none
שם של default על עמודה של User-Defined Table type RRS feed

  • שאלה

  • היי,

    האם מישהו יודע אם ניתן לתת שם ל Default Constraint שהוגדר על עמודה של User-Defined table type.

    אני לא מצליח למצוא לזה שום אזכור או דוגמה ברשת.

    יום חמישי 13 אפריל 2017 12:13

כל התגובות

  • אהלן

    אתהמדבר על שימוש ב Table-valued parameters ?

    From the BOL: A user-defined table type cannot be used as a column in a table or a field in a structured user-defined type.

    לא ברור לי מה בדיוק אתה מנסה לעזות

    אני מניח שאתה מתכוון ל constraint של ערך ברירת מחדל שיכנס לעמודה מסויימת בטבלה, אבל אנא תקרא את הציטוט מעל. השאילתה הבאה תגרור שגיאה:

    CREATE TYPE numType AS TABLE (num INT );  
    GO  
    
    CREATE TABLE T (id int identity(1,1), MynumType numType)
    GO

    אתה יכול לנסות להבהיר את הבעיה מעט יותר. מה בדיוק אתה עשה כרגע

    * אפשר ליצור טבלה עם עמודה מסוג חדש שהוגדר בעזרת CLR ואז אפשרלקבוע constraint של ברירת מחדל.


    signature   Ronen Ariely
     [Personal Site]    [Blog]    [Facebook]    [Linkedin]


    יום רביעי 19 אפריל 2017 00:00
    מנחה דיון
  • שלום,

    עד כמה שידוע לי אין אפשרות לתת שם ל-Default Constraint על עמודה של משתנה טבלה.

    זה לא יעבוד לך:

    create type dbo.myTab AS TABLE (col1 INT, col2 INT CONSTRAINT DF_MyTab DEFAULT(12))

    אבל זה כן יעבוד:

    create type dbo.myTab AS TABLE (col1 INT, col2 INT DEFAULT(12))

    אפשר לשאול אבל למה בכלל יש לך צורך לתת שם ל-Default Constraint?
    פשוט תגדיר אותו בלי שם כמו שכתבתי למעלה.

    לדעתי הסיבה להגבלה הזאת זה ש-constraint הוא סוג של אובייקט שמותר שיהיה קיים רק אחד עם אותו שם באותה סכמה.
    אם אתה מגדיר אחד כזה עם שם על User Defined Table Type, אז כל פעם ששני אנשים ינסו להשתמש בטיפוס נתונים הזה (יעשו DECLARE או יריצו פרוצדורה שמשתמשת בו כפרמטר), אז SQL תאורטית ינסה לשכפל גם את ה-constraint.
    אבל אם יהיה להם את אותו השם אז זה יגרום להתנגשות.

    למעשה, אותה בעיה גם קיימת עם טבלאות זמניות (אלה עם הסולמית #).
    אפשר אפילו להוכיח את זה. תריץ את הסקריפט הזה משני חלונות נפרדים:

    create table #t (col1 int CONSTRAINT DF_t DEFAULT (1));

    ותראה שכשתריץ את זה בחלון השני, זה יקפיץ שגיאה על זה ש-DF_t כבר קיים.

    תאר לך שיצרת פרוצדורה שכחלק מהלוגיקה שלה היא יוצרת טבלה זמנית כזאת עם Default Constraint בעל שם, ושני אנשים מריצים את הפרוצדורה בו-זמנית.
    בום - התנגשות, שגיאות, כיף חיים.

    קח דוגמא:

    create procedure proctest
    as
    create table #t (col1 int CONSTRAINT DF_t DEFAULT (1));
    
    waitfor delay '00:00:30'
    
    drop table #t 

    תריץ את הפרוצדורה proctest משני חלונות ותראה מה קורה.

    אותה בעיה בדיוק תיגרם אם ניתן היה לעשות את זה עם טבלאות משתנה (אלה עם השטרודל @).
    אבל כנראה שמיקרוסופט הפעם חשבו קדימה והטמיעו מניעה לדבר הזה :)


    Eitan Blumin; SQL Server Consultant - Madeira Data Solutions;




    • נערך על-ידי EitanBlumin יום חמישי 13 יולי 2017 07:37
    • הוצע כתשובה על-ידי EitanBlumin יום חמישי 13 יולי 2017 07:39
    • הצעה כתשובה בוטלה על-ידי pituachMVP, Editor יום שישי 14 יולי 2017 12:18
    יום חמישי 13 יולי 2017 07:10
  • אהלן איתן וברוך הבא לפורום

    יישר כוח על העזרה :-)
    +5

        

    * עם זה, אנא אל תציע הודעות של עצמך כתשובה. העובדה שאתה מפרסם תשבוה כבר אומרת שאתה חושב שזה התשובה ולכן אין שום ייעול בסימון עצמי. לא לכך נועד הסימון. הסימון נועד בשביל לחזק תגובה של מישהו אחר שאתה גם רוצה להגיד שזה התשובה לדעתך.

    תחשוב על האבסורד - כל מי ששם תשובה ורוצה לעזור חושב שהוא סם תשובה נכונה, אחרת הוא לא היה שם אטותה. אם כל אחד יסמן את התשובה של עצמו אז כל התשובות יהיו מסומנות = זה שווה לכך ששום תשובה לא מסומנת

    בדיוק כמו שלא כותבים מסמך שכולו בטקסט בולט מכיוון שאז אין שום דבר שבולט כך אין הגיון לסמן את כל התשובות

    תודה על ההבנה,

       

    הערה:
    לצרכי מינהלה בלבד במקרים נדירים מאוד כאשר פורום כולל מנהל בודד, ישנם מצבים שמנהל הפורום מציע הודעות של עצמו כתשובה, אבל גם במקרה קיצוני זה לא נהוג ולא ניראה טוב שמישהו יסמן את התגובות של עצמו כתשובות! במקרים קיצוניים מאוד כמו בפורומים בעברית, בהם במקרה הטוב ישמנהל בודד פעיל (ועוד כמה אולי על הנייר), אז אפשר לראות אלפי הודעות (שלי למשל) שלא סומנו כתשובה => מה שגורר כמובן הפסד נקודות - אבל אחרי הכל אנחנו לא יכולים ללכת למכולת עם הנקודות ועד שמייקרוסופט יקצו owner פעיל לפורומים בעברית (מה שלא ניראה באופק לצערי) וכל פורום יכלול לפחות 2 מנהלים פעילים, הבעיה לא תפתר. לשמחתך ולשמחת המשתמשים בפורומים בהם אני משמש כמנהל, אני דואג לסגירת שרשורים של אחרים, ואני מסמן תשובות של משתמשים אחרים אם אני רואה שמי ששאל את השאלה לא סגר את השרשור בעצמו וזו התשובה הברורה היחידה. כך שהיחיד ש"סובל" מהנושא הוא מנהל הפורום :-)


    signature   Ronen Ariely
     [Personal Site]    [Blog]    [Facebook]    [Linkedin]



    יום שישי 14 יולי 2017 12:31
    מנחה דיון
  • תודה על ההערה, רונן.

    לא חשבתי שזאת בעיה, אחרת ההיגיון אומר שהפיצ'ר לא היה קיים.
    אחרי הכל, אתה לא יכול, למשל, לעשות upvote לתגובות של עצמך, אז אני לא עושה. הפיצ'ר לא קיים פשוט.
    אם אסור לעשות לעצמך mark as answer אז למה הפיצ'ר הזה דווקא כן קיים? זה בכל אופן היה כיוון החשיבה שלי.

    אבל אם זאת בעיה אז אני לא אעשה את זה יותר.

    תודה שוב וסליחה


    Eitan Blumin; SQL Server Consultant - Madeira Data Solutions;

    שבת 15 יולי 2017 06:39
  • אהלן איתן,

    אין בעיה, ותודה על ההבנה :-)

    * ההסבר הקצר הוא שאנחנו לא רוצים שימנעו ממשתמש להציע את ההודעה של עצמו מכיוון שכרגע יש לכך צורך (במקרים נדירים) לצרכי מינהלה, כפי שהזכרתי מעל. כמובן שהיה אפשר לשפר את המערכת ולחסוך את הצורך על ידי הרשאות יותר מגוונות (למשל לאפשר רק למנהלים לסמן הודעות של עצמן לצרכי מינהלה או פתרון אחר שכרגע וכניראה גם בעתיד הנראה לעין לא קיים במערכת)


    signature   Ronen Ariely
     [Personal Site]    [Blog]    [Facebook]    [Linkedin]


    שבת 15 יולי 2017 23:22
    מנחה דיון