מחיקת פרמטר שנשלח ב read
-
@amp-Software-0 אמר במחיקת פרמטר שנשלח ב read:
בדיקה אם המשתמש כבר הקיש ערך ב approval
אז למה שלא תעשה לכל approval,read נפרד?
-
@לעזור-לכולם
אתה צודק, זה אחד הקומבינות שעשיתי. זה אמנם עונה על הבעיה שהצגתי לעיל, אבל לא פותר אותה באופן מלא.
עדיין תשאר הבעיה באותו read בעצמו, כלומר באותו מוצר ממש.
נגיד אם הוא הקיש כמות חריגה במוצר 004 ורוצה לתקן, אז אני שולח לו שוב read לקבל כמות מוצר 004, עכשיו כעת אחרי שהוא הקיש את הכמות והיא שוב פעם חריגה אין לי אפשרות לוודא את זה מולו, כי כבר קיבלתי את ה approval למוצר הספציפי הזה... -
@avrham אמר במחיקת פרמטר שנשלח ב read:
@amp-Software-0 אוקיי, אז ברגע שנתקבל מידע מימות ב read תשמור אותו במשתנה/ קובץ אחר. ואז תקרא לו . מה הבעייה?
כי המשתנה ימחק
הרי בכל read מתבצעת קריאה מחודשת לשרת, ככה שהמשתנים מתאפסים
האפשרות היחידה זה לאכלס את זה ב db (ליצור טבלה שמכילה את כל החיוגים, ולאחסן את הפרמטר ברשומה של השיחה לפי מזהה השיחה), זה גם אפשרות שעשיתי פעם. כמובן שזה קובמינה מאוד לא נוחה, ולא תקינה.. -
@amp-Software-0
עריכה טעיתי
כמובן גם לזה אפשר לעשות קומבינה
אבל באמת עדיף שימות יסדרו את זה -
למה שלא תקרא לזה approval-004?
-
@amp-Software-0 אמר במחיקת פרמטר שנשלח ב read:
עדיין תשאר הבעיה באותו read בעצמו, כלומר באותו מוצר ממש.
נגיד אם הוא הקיש כמות חריגה במוצר 004 ורוצה לתקן, אז אני שולח לו שוב read לקבל כמות מוצר 004, עכשיו כעת אחרי שהוא הקיש את הכמות והיא שוב פעם חריגה אין לי אפשרות לוודא את זה מולו, כי כבר קיבלתי את ה approval למוצר הספציפי הזה... -
@לעזור-לכולם אמר במחיקת פרמטר שנשלח ב read:
@amp-Software-0 אמר במחיקת פרמטר שנשלח ב read:
עדיין תשאר הבעיה באותו read בעצמו, כלומר באותו מוצר ממש.
נגיד אם הוא הקיש כמות חריגה במוצר 004 ורוצה לתקן, אז אני שולח לו שוב read לקבל כמות מוצר 004, עכשיו כעת אחרי שהוא הקיש את הכמות והיא שוב פעם חריגה אין לי אפשרות לוודא את זה מולו, כי כבר קיבלתי את ה approval למוצר הספציפי הזה...OK.
@amp-Software-0
בשביל זה אפשר לעשות בדיקה אם approval-004 קיים כבר תקרא לו approval-004-0\1\2 וכו' ותתיחס בתכלס רק למספר הכי גבוהה -
-
@MGM-IVR אמר במחיקת פרמטר שנשלח ב read:
@לעזור-לכולם אמר במחיקת פרמטר שנשלח ב read:
@amp-Software-0 אמר במחיקת פרמטר שנשלח ב read:
עדיין תשאר הבעיה באותו read בעצמו, כלומר באותו מוצר ממש.
נגיד אם הוא הקיש כמות חריגה במוצר 004 ורוצה לתקן, אז אני שולח לו שוב read לקבל כמות מוצר 004, עכשיו כעת אחרי שהוא הקיש את הכמות והיא שוב פעם חריגה אין לי אפשרות לוודא את זה מולו, כי כבר קיבלתי את ה approval למוצר הספציפי הזה...OK.
@amp-Software-0
בשביל זה אפשר לעשות בדיקה אם approval-004 קיים כבר תקרא לו approval-004-0\1\2 וכו' ותתיחס בתכלס רק למספר הכי גבוההאתה צודק זה רעיון מצויין
[אני חשבתי לעשות approval-004-20 כלומר להכניס את הכמות שהוא הקיש ביחד עם המוצר, הבעיה אם הוא יקיש אותה פעם נוספת... (למרות שאם הוא יקיש 1 הוא יעבור, אבל למקרה שהקיש 2 ואז התחרט)
בפתרון שלך זה פותר גם את זה] -
@מנסה אמר במחיקת פרמטר שנשלח ב read:
איפה אתה שומר את המוצרים שהוא מזמין תוך כדי שיחה?
[אולי תוכל לשחק אם שלוחות]
בדאטה בייס חיצוני
כל בחירה של כמות נרשם מיידית ב db -
@amp-Software-0 להבנתי הפתרון הכי נכון הוא שיהיה אפשר להגדיר בשלוחה/תגובת שרת שהערך הקודם יידרס.
זה מצריך פיתוח מצד ימות המשיח
מציע לך לפנות במייל ולבקש הצעת מחיר ו/או לפתוח שרשור חדש ב"הצעות לפיתוח" -
@amp-Software-0 אמר במחיקת פרמטר שנשלח ב read:
לצורך זה רציתי אפשרות לשדר לימות שימחקו את הפרמטר הזה, שלא ישלחו לי אותו שוב, ואז בפעם השניה שאני יבקש אותו הבדיקה תהיה באמת אפקיטיבית אם הוא כבר הקיש או לא
@eliyahu זו המסקנא שגם אני הגעתי אליה, אבל כתבתי כאן למקרה ואולי יש למישהו פתרון פשוט יותר, כמו שבאמת הציעו כאן כמה
-
אתה יכול [אולי] לעשות שאת אישורי הכמות החריגה יהיה בשלוחה אחרת, [זאת אומרת שזה יעביר אותו לשלוחה ששואלת האם לאשר או לא, ולפי התשובה שם תטפל בנתונים שבDB שלך
אח"כ תחזיר אותו לשלוחה הרגילה מהמקום בו הוא נמצא [אם זה שייך אצלך, תלוי בצורת התקשור]
-
הוזכר על-ידי ל לעזור לכולם
-
הוזכר על-ידי C Chaim