yitzchok

קודם כל את זה אני מגבה בחום

Yanai כתב:

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

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

לגבי סדר העדכונים – סדר לפי סוג זה כלל טוב אבל העיקר החשוב זה תלות.
על אף שהכנת הישויות קורית רק בסוף, הכלל של דטהבייסים (תקינים) של "אי אפשר להצביע על דבר שלא נמצא" כן חל ולזה רמת ינאי כשאמר שדו"ח צריך להיות לפני פרוצדורה. זה לא שדו"ח חייב בגלל איזו היררכיית חשיבות ללכת קודם אלא פשוט שאי אפשר לשייך Y ל-X אם לא נמצא גם Y וגם X. ואם עושים TAKESINGLEENT עבור פרוצדורה שלמה כולל כל השלבים אז הדו"חות (או ממשקים או מסכי קלט וכו') צריכים להיות שם כבר אחרת המערכת תשאל איך היא אמורה לשים יישות Y בתוך יישות X אם Y לא מוכרת לה?

מקווה שזה הבהיר קצת יותר

צילום המסך לא אומר לנו הרבה

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

אלא אם כבר הסתדרת

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

נשמח לדעת אם גילית משהו או אם אתה עדיין תקוע (או אם הפעלה מחדש סידרה את זה B) )

ממה שאתה מתאר אני חושש שאתה חשבת להביא לחברה X את כל ההזמנות מחברה Y כדי לעשות JOIN
אני בספק אם זה רעיון טוב

אני הייתי כן שוקל להוסיף מסך בן וכשנכנסים אליו הפעלת PRE-FORM שלו יקפוץ לחברה השניה ויביא את הפרטים
ושים לב שאני אומר חברה שניה כאילו אני יודע איזו וזה בתנאי שאני (לדוגמה) קינפגתי מאפיין או משהו בלקוח בו כתוב שם החברה (פנימי DNAME) של הסביבה של הלקוח הזה, אחרת אני אאלץ גם לעשות לולאה בכל החברות לחפש את ההזמנה (אא"כ זה תמיד יהיה חיפוש בחברה Y ואולי רק מחברה X)
אם מדבור בכמה ערכים בלבד אפשר מסך של שורה שמבוססת על השורה של מסך העל, ואפשר לעבוד עם טבלת link בהפעלה ולהציג ערכים ממשתנים.

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

אלה הדברים שאני חושב עליהם כרגע

בהצלחה וחג שמח

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

למה שלא תהפוך את המסך לרב חברתי ואז תוכל לשלוף כל נתון בכל שדה מכל החברות שתגדיר כמשתתפות במסך רב חברתי?

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

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

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

מקווה שזה מכוון אותך קצת.