yitzchok

Forum Replies Created

מוצגות 15 תגובות – 2,011 עד 2,025 (מתוך 2,466 סה״כ)
  • Replies
  • yitzchok
    משתתף
    IL
    כן, זה איפה שמפתחים

    איך היית מתחיל?

      [ בבקשה לא לשלוח הודעות פרטיות במערכת - אני לא קורא אותן ]
    yitzchok
    משתתף
    IL
    ודאי שזה פיתוח…

    לא נורא מורכב למי שמכיר טוב איך לפתח במערכת אבל למי שלא מכיר זה יהיה אתגר ממש.

      [ בבקשה לא לשלוח הודעות פרטיות במערכת - אני לא קורא אותן ]
    yitzchok
    משתתף
    IL
    רצוי לספר כאן על הדרישה המלאה מההתחלה – לפעמים הפרטים יכולים לשנות משמעותית את הפתרון…

    אפשר לתאר את הדרישה שלך כך:

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

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

    ?

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

      [ בבקשה לא לשלוח הודעות פרטיות במערכת - אני לא קורא אותן ]
    yitzchok
    משתתף
    IL
    בתפריט של מחולל פרוצדורות.

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

      [ בבקשה לא לשלוח הודעות פרטיות במערכת - אני לא קורא אותן ]
    yitzchok
    משתתף
    IL
    adbs3000 כתב:

    יש לי פרוצדורה

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

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

      [ בבקשה לא לשלוח הודעות פרטיות במערכת - אני לא קורא אותן ]
    yitzchok
    משתתף
    IL
    אוסיף לזה הסתייגות.
    מה שאני כתבתי מבוסס על הנחה שכל הטעינות נעשות באותו משתמש.
      [ בבקשה לא לשלוח הודעות פרטיות במערכת - אני לא קורא אותן ]
    yitzchok
    משתתף
    IL
    אני לא חושב שאת צודקת בקשר לדו"ח השגיאות.

    טעינה תקינה תרוקן את הדו"ח ולא תוכלי לראות את השגיאות מטעינות שקדמו לה.

      [ בבקשה לא לשלוח הודעות פרטיות במערכת - אני לא קורא אותן ]
    yitzchok
    משתתף
    IL
    אפשר לחסוך הרבה.

    ושם מוסיף את העמודות הנוסופת הרצויות.

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

    בינתיים נניח שתעשה את הכל בשלבי הכנה.

    הנחה נוספת: המקור שלך מסודר וכל תאריך סיום אחרי תאריך ההתחלה הקשור אליו.

    אני הייתי עושה כך:

    1. אוסף (MIN(SDATE ו- (MAX(EDATE על פני כל התעודות – נקרא לאלה MIN_SDATE ו-MAX_EDATE
    2. עושה לולאה פשוטה (לא קורסור). מתחיל מ-MIN_SDATE, בוחן אם מדובר בששי/שבת (או בתאריך של חופשים אחרים) ומדלג אם כן. (אם יש מצב של ששי/שבת שיכול להיות יום עבודה אז חזור למה שכתבתי קודם על נושא זה ושנה כאן בהתאם). את התאריך הזה מכניסים לטבלה (אם לא מדלגים) – טבלת STACK מצויינת לזה, רק לעשות 0+ כדי להפוך את התאריך למספר. וחוזר עד שמגיע ל-MAX_EDATE.
    3. עושה שאילתא על בסיס טבלת התעודות, וטבלת התאריכים מהשלב הקודם. עושים תנאי שהערך מטבלת התאריכים צריך להיות בין ה-SDATE וה-EDATE של התעודה (כולל, אם כך אתה רוצה) ואז קבץ לפי DOC ותוציא ספירה (COUNT) של מספר השורות שאתה מקבל לכל ערך של DOC. תוכל כאן לדעתי לדלג על שמירת SDATE ו-EDATE כי תוכל להביא אותם לדו"ח ביחד עם הערכים האחרים. כך שאתה צריך להכניס רק שני עמודות DOC ו-COUNT לאיזו טבלת לינק.
    4. כמו שלב 3 שלך

    מה דעתך?

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

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

      [ בבקשה לא לשלוח הודעות פרטיות במערכת - אני לא קורא אותן ]
    • in reply to: CHOOSE-FIELD
    yitzchok
    משתתף
    IL
    בתשובה זאת אני מניח שאתה שואל על סטטוס של התעודה ולא בשדה סטטוס בשורה.

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

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

      [ בבקשה לא לשלוח הודעות פרטיות במערכת - אני לא קורא אותן ]
    yitzchok
    משתתף
    IL
    ולא קוראים לא לטבלה ולא למסך SUPTOCUST אלא HADA_SUPTOCUST (לדוגמה) כאשר ארבע האותיות הראשונות הן הקידומת המקובלת אצלכם

    בנוסף השמות CUSTSUPPLIERS או CUSTSUP (אחרי הקידומת כנ"ל) היו מתאימים יותר לסגנון השמות שבפריוריטי

      [ בבקשה לא לשלוח הודעות פרטיות במערכת - אני לא קורא אותן ]
    yitzchok
    משתתף
    IL
    yitzchok כתב:

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

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

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

      [ בבקשה לא לשלוח הודעות פרטיות במערכת - אני לא קורא אותן ]
    yitzchok
    משתתף
    IL
    כתוספת לכל מה שנעם כתב אני אציע לקרוא את העמודים הבאים שמסבירים כללים מאוד חשובים לגבי תכנון מסדי נתונים. בלי הכרת הכללים האלה אפשר בקלות להוסיף דברים לפריוריטי שאו לא עונים לצרכים או שפשוט לא יעבדו.

    נרמול בסיס נתונים בויקיפדיה
    תיאור העקרונות הבסיסיים של נרמול מסדי נתונים באתר מיקרוסופט

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

      [ בבקשה לא לשלוח הודעות פרטיות במערכת - אני לא קורא אותן ]
    yitzchok
    משתתף
    IL
    במקרה של SUPPLIERSA אנחנו לא יכולים להיות בטוח שיש רשומה מתאימה בטבלה ולכן צריכים סימן שאלה בעמודת "מזהה עמודה" או "מזהה חיתוך" (לפי הצורך) באיזכור אחד של הטבלה.

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

      [ בבקשה לא לשלוח הודעות פרטיות במערכת - אני לא קורא אותן ]
    yitzchok
    משתתף
    IL
    גם אם עושים את זה לא נורא יעיל זה לא יקח המון זמן.
    מי שיבין טוב יכול לבנות משהו שיקח מספר שניות גג.
      [ בבקשה לא לשלוח הודעות פרטיות במערכת - אני לא קורא אותן ]
מוצגות 15 תגובות – 2,011 עד 2,025 (מתוך 2,466 סה״כ)