Forum Replies Created
- Replies
-
- מאי 18, 2022 בשעה 7:05 pm
- in reply to: פרוצדורה עם HTMLCURSOR
תודה, הסתדרתי. כתבתי ככה./*———————————————————–*/
:PART = :SERN = 0;
SELECT PART INTO :PART FROM PART WHERE PARTNAME = :$.PRT;
/*———————————————————–*/
LINK SERNUMBERS TO :$.PAR;
GOTO 888 WHERE :RETVAL <=0;
SELECT SERN INTO :SERN FROM SERNUMBERS WHERE PART = :PART;
UNLINK SERNUMBERS;
LABEL 888;
/*———————————————————–*/
SELECT SQL.TMPFILE INTO :$.PAR FROM DUMMY;
LINK SERNUMBERS STK TO :$.PAR;
GOTO 999 WHERE :RETVAL <=0;
INSERT INTO SERNUMBERS STK
SELECT * FROM SERNUMBERS ORIG WHERE SERN = :SERN;
UNLINK SERNUMBERS STK;
LABEL 999;
/*———————————————————–*/- התגובה הזו עודכנה לפני לפני 2 שנים, 6 חודשים ע"י PriorityDev.
- התגובה הזו עודכנה לפני לפני 2 שנים, 6 חודשים ע"י PriorityDev.
- מאי 18, 2022 בשעה 6:46 pm
- in reply to: פרוצדורה עם HTMLCURSOR
ניתן לקבוע ערך חדש ב-PAR וה-HTMLCURSOR יתיחס לערך החדשיצחק,
למה התכוונת? תוכל לתת דוגמת קוד?
- מאי 17, 2022 בשעה 9:35 am
- in reply to: פרוצדורה עם HTMLCURSOR
אתה צודק יצחק.אבל כאן כמדומני ה-HTMLCURSOR מקבל רק את ה-PAR המקורי ואי אפשר למסור לינקוק אחר.
מצד שני אם אני בודק מייד אחרי הלינקוק האם הלינקוק בוצע (ואם לא בוצע – מפסיק את התוכנית או מדלג על המחיקה) – לכאורה אין סכנה.
- מאי 17, 2022 בשעה 2:35 am
- in reply to: פרוצדורה עם HTMLCURSOR
לא יודע אם עדיין רלוונטי לפותח הנושא, אבל יכול להועיל למחפשים בעתיד.אפשר להוסיף שלב SQLI בין ה-INPUT ל-HTMLCURSOR.
לשלב זה יש למסור גם את הפרמטר PAR וגם את הפרמטר הנוסף שלפיו רוצים לסנן את הטבלה של PAR.
מלנקקים את הטבלה הרלוונטית ל-PAR ומוחקים מהטבלה המלונקקת ב-DELETE את הרשומות הלא רלוונטיות (כאן אפשר חופשי לבצע חיתוכים ע"י כל פרמטר נוסף).
לאחר מכן ה-HTMLCURSOR יתייחס לפרמטר PAR עם השינויים שבוצעו ולא כפי שנקלט ב-INPUT.
- פברואר 18, 2020 בשעה 12:23 pm
- in reply to: עיצוב שדות במסך מותאם
מסך האב והבן הם במצב שליפה.מסך הנכד (שעליו רוצים לעשות עיצוב שדות) – מצב כתיבה.
רק קבוצת משתמשים מסוימת לא מסוגלת לבצע עיצוב שדות על המסך הנ"ל (לקבוצה זו יש הרשאת כתיבה על המסך הנ"ל).
גם קבוצה זאת יכלה לבצע עיצוב שדות על המסך הנ"ל עד שביצעתי שינוי קטן במסך (השינוי הוא: הפיכת שדה מ-Read ל-Write והוספתו בטריגר המעדכן טבלת המשך).
- נובמבר 12, 2019 בשעה 10:15 am
- in reply to: המרת DATE14 ל-DATE8
תמיד הייתי עושה כך:
SELECT ATOD(DTOA(SQL.DATE,'DD/MM/YY'),'DD/MM/YY') FROM DUMMY FORMAT;- נובמבר 6, 2019 בשעה 5:15 pm
- in reply to: עריכת קוד פריוריטי בNotepad++
NoamN: לאחר ש"נשרפתי" עם בעיית העברית לפני כמה שנים, אני תמיד מטעין מחרוזות בעברית באמצעות ENTMESSAGE ואף פעם לא כותב עברית גלויה בפרוצדורות.
+1000000!
ENTMESSAGE זה הפתרון.
- מרץ 26, 2019 בשעה 6:41 pm
- in reply to: הרצת BACKFLUSH מטריגר של מסך
איזו מלחמה, חבר? רק דנים דיון מקצועי.למה החלטתי שהפתרון שלך לא טוב – כבר הסברתי:
1. היום התפעול עובד עם פק"ע אחת ורואה שם את כל התנועות. אתה מציעה להכריח אותם לשנות את סדרי העבודה, לפתוח פק"ע נוספת ולתחזק את שתיהן.
2. בשביל לראות התנהלות מול קב"מ בכל פרויקט, יצטרכו לעקוב בשני מקומות במקום 1.
3. יהיה צורך לשנות את הדו"חות (כולל BI) שמותאמים היום לתהליך הקיים, ומאידך – עדיין לתחזק דו"חות שמסתכלים על פרויקטים שלפני השינוי. קרי – חוסר עקבות אחורה + צורך בהרבה פיתוח.
3. בפתרון שלך המלאי לא מתעדכן, וזה לא נכון. המלאי צריך להתעדכן. כל הפרויקטון הזה התחיל מהבעיה שהמלאים לא התעדכנו נכון. ואתה מציעה פתרון שלא יעדכן מלאי בכלל.
כלומר, יש תהליך פשוט שעובד מצויין, רק חסר 10% לתוצאה הרצויה, שאפשר להשלים את ה-10% ע"י פיתוחון פשוט.
ואתה מציע לשנות את כל התהליך כאשר הדבר יגרום שיהיה חסר 80% לתוצאה הרצויה + יגרום בעיות נוספות + יצור צורך בפיתוח הרבה יותר מסיבי.לעומת זאת נתתי פתרון שהשקעתי בו שעתיים (עם פיתוח שלא משנה את הסטנדרט של פריוריטי, אלא רק משלים חוסר בתהליך הסטנדרטי, כאשר אשבל מודים שיש כאן בעיה בסטנדרט) , וכל התהליך נשאר שקוף ואחיד כפי שהיה.
אז איזו דרך היא באמת קלה ופשוטה? ובלי הרבה פיתוחים? והעיקר – נכונה?
שום דבר אישי, רק דיון מקצועי.
- מרץ 26, 2019 בשעה 4:48 pm
- in reply to: הרצת BACKFLUSH מטריגר של מסך
אני דוגל בפתרון שפותר את הבעיה עם כמה שפחות שינויים בתהליכים סטנדרטיים וכמה שפחות להרבות בישויות ומסמכים מיותרים.
אם יישום עונה על זה – מצוין.
אם פיתוח עוזר יותר טוב – צריך לפתח, בלי תאוריות.במקרה הנ"ל הפתרון פותר את הבעיה מצוין ומבחינת המשתמשים לא השתנה כלום.
אוי ואווי אם מישהו היה עכשיו משנה את כל סידרי העבודה בתפ"י/ייצור/רכש, הורס עקבות אחורה, גורם לעיוותים במלאים רק בגלל שהוא "דוגל בפתרונות יישומיים".- מרץ 26, 2019 בשעה 4:11 pm
- in reply to: הרצת BACKFLUSH מטריגר של מסך
לא יודע מה זה נקרא אצלך יותר מדי פיתוח.
לי לקח כשעתיים-3, בלי להרבות בפק"עות מיותרות.
וכן, המלאי חייב להשתנות.
מה שנשלח בחזרה לספק, צריך לרדת ממלאי שלנו, וכשהתקבל שוב – צריך לחזור.כך שהפתרון שלך נשמע כמו יותר מדי יישום (שדורש מהפכה בתהליכי תפעול) שבסוף לא עושה את מה שאנחנו צריכים.
יתרה מזו, הפתרון שלי הוא הנכון יישומית ומערכתית – יש לי על זה תשובה רשמית של מידעטק ופריוריטי סופטוור.
ואת החוליה החסרה שאני נאלצתי לפתח, הם הכניסו לתוכנית פיתוח לגרסה הבאה.- מרץ 26, 2019 בשעה 2:12 pm
- in reply to: הרצת BACKFLUSH מטריגר של מסך
נעם-גלובל כתב:אני מצטרף לדעה של שוגי. יש טעם להריץ BF רק כאשר יש הצטברות דיווחי יצור, וכמובן תלוי באיך אתם מגדירים/מתיחסים אל "REAL TIME" אצלכם.
אצלי REAL TIME = יום, כך אין סיבה להריץ את BF יותר מפעם ביום. אם אצלכם RT = שעה, אז יש הצדקה להריץ (דרך TTS) פעם בשעה.
OK, כנראה שאני צריך להסביר את הצורך שלי (אגב, את הפתרון כבר יישמתי והוא עובד).
ה-BF אצלנו רץ פעם ב-12 שעות, וזה בסדר.יש כרגע בעיה נקודתית:
פותחים פק"ע + הזמנת רכש לקב"מ.
כשמקבלים סחורה לקב"מ, נוצר דיווח בפק"ע המקושרת להזמנה.
כשמחזירים סחורה לקב"מ (נגיד בגלל פסילת איכות), זה מטפל במלאים וביתרות בהזמנה, אבל לא בדיווחים בפק"ע.
אשבל כבר הכניסו את זה לתוכנית פיתוח עתידית שלהם, אבל כרגע הפתרון שהם מציעים הוא לעשות קבלת סחורה מספק במינוס.הפתרון הזה אכן עובד, אבל יש 2 בעיות:
1. אם הפק"ע הייתה סגורה, היא לא נפתחת בחזרה.
את הבעיה הזו פתרתי בקלות ע"י הרצת ממשק מהטריגר.
2. נוצר מלאי לא מקוזז, כלומר, המערכות המיוצרות נגרעות מהמלאי, אבל רכיבי הניפוק מגיעים למלאי רק אחרי הרצת BF.
לכן עלה צורך להריץ BF בו בזמן.
ואני דווקא לא מחפש להריץ BF בתדירות גבוהה, אלא רק מתי שצריך (קבלת סחורה מספק במינוס לא קורת הרבה).
אכן פתרתי את הבעיה כפי שתיארתי כאן:
https://www.priority-forums.com/he/index.php/forums/6-%D7%90%D7%A4%D7%99%D7%95%D7%9F-%D7%95%D7%A4%D7%99%D7%AA%D7%95%D7%97-%D7%A4%D7%A8%D7%99%D7%95%D7%A8%D7%99%D7%98%D7%99/21493-%D7%94%D7%A8%D7%A6%D7%AA-BACKFLUSH-%D7%9E%D7%98%D7%A8%D7%99%D7%92%D7%A8-%D7%A9%D7%9C-%D7%9E%D7%A1%D7%9A#21510- מרץ 25, 2019 בשעה 11:59 pm
- in reply to: הרצת BACKFLUSH מטריגר של מסך
yitzchok כתב:שקול גם EXECUTE BACKGROUND
אולי גם ACTIVATE במקום WINACTIVניסיתי EXECUTE BACKGROUND.
מקבל הודעת שגיאה:
"ברגע זה מתבצע חישוב מלאי, ולכן לא ניתן לרשום תנועות."בינתיים עשיתי כפי מה שרציתי. זה עובד מצוין.
תודה, יצחק.
- מרץ 25, 2019 בשעה 11:56 pm
- in reply to: הרצת BACKFLUSH מטריגר של מסך
yitzchok כתב:אם אני לא טועה באחת הגרסאות האחרונות אמרו ש-backflush כבר לא אמורה להפריע לעבודה. כדאי לבדוק.
בדקתי. כן מפריע. תוקע את המסך עד סוף הריצה.
גרסה 18.1- מרץ 25, 2019 בשעה 11:47 pm
- in reply to: הרצת BACKFLUSH מטריגר של מסך
yitzchok כתב:michaelm כתב:
[quote]הודעת שגיאה.
"D:\tmp/file.in", line 1: parse error at or near symbol BACKFLUSH_ONACCBALנכון
אני שם לב עכשיו שחסר לך פסיק אחרי ה 'P-'שלוף דוגמאות דרך windbi ותראה[/quote]
צודק, פיספסתי פסיק.
עכשיו עובד.- מרץ 25, 2019 בשעה 10:37 pm
- in reply to: הרצת BACKFLUSH מטריגר של מסך
בהתחשב במה שנעם כתב שזה יגרום להמתנה ארוכה במסך, אני חושב לעשות את זה אחרת:1. אבנה פרוצדורה על בסיס BACKFLUSH_ONACCBAL, רק שהיא בודקת קבוע מערכת (שאגדיר אותו) שיש בו דגל ורצה רק כשהדגל מורם.
2. אריץ ב-TTS את הפרוצדורה החדשה (כל 10 דקות) בדומה להרצת BACKFLUSH_ONACCBAL.
3. ארים את הדגל מהטריגר במסך לפי הצורך, ובסוף ריצת הפרוצדורה אוריד אותו.זה יפתור לי גם את בעיית הפרעות למשתמש המסך וגם את בעיית הסינטקס.
מה אתה אומר, יצחק?