תחומים - פורום חרדי מקצועי

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

@dovid מסתמא התכוונת ל-wellcom. גם אני הזמנתי מהם כמה פעמים, מחירים טובים ושירות מהיר.

שלום לכולם!
אז אחרי 9 שנים התנור Beko דו-תאי שלנו השמיע את חרחורי הגסיסה האחרונים שלו, ובסוף שחל"ח בשיבה טובה.
כעת אני מחפש המלצות לתנור חדש.
יש לי שני ספיקות:

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

@מיכאלוש פתח קובץ אקסס חדש > ותבחר לפי הסדר בתמונה:

בחלון שנפתח תנווט לשם הקובץ שלך, תבחר באפשרות הראשונה, ותלחץ על אישור:

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

דווקא כן, אלא שבגרסאות החדשות יותר הוא עם סיומת accde:

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

אמנם, מה שאתה כן יכול לעשות, זה לייבא ממנו את הטבלאות והשאילתות, (אם כאלו קיימות בו), לתוך קובץ אקסס עדכני.

@אליהו-בן נהדר!
אם תערוך את ההודעה הראשונה שלך (בתחילת השרשור) זה יאפשר לך לערוך גם את הכותרת, ולהוסיף את המילה 'נפתר' בהתחלה.

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

יש כמה הצעות לפיתרון, מהקל לכבד:

1. להוסיף את הכותרות הבאות לאובייקט כשאתה יוצר אותו, בתקווה שהשרת יכבד אותן:

    Set xhrRequest = CreateObject("MSXML2.XMLHTTP.6.0")
    xhrRequest.setRequestHeader "pragma", "no-cache"
    xhrRequest.setRequestHeader "Cache-Control", "no-cache, no-store"
   Do Until order.EOF
   ...

2. להשתמש באובייקט החלופי WinHttp.WinHttpRequest.5.1, שלא משתמש במטמון. שמות המתודות הנדרשות בו זהים לשמות שבאובייקט MSXML2.XMLHTTP.6.0, דהיינו:

Set httpRequest = CreateObject("WinHttp.WinHttpRequest.5.1")

Do Until order.EOF
'Url = "XXXXXXXXX?
httpRequest.Open "GET", url, False
httpRequest.Send
res = httpRequest.responseText

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

' תריץ את הפקודה הזו פעם אחת בתחילת ההפעלה של התוכנה שלך
Randomize
...
' ואז בקוד של השליחה

    ' יצירת מספר מ-1 עד 100000
    Dim dummyNumber As Long
    dummyNumber = Int((99999) * Rnd) + 1

    ' הוספת הפרמטר לבקשה
    xhrRequest.Open "GET", url, False & "&dummy=" & dummyNumber

4. אם כלו כל הקיצין: תוכל לנקות את המטמון לפני כל הפעלה (על ידי קריאה ל-API של Windows) וכך לכפות יצירת סשן חדש בכל פעם.
   תדביק את הקוד הבא במודול חדש:

Public Declare PtrSafe Function InternetSetOptionStr Lib "wininet.dll" Alias "InternetSetOptionA" (ByVal hInternet As Long, ByVal lOption As Long, ByVal sBuffer As String, ByVal lBufferLength As Long) As Integer

Public Sub ClearInternetCache()
    InternetSetOptionStr 0, 42, 0, 0
End Sub

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

    ClearInternetCache
    Set xhrRequest = CreateObject("MSXML2.XMLHTTP.6.0")
...

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

@אליהו-בן כתב במעונין בקוד לאקסס שירענן נתונים כאילו סגר את האקסס ופתח:

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

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

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

@dovid כתב בקיצורי מקלדת באקסס:

או להכניס את השורות האלה לתוך התנאי.

כך הייתי צריך לעשות באמת, תודה על ההערה, תיקנתי במקור.

@Y-Excel-Access כתב בc# שימוש שוטף בTry/Catch:

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

אם לא התכוונת בפירוש שזה יקרה - זה בעצם באג.

ולמה לשחרר ללקוח מוצר לא מושלם? כי לפעמים זה יעלה לו הרבה פחות שעות פיתוח

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

@Y-Excel-Access מסתמא הRECORDSET עובד בדיוק כמו שהוא אמור לעבוד. השאלה היא מה אמרו לו לעשות... מה הכוונה במילים:

והכל עבד רק השרת פשוט לא עונה תשובה.

לא חזר כלום? חזרה אותה התגובה? חזרה שגיאה?
מתי יבוא אליהו ויתרץ?

@mekev יש הרבה מה לומר בנידון, הנה כמה נקודות:

1. רצף - זה שובר את רצף הריצה של התכנית, מעין GOTO בתחפושת, לעיני המתכנת זה מקשה מאוד על ההבנה של הקוד.
2. תחזוקה - זה מאוד מקשה על הדיבוג, בפרט בקוד אסינכרוני, חריגה יכולה לצוץ בלי שיהיה לך מושג מה גרם לה.
3. חוסר יעילות - חריגה מבזבזת משאבים מיותרים. גם אם אתה תופס אותה.
4. הסתרת באגים - אם אתה לא באמת מתכוון לטפל בשגיאה, כלומר לא רק להתעלם ממנה, אלא לעשות איתה משהו שימושי: כתיבה ללוג, התאוששות מהשגיאה על ידי בקשת קלט נוסף וכו' וחזרה למסלול הריצה הסדירה של התוכנה - השימוש ב Try/Catch לעתים קרובות נובע מחוסר ידע או מעצלות. מה שיגרום שבתוכנה יהיה את הסוג הכי בעייתי של באגים - כאלו שאף אחד לא שם לב אליהם בזמן, כי הקוד נראה כאילו הוא עובד תקין... (מכיר את המשל על מי שעקר את נורת האזהרה מלוח השעונים כי היא הפריעה לו?)
   במלים אחרות: בעת הפיתוח - אתה בעצם כן רוצה להבחין בכל החריגות ולשכתב את הקוד שלך כך שהם פשוט לא יווצרו.

חפש Why you should avoid try catch לעוד מראי מקומות מפורטים.

@Y-Excel-Access ההסבר שהצעת לתופעה, שיש דחייה על ידי השרת של בקשות תדירות של נתונים דומים, לא מסביר מדוע סגירה ופתיחה מחדש של אקסס - כן מועילה? לכן חשבתי שהבעייה היא בעדכון של הנתונים הקיימים באקסס.
אגב, הבקשה היא GET ולא אמורה להעלות נתונים לשרת, רק למשוך ממנו.

@mekev בוא נעשה סדר. אני מנסה להבין מה בדיוק קורה כאן, נוסח השאלה שלך מעורר בי כמה תמיהות:

1. אתה מעוניין שאם יש ערך כלשהו בשדה בדאטא - לא יבוצע עדכון? תקרא את הערך ותבדוק אם הוא מכיל משהו.
2. אתה מעוניין למנוע מצב שבו שני משתמשים מנסים לכתוב בו זמנית לאותו שדה? זו בפירוש אחריות שמוטלת על ה-DB ולא צריכה להיות מנוהלת על ידי הקוד בתוכנה.
3. אפשר להשתמש ב-TryParse שלא זורק חריגה במקרה של כישלון המרה.
4. באופן כללי אתה צודק שאין לחזור על עצמך בקוד. אתה אמור להפוך את תהליך הבדיקה לפונקציה בפני עצמה, ולקרוא לה 10 פעמים, לא לחזור על הקוד 10 פעמים.
5. באופן כללי, נסה להמנע מלהשתמש ב-Try/Catch ככל האפשר. ברוב המוחלט של המקרים, יש דרך למנוע את החריגות מעיקרא, על ידי תכנון יותר טוב.

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

@אוריי התשובה שנתת שיש מזהה של תורם - לכאורה לא מספקת. אם יש שתי תרומות שונות לאותו תורם -הם ייחשבו בטעות כתרומה כפולה.

@אוריי האם זה אפשרי לזהות את התרומות הכפולות? לפי מה?

@אוריי לא הבנתי מה הקושי. אולי תוכל לפרט יותר את התרחיש שלך?

@אליהו-בן הקוד שצירפת מבצע בקשות GET לשרת אלמוני X, על פי רשימה מתוך הטבלה שנפתחת כ-order. במקרה שהנתונים בשרת X השתנו, (ובהנחה הפשוטה שאין איזה שירות cache מקומי פעיל), אתה אמור לקבל תוצאות עדכניות בכל פעם.

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

האם אני צודק?

@אוריי בתחבולות...

Replace ("Oded's example", "'","")
' --->  Output:   Odeds example
Replace ("Oded""s example", """","")
' --->  Output:   Odeds example