yitzchok

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

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

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

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

עמרי

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

ניתן לשלב תת-שאילתא בתנאי

מציע להוסיף למסך עמודת DUMMY.DUMMY כעמודה נסתרת ולקבוע בה תנאי ששווה ל-1 ואז AND וכו'

אבל אם השאילתא שלך פשוטה ומחזירה PART בלבד מספיק תנאי על PART.PART בעזרת IN.

<p dir="ltr">There is a standard procedure which is in the TTS configuration (although perhaps not enabled) which records that it was run, and when, I think in the LASTS table (you can check that by looking in the code).</p>
<p dir="ltr">Of course, to tell you if something's running you need something else to run, to do the check.</p>
<p dir="ltr">Your problem is probably that the TTS service is supposedly running but it's not actually doing anything, so looking at the status of the service with Windows tools isn't a solution.</p>
<p dir="ltr">When I contended with this in the past I set up an SQL Server Agent job which looked at the record which the above procedure updates, and if the time was further in the past than the interval I had defined it would notify me. But you could also run a Powershell script from the Windows task scheduler or use any other tool you like which can read from the database.</p>

היבטי רישוי אולי

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

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

אני נורא רוצה לשחזר את זה ולחקור אבל לא רואה שיש לי את הזמן הנדרש.

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

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

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

 

כנראה "לזה" אתם כן מתכוונים.

יש לי מחויבות מקצועית לחזור ולדגיש:

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

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

(בהערת אגב אגיד שעכשיו שפירטת, ברור שמה שכתב babun רומז לפתרון. אילו היה מתאים לבצע עדכון ב-UPDATE זה יהיה די פשוט כי אתם רוצים לעדכן את כל השורות ברלוונטיות באותה צורה)

בסופו של דבר, אתם רוצים לעבור על לקוחות בהם במסך "חשבון/כרטיס אשראי לחיוב" יש Y ב-"אישור משב"א" , ולקבוע 5 בקוד תשלום באותו מסך?

הייתי תוקף את זה ככה (ואם יש משהו מוכן יותר אני מתנצל, אני לא מכיר):

תבנה ממשק מסך שטוען מקובץ עם FNCCUST ב-RECORDTYPE 1 ו-PAYMENTDEF ב- RECORDTYPE 2, בשורה של FNCCUST תקבע CUST (או CUSTNAME לדעתי שניהם אפשריים) בשורה של PAYMENTDEF תקבע PAYMENTCODE

אז תכין קובץ עם שורות רלוונטיות. או שאילתא פשוטה שמוציא את הלקוחות המסומנים ע"י חיתוך בין CUSTOMERS ו-PAYMENTDEF (כאשר TYPE שווה ה-EXTTYPE של CUSTOMERS) ותכין את הקובץ באקסל בו תיסוף LINE ו-RECORDTYPE וגם שורה אחרי כל שורה עם ה-PAYMENTCODE

או שאילתא יותר מורכב עם קורסור על בסיס אותו שאילתא, שיכתוב את כל הקובץ כמו שצריך בבת אחת

לצערי אין תמיד פתרון קל לעדכון גורף