none
EF 4.3.1 פיצול טבלה לשתי ישיות בשילוב ירושה RRS feed

  • שאלה

  • שלום לכולם,

    אני עובד עם EntityFramework 4.3.1.

    ברצוני לפצל נתוני טבלה אחת לשתי ישויות כאשר ישות אחת תכיל את השניה, כלומר, אחת תהיה baseType של השניה.

    לדוגמא:

    יש לי טבלת תשלומים המכילה את השדות:

    id,total,paymentData,bankAccount,voucherId

    אני רוצה לשים בישות ה-base את השדות : paymentDate, bankAccount

    ואת כל השאר בישות אחרת שתירש את ישות ה-base

    זאת, כיון שלעיתים אני שולף ממסד הנתונים (באמצעות שאילתת linq) רק את הנתונים של ה-base וחבל לי להגדיר עוד אוביקט.

    האם זה בכלל נכון?

    האם יש דרך לעשות זאת?

    תודה מראש!


    ג'רי

    • הועבר על-ידי Eran Sharvit יום חמישי 19 דצמבר 2013 09:32
    יום רביעי 18 דצמבר 2013 11:33

תשובות

  • לפני הכל נתחיל מהסוף בכך שתמיד יש דרך לבצע כל מה שרוצים במחשבים. הכל עניין רק של ידע ויכולת :-)

    1. דבר ראשון צריך לחשוב מה ההגיון בפיצול שאתה מדבר עליו ובמבנה האלמנט החדש שאתה מציע.

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

    3. לסיום השלב ההתחלתי צריך להבין באיזה גישה/שיטה אתה עובד עם EF.

    1. יישות צריכה להיות ייחודית. אפשר לעבוד עם יישויות לא ייחודיות אבל כיצד תדע לאיזה מהיישויות אתה פונה? טור ייחודי במסד הנתונים משמש לנו בדרך כלל בדיוק לצורך זה. אם יש לך 2 אנשים עם השם X אז כיצד תדע מי כרגע הפעיל? התשובה היא על ידי שימוש בטור הייחודי (למשל טור ה ID או טור של תעודת זהות)

    יישות שכוללת רק את הנתון של paymentDate, bankAccount לא כוללת נתון ייחודי ולכן התכנון שלך לוקה בחסר.

    המבנה המקורי שאתה מציג גם הוא נשמע בעייתי: id,total,paymentData,bankAccount,voucherId

    אתה כולל כאן נתון שמהשם שלו נובע שהוא אנו נתון בודד אלא סיכום של נתונים! מה זה total?!? סך הכל מה? זו אינה יישות אלא נתון של יישות אחרת לפי השם.

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

    יש סיבה שאפיון מערכת זה החלק היותר מורכב ויותר מתקדם בפיתוח ולא כתיבת הקוד :-)

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

    2. יש אפשרות להגדיר יישויות בהתאמה למסד הנתונים ויש אפשרויות להגדיר יישויות בצורה דינאמית או קבועה באפליקציה. למשל אם יש לי טבלה שמכילה נתונים של משתמשים ולכן יש בה את הטורים ID,FirstName,LastName אז יכול להיות שיותר מתאים באפליקציה להגדיר יישות שונה בשם משתמש שיש בה את המאפיינים ID,FUllName. לא תמיד צריכה להיות התאמה בין הטבלאות במסד הנתונים ובין היישות באפליקציה. לכן בשלב זה עלייך לתכנן את היישויות באפליקציה ואת הארכיטקטורה של מסד הנתונים שלך. תחשוב מה לפצל והיכן.

    יישות באפליקציה מגדירים בצורה קבועה על ידי הגדרת מחלקה מתאימה למשל או בצורה דינאמית. LINQ יודע לעבוד עם יישויות שאינן תואמות למסד הנתונים בצורה מובנית בעבדה עם 

    דוגמה טובה לכך יש בקישור הבא בסעיף "Scenario 3: Splitting a Table Across Multiple Types"
    http://weblogs.asp.net/scottgu/archive/2010/07/23/entity-framework-4-code-first-custom-database-schema-mapping.aspx

    ** אני ממליץ לעבור על כל הפרוייקט דוגמה של NerdDinner. לאחר שתפתח אותו תעד אחרי תעד עם המדריכים המתאימים (אם יש לך את הרקע המתאים ב C#) אז אתה תשלוט טוב מאוד בכל הנושא שאתה שואל עליו!
    http://www.asp.net/mvc/tutorials/older-versions/nerddinner/introducing-the-nerddinner-tutorial

    3. יש כמה צורת עבודה עם EF שהן מעט שונות בהקשר של החלוקה ליישויות ובכללץ עלייך לוודא (ולספר לנו) באיזו צורה אתה עובד:

    Code-First
    Model-First
    Database-first

    אני מקווה שזה ייתן כיוון להמשך ולא דיברתי סינית.
    * תזכור שגם אם אתה שולף בשאילתה רק 2 טורים מטבלה אין מניעה שיהיה בטבלה עוד טורים.
    * תזכור שנוח ברמת האפליקציה שיישות תהיה מתאימה לזו שבה אנחנו עושים שימוש בלי נתונים מיותרים (למה לשלוף נתונים מיותרים)
    * ולסיום תזכור לנטר את השאילתות במגיעות למסד הנתונים בפועל ולא רק לסמוך על כך שמייקרוסופט דאגו שהשאילתות LONQ שלך יתורגמו נכון ובצורה מיטבית לשאילתות SQL (הרבה מאוד פעמים זה לא קורה בעיקר באשמת המפתח אבל לפעיתים גם בגלל מיגבלות ה ORM של EF).


    [Personal Site] [Blog] [Facebook]signature

    • סומן כתשובה על-ידי Eran Sharvit יום ראשון 22 דצמבר 2013 10:22
    יום חמישי 19 דצמבר 2013 15:14
    מנחה דיון
  • * קשה לתת קוד ותשובה ספציפית כשאין לנו קוד :-)

    תבדוק אם המדריך הבא עוזר לך (מה שאתה צריך זה יחס יחיד ליחיד):

    http://www.asp.net/mvc/tutorials/getting-started-with-ef-5-using-mvc-4/implementing-inheritance-with-the-entity-framework-in-an-asp-net-mvc-application

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

    תיאורטית אתה יכול פשוט ליצור 2 מחלקות חדשות אחת עם המאפיינים paymentDate, bankAccount ומחלקה שנייה שנגזרת מהראשונה ומוסיפה מאפיינים id,total,voucherId. בו פעם יש לך בעיה שלא תוכל לזהות את היישויות מהמחלקה הראשונה כי אין לך שום נתון ייחודי! אבל תיאורטית זה אפשרי. ואז אתה יכול ליצור אובייקטים של מחלקות אלו על ידי שימוש במחלקה המתאימה לטבלה שלך שנוצרה במודול. זה דרך עקומה. אני לא מצליח להבהיר מספיק טוב שהכל עניין של תכנון. יישות צריכה זיהוי חד חד ערכי. תחשוב שוב על הגדרה של יישות דנאמית ולא שימוש בגזירה (שים לב שאני מסיים כל הודעה כמעט באותו משפט... קודם כתבתי "אבל צריך לחשוב האם אכן מדובר ביישות נגזרת או אולי ביישות חדשה לחלוטין")

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

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


    [Personal Site] [Blog] [Facebook]signature

    • סומן כתשובה על-ידי ג'רי יום שני 23 דצמבר 2013 08:40
    • סימון כתשובה בוטל על-ידי ג'רי יום שני 23 דצמבר 2013 08:40
    • סומן כתשובה על-ידי ג'רי יום שני 23 דצמבר 2013 08:43
    יום שני 23 דצמבר 2013 08:06
    מנחה דיון

כל התגובות

  • אני מעביר את השאלה לפורום יותר מתאים.

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

    יום חמישי 19 דצמבר 2013 09:32
  • תראה את הקוד שלך, ותנסה להצביע על החלק המיותר.

    אני מנחש שאתה משתמש עם LinqToSql ולא אתה אחראי ליצירת האובייקטים, ומפריע לך שנוצר אובייקט עם שדות מיותרים פר שורה .

    לדעתי זה דאגה מיותרת, אפי' שברמה התיאוריה זה אכן לוקח טיפה יותר זיכרון.

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

    יום חמישי 19 דצמבר 2013 11:49
  • לפני הכל נתחיל מהסוף בכך שתמיד יש דרך לבצע כל מה שרוצים במחשבים. הכל עניין רק של ידע ויכולת :-)

    1. דבר ראשון צריך לחשוב מה ההגיון בפיצול שאתה מדבר עליו ובמבנה האלמנט החדש שאתה מציע.

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

    3. לסיום השלב ההתחלתי צריך להבין באיזה גישה/שיטה אתה עובד עם EF.

    1. יישות צריכה להיות ייחודית. אפשר לעבוד עם יישויות לא ייחודיות אבל כיצד תדע לאיזה מהיישויות אתה פונה? טור ייחודי במסד הנתונים משמש לנו בדרך כלל בדיוק לצורך זה. אם יש לך 2 אנשים עם השם X אז כיצד תדע מי כרגע הפעיל? התשובה היא על ידי שימוש בטור הייחודי (למשל טור ה ID או טור של תעודת זהות)

    יישות שכוללת רק את הנתון של paymentDate, bankAccount לא כוללת נתון ייחודי ולכן התכנון שלך לוקה בחסר.

    המבנה המקורי שאתה מציג גם הוא נשמע בעייתי: id,total,paymentData,bankAccount,voucherId

    אתה כולל כאן נתון שמהשם שלו נובע שהוא אנו נתון בודד אלא סיכום של נתונים! מה זה total?!? סך הכל מה? זו אינה יישות אלא נתון של יישות אחרת לפי השם.

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

    יש סיבה שאפיון מערכת זה החלק היותר מורכב ויותר מתקדם בפיתוח ולא כתיבת הקוד :-)

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

    2. יש אפשרות להגדיר יישויות בהתאמה למסד הנתונים ויש אפשרויות להגדיר יישויות בצורה דינאמית או קבועה באפליקציה. למשל אם יש לי טבלה שמכילה נתונים של משתמשים ולכן יש בה את הטורים ID,FirstName,LastName אז יכול להיות שיותר מתאים באפליקציה להגדיר יישות שונה בשם משתמש שיש בה את המאפיינים ID,FUllName. לא תמיד צריכה להיות התאמה בין הטבלאות במסד הנתונים ובין היישות באפליקציה. לכן בשלב זה עלייך לתכנן את היישויות באפליקציה ואת הארכיטקטורה של מסד הנתונים שלך. תחשוב מה לפצל והיכן.

    יישות באפליקציה מגדירים בצורה קבועה על ידי הגדרת מחלקה מתאימה למשל או בצורה דינאמית. LINQ יודע לעבוד עם יישויות שאינן תואמות למסד הנתונים בצורה מובנית בעבדה עם 

    דוגמה טובה לכך יש בקישור הבא בסעיף "Scenario 3: Splitting a Table Across Multiple Types"
    http://weblogs.asp.net/scottgu/archive/2010/07/23/entity-framework-4-code-first-custom-database-schema-mapping.aspx

    ** אני ממליץ לעבור על כל הפרוייקט דוגמה של NerdDinner. לאחר שתפתח אותו תעד אחרי תעד עם המדריכים המתאימים (אם יש לך את הרקע המתאים ב C#) אז אתה תשלוט טוב מאוד בכל הנושא שאתה שואל עליו!
    http://www.asp.net/mvc/tutorials/older-versions/nerddinner/introducing-the-nerddinner-tutorial

    3. יש כמה צורת עבודה עם EF שהן מעט שונות בהקשר של החלוקה ליישויות ובכללץ עלייך לוודא (ולספר לנו) באיזו צורה אתה עובד:

    Code-First
    Model-First
    Database-first

    אני מקווה שזה ייתן כיוון להמשך ולא דיברתי סינית.
    * תזכור שגם אם אתה שולף בשאילתה רק 2 טורים מטבלה אין מניעה שיהיה בטבלה עוד טורים.
    * תזכור שנוח ברמת האפליקציה שיישות תהיה מתאימה לזו שבה אנחנו עושים שימוש בלי נתונים מיותרים (למה לשלוף נתונים מיותרים)
    * ולסיום תזכור לנטר את השאילתות במגיעות למסד הנתונים בפועל ולא רק לסמוך על כך שמייקרוסופט דאגו שהשאילתות LONQ שלך יתורגמו נכון ובצורה מיטבית לשאילתות SQL (הרבה מאוד פעמים זה לא קורה בעיקר באשמת המפתח אבל לפעיתים גם בגלל מיגבלות ה ORM של EF).


    [Personal Site] [Blog] [Facebook]signature

    • סומן כתשובה על-ידי Eran Sharvit יום ראשון 22 דצמבר 2013 10:22
    יום חמישי 19 דצמבר 2013 15:14
    מנחה דיון
  • ראשית, תודה רבה על התשובה המפורטת והארוכה.

    לפי מה שכתבת, אני מבין שלא הסברתי את עצמי מספיק טוב, ואנסה לעשות זאת:

    אני עובד עם ה-ef בצורה של Database-first.

    יש לי במסד הנתונים טבלת תשלומים המכילה פרטי תשלומים שהתקבלו (total - סה"כ ששולם, פר שורה ולא סיכום של כמה שורות).

    אני רוצה לפצל את נתוני הטבלה לשתי ישויות: ישות שתכיל את הנתונים הבסיסיים וישות שתכיל את שאר הנתונים.

    בישות הבסיסית אשתמש בפעמים שאני שולף ממסד הנתונים (באמצעות שאילתת linq על ה-ef) רק את הנתונים הבסיסיים.

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

    חשבתי לעשות זאת כי זה היה נראה לי יותר קריא, אך אינני יודע אם זה נכון.

    מקווה שהבהרתי יותר טוב.

    תודה מראש!


    ג'רי

    יום ראשון 22 דצמבר 2013 11:35
  • זה בערך מה שהבנתי גם קודם. ההערות שלי היו בחלקן לגבי התכנון הכללי של האפליקציה והיישויות באפליקציה ומסד הנתונים ולא רק השאלה ששאלת.

    "total - סה"כ ששולם, פר שורה ולא סיכום של כמה שורות" ז"א הוא ס"הכ של משהו... של מה? מה הוא מסכם? האם אין לך יישות מתאימה למה שהוא מסכם? משתמש לא משלם לפי הסה"כ אלא לפי מוצרים למשל שבחר. אם אני הייתי חושב על מערכת שיש בה תשלום על מוצרים אז עבור כל מוצר יש תשלום מסויים ואין הגיון לשים את הס"הכ במקום נוסף.

    נניח חנות עם מוצרים A ו B
    אדם רוכש 2 מוצרים של A ומוצר 1 של B
    לכן יכולה להיות טבלה של "פירוט רכישות", ועבור הקנייה הכוללת של האדם הזה יתווספו בטבלה 3 רשומות או 2 תלוי במבנה שמתכננים (שוב)

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

    אני לא יודע אם זה מה שמתאים לך ולא יכול לייעץ על ארכיטקטורה בפורום בדרך כלל, אבל זה נועד רק לתת כיוון כללי.

    כאמור אני חושב שכדאי לעבור על הארכיטקטורה של מסד הנתונים שלך והיישויות באפליקציה. כדאי להציץ באפליקציות של חנויות למשל כדי לקבל התרשמות כללית. 

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


    [Personal Site] [Blog] [Facebook]signature

    יום ראשון 22 דצמבר 2013 14:28
    מנחה דיון
  • שוב- תודה רבה על התשובה!

    לגבי התכנון, הוא נראה לי מתאים לצורך שלי:

    לא מדובר בתשלום מוצרים , אלא בתשלום חוב שיש לו סה"כ אחד. בכל אופן תודה על ההערה.

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

    תודה מראש!


    ג'רי

    יום שני 23 דצמבר 2013 05:08
  • * קשה לתת קוד ותשובה ספציפית כשאין לנו קוד :-)

    תבדוק אם המדריך הבא עוזר לך (מה שאתה צריך זה יחס יחיד ליחיד):

    http://www.asp.net/mvc/tutorials/getting-started-with-ef-5-using-mvc-4/implementing-inheritance-with-the-entity-framework-in-an-asp-net-mvc-application

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

    תיאורטית אתה יכול פשוט ליצור 2 מחלקות חדשות אחת עם המאפיינים paymentDate, bankAccount ומחלקה שנייה שנגזרת מהראשונה ומוסיפה מאפיינים id,total,voucherId. בו פעם יש לך בעיה שלא תוכל לזהות את היישויות מהמחלקה הראשונה כי אין לך שום נתון ייחודי! אבל תיאורטית זה אפשרי. ואז אתה יכול ליצור אובייקטים של מחלקות אלו על ידי שימוש במחלקה המתאימה לטבלה שלך שנוצרה במודול. זה דרך עקומה. אני לא מצליח להבהיר מספיק טוב שהכל עניין של תכנון. יישות צריכה זיהוי חד חד ערכי. תחשוב שוב על הגדרה של יישות דנאמית ולא שימוש בגזירה (שים לב שאני מסיים כל הודעה כמעט באותו משפט... קודם כתבתי "אבל צריך לחשוב האם אכן מדובר ביישות נגזרת או אולי ביישות חדשה לחלוטין")

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

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


    [Personal Site] [Blog] [Facebook]signature

    • סומן כתשובה על-ידי ג'רי יום שני 23 דצמבר 2013 08:40
    • סימון כתשובה בוטל על-ידי ג'רי יום שני 23 דצמבר 2013 08:40
    • סומן כתשובה על-ידי ג'רי יום שני 23 דצמבר 2013 08:43
    יום שני 23 דצמבר 2013 08:06
    מנחה דיון
  • הבנתי, ממש ממש תודה רבה!

    אין לי אפשרות לצרף את הפרויקט מכמה סיבות ולכן אינני עושה זאת.

    אני אנסה לבדוק ולממש את הדברים.

    ושוב- תודה על התשובות המפורטות ועל הזמן המושקע בהם!


    ג'רי

    יום שני 23 דצמבר 2013 08:43
  • בכיף :-)

    ברצינות בכיף :-) זה תמיד נחמד לראות אנשים מנומסים שאומרים גם תודה. לצערי זה לא כל כך נפוץ בפורומים של מייקרוסופט משום מה. אז תודה על התודה ואתה מוזמן גם להמשיך לבקר כשאין לך שאלות ולעניין בהודעות אחרות. אפשר ללמוד הרבה מאוד מבעיות שאחרים נתקלים בהם ואולי תוכל גם לעזור לאחרים :-)


    [Personal Site] [Blog] [Facebook]signature

    יום שני 23 דצמבר 2013 10:14
    מנחה דיון