yoram

Forum Replies Created

מוצגות 15 תגובות – 16 עד 30 (מתוך 160 סה״כ)
  • Replies
  • yoram
    משתתף
    זאת בעיה ידועה ב – OUTLOOK .

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

    yoram
    משתתף
    תודה רבה!
    yoram
    משתתף
    תודה .

    זה רץ ב – TTS כך שקלט פחות טוב .

    yoram
    משתתף
    תודה רבה
    yoram
    משתתף
    תעלה לפה בבקשה כדי שנוכל לקרוא גם.
    yoram
    משתתף
    תודה.
    בהמשך של עבודה בממשק הוובי – איך הדרך הנוחה ביותר לדבג לתוך קובץ ושהקובץ יישמר במחשב שלי ולא ע"ג השרת באירוח ואז אין לי גישה לקובץ.
    • in reply to: מחקר
    yoram
    משתתף
    שלום נועם.

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

    yoram
    משתתף
    michaelm כתב:

    snoof123 כתב:
    [quote]היי יהורם,
    שאלה: מה אתה היית עושה במצב שבו אתה מנסה להוסיף עמודה לטבלה כמו PART ועברו שעתיים והתכנית לא סיימה.

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

    לא משנה אם ברוח החיובית או השלילית, לא אמורים להגיע לכזה מצב כי:
    1. מגבים את הטבלה בכל החברות לפני ה-DBI.
    2. מוציאים את כל המשתמשים מהמערכת (אפשר לפתח תוכנית כזאת).
    3. במקרה של טבלאות גדולות וחשובות כמו PART חושבים 10 פעמים לפני שמחליטים להוסיף שדה בטבלה עצמה (ואז עושים במשנה זהירות).
    אבל בדרך כלל מוסיפים טבלת המשך (כמובן שכאן צריך לפתח את כל הטריגרים הדרושים).

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

    5. ואם בכל זאת נאלצתי להרוג את התהליך, לא מקמפלים והולכים הביתה, אלא בודקים מול לקוח תקינות נתונים.
    בדיקה מינימלית – מספר רשומות לפני ואחרי.
    ואז משחזרים את הנתונים ולא מחכים לצרחות מהלקוח.[/quote]

    חד משמעית!!!

    yoram
    משתתף
    היי,

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

    1. כאשר מבצעים DBI שכזה מאחורי הקלעים הבסיס נתונים "מעתיק" הצידה את כל רשומות הטבלה , מבצע את השינוי בטבלה ומחזיר את הרשומות חזרה (זה בצורה מפושטת ).
    2. יש חשיבות לכמות הרשומות שיש בטבלה – ואכן במקרה הזה היו בטבלה ס"ג של 80K רשומות ולכן גם זה השפיע על הזמן הנדרש .
    3. כניסה לבסיס נתונים עצמו דרך ה – SQL MANAGMENT הראתה שהתהליך עדיין רץ ושיש DEADLOCK על הטבלה מאחר ומישהו באותו זמן גם ניסה לבצע גישה נוספת לטבלה במקביל (שחרור ה – DEADLOCK יכל לפתור כמעט בוודאות את הבעיה) .
    4. לוודא שכלל המשתמשים באמת מחוץ למערכת – ולא מבצעים פעולות שיכולות לשבש את ה – DBI .
    5. גיבוי נקודותי לטבלה ממש לפני ביצוע (לא מדובר בגיבוי השעתי/היומי) .

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

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

    אני לא כל כך מסכים עם מה שנכתב פה בתגובה לשאלתך .

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

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

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

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

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

    מקווה שעזרתי לך.

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

    yoram
    משתתף
    תשאיר פרטי התקשרות ואחזור אלייך .

    נשמח לבצע את העבודה .

    yoram
    משתתף
    בדוח פירוט ההזמנה שהוא אחד מהדוחות בתוך הפרוצדורה תבצע חיתוך לטבלת partspec:
    Part.part = partspec.part ואז
    תציג את עמודה spec18.

    בהנחה כמובן שאתה רוצה להציג את פרמטר 18 למוצר.

    yoram
    משתתף
    נכון. המלאי קיים במערכת עם הכמות שנארזה והסטטוס מקבל את מספר הלקוח(כלומר לא מלאי חופשי אלא מלאי "משוריין" ללקוח שעוברו נארז) .
    yoram
    משתתף
    תעודת האריזה מבצעת תנועת מלאי שמשריינת את המלאי ללקוח. יש לכך משמעויות רבות מבחינת מלאי זמין / ריצת mrp וכו. כמו כן זה מאפשר לארוז את המלאי אבל עדיין לא לשלוח אותו כלומר לגרוע את המלאי מהמערכת עד אשר באמת מבצעים משלוח. כמו כן ניתן לבצע בתעודה הערכת משקלים וכו. לא יודע מה אופי החברה שלכם על מנת לתת יותר פרטים.
מוצגות 15 תגובות – 16 עד 30 (מתוך 160 סה״כ)