בפוסט הקודם דנתי באפשרות לקשר מערכת מבוססת Access לשרת SQL ולהפעיל שגרות מאוחסנות (Stored procedures) הקיימות בו. בעוד שבפוסט הקודם התייחסתי לאפשרות שכל מסד הנתונים עובר לשרת SQL, בפוסט זה אתייחס למקרה שבו מעוניינים להמשיך ולהחזיק חלק מהטבלאות בקובץ ה-Access ולהעביר לשרת ה-SQL את שאר הטבלאות.
ובכן, הטכניקה שבה ניתן ליישם מנגנון גישה שכזה היא שימוש ב-ADO הישן והטוב. על-ידי שימוש מושכל בשיטה זו ניתן אפילו ליישם מנגנוני Caching פשוטים על מנת לשפר את זמני הביצוע, בדוגמה המצורפת תוכלו למצוא קובץ Access המכיל שני מודולים: DAL ו- GUI_HND, כפי שתוכלו לשים לב, פרט למקרו אחד (המשמש לביצוע פעולות בתגובה לאירועים שונים בממשק המשתמש) ולמודולים אלו אין בקובץ זה כלום, זאת משום שקובץ זה נסמך על קישור ל-DSN ב-ODBC ואשר דרכו הוא משיג גישה למסד הנתונים ולשגרות המאוחסנות בו.
להלן אופן הפעולה:
1. הקמת מסד הנתונים בשרת ה-SQL: שלב זה מתבצע בדיוק כמו שביצענו בפוסט הקודם ולכן לא אתאר אותו כעת.
2. הקמת DSN חדש המפנה למסד הנתונים שיצרנו:
3. קישור קובץ ה-Access שלנו אל מסד הנתונים: בדוגמה המצורפת בחרתי לבנות מודול מיוחד למטרה זו (DAL) ולאחזר את כל הרשומות המוחזרות מה-Stored procedure אל מערך דו ממדי ולהתנהל מולו בשלבים הבאים. הסיבה לבחירתי זו הייתה העובדה שמצד אחד לא מדובר בכמות גדולה של רשומות שיש לאחזר ומצד שני ייתכן ונידרש ליותר מגישה אחת אל הנתונים הללו ולכן במודול ה-DAL ניתן לנהל מעין מנגנון Cache פשוט על-ידי שמירת המערך שהוחזר למשך זמן מסוים מוגדר.
4. בניית מודול לבנייה דינמית של טופס על בסיס הנתונים: בדוגמה המצורפת בחרתי לבנות מודול מיוחד למטרה זו (GUI_HND) למרות שמדובר בדוגמה בחרתי להקים מודול נפרד למטרה זו ואני ממליץ גם לך לעשות זאת, שכן מודול שכזה מאפשר לך בהמשך לבנות יחסית בקלות ממשקי משתמש נוספים. בעת בניית האפליקציה ה-"מבצעית" אני בד"כ ממליץ על הקמת מודול נפרד לניהול הלוגיקה העסקית (BL), באופן כזה שינויים במודול אחד לא מחייבים שינוי במודולים אחרים (במרבית המקרים).
במידה ונרצה לאפשר למשתמש גם לעדכן נתונים בשדות שהוחזרו ניתן יהיה לעשות זאת באחת מ-2 דרכים:
1. עדכון ישיר בעבודה במוד Connectionful: לקשור לאירוע ה-AfterUpdate של תיבות הטקסט שבנינו הפעלה של מאקרו שיפעיל פונקציה אשר על בסיס מאפיין ה-ActiveControl תזהה את השדה שיש לשנות ותפעיל Stored Procedure אחרת לביצוע השינוי הדרוש. היתרונות של שיטה זו הם שהעדכון מתבצע באופן מיידי כמו גם שלא נדרשים פקדים (Controls) נוספים בטופס לצורך ביצוע הפעולה. החסרונות של אופן פעולה כזה הם הצדדים האחרים של היתרונות: עבודה באופן כזה תייצר כמות גדולה של מטלות עדכון שיישלחו לשרת ה-SQL ובכך עשויות לגרום לעומס הן בתקשורת לשרת והן על משאבי המעבד והזיכרון שלו.
2. עדכון בעזרת פקד נוסף במוד Connectionless: לבנות פקד נוסף (כפתור למשל) שבעת הפעלתו יישלח העדכון לשרת ה-SQL, בנוסף, ניתן להשתמש באירוע ה-AfterUpdate בכדי לסמן למשתמש (ע"י הצגת כוכבית למשל) כי הנתון טרם שונה בשרת וכי עדכונו יבוצע לאחר הפעלת הפקד הנוסף. אפשר גם להשתמש באירוע ה-AfterUpdate בכדי לבנות באופן מיטבי את השאילתה/הפניה ל-Stored Procedure שתשלח לשרת לאחר הפעלת הפקד הנוסף. החיסרון העיקרי של פתרון כזה הוא שבמקרה של נפילת מערכת במהלך עדכון השדות המשתמש יידרש להזין את כל הנתונים שנית שכן שום עדכון לא מבוצע בשרת עד להפעלת הפקד הנוסף. היתרונות של אופן פעולה שכזה הם רבים וכוללים בין השאר: חיסכון ניכר במשאבי רשת ומשאבי שרת (זיכרון, מעבד וכו'), עבודה מהירה יותר בצד הלקוח, אפשרות לציודי רשת שונים לזהות, לתעד ולאבטח תהליכי עבודה שלמים במקום פעילויות עדכון בודדות ללא כל הקשר כלשהו ביניהן. חשוב לשים לב שאת החיסרון של עבודה באופן פעולה כזה, כפי שצוין קודם, ניתן לפתור יחסית בקלות על ידי שמירה אוטומטית מתוזמנת של הנתונים שהוזנו בטופס האוטומטי (על-ידי אירוע ה-AfterUpdate) אל טבלה כלשהי (ב-Access או ב-SQL) אשר תחזיק את נתוני הטיוטה עד לסיום העדכון.
מתכנתים רבים שעברו לעבודה ב-ADO.Net לאחר שנים רבות של עבודה ב-ADO או ב-MS Access נרתעים מעבודה במוד Connectionless כפי שזו מיושמת ב-Dot Net שכן הם רואים בה אופן עבודה בזבזני משהו ובדרך כלל מגיעים למסקנה שתיאוריות לגבי שימוש בשכבות נכונות בתיאוריה בלבד, או כפי שהיטיב לנסח זאת ראש צוות פיתוח של חברה אליה הגעתי פעם לראיון: "שכבות מבחינתי יש רק בעוגת קרם". לכן, חשוב לי להסביר משהו לגבי אופן עבודה שכזה, זה אכן נכון שמשיכת כל הנתונים למערך (או ב-Dot Net אובייקט DataSet) היא פעולה שנראית לא יעילה, אך לאחר שמנתחים מערכות מידע רבות לעומק מתברר כי מערכות רבות נדרשות למעשה לגשת לאותם נתונים שוב ושוב כתוצאה ממגוון רחב של פעולות (אירועים שונים בממשק המשתמש כמו גם פעילויות ותתי פעילויות שונות הקשורות ללוגיקה העסקית של המערכת) וכתוצאה מכך, בעבודה מסורתית ב-ADO היה צורך בפתיחת חיבורים רבים לשרת מסד הנתונים. חשוב להבין שחיבור לשרת מסד נתונים מצריך משרת מסד הנתונים משאבים רבים ולכן, על מנת לחסוך בפניות לשרת מסד הנתונים קיים היגיון רב בהקמת שכבה נפרדת (בדמות DLL או Code Module) אשר רק היא תייצר את הפניות לשרת מסד הנתונים ושם יבוצע Caching לנתונים שכבר נמשכו על ידי חלקים אחרים של המערכת, כמו כן, שכבה זו תשתדל בעת משיכת הנתונים להשיג את מקסימום הנתונים האפשרי על מנת להימנע מהצורך למשוך אותם שנית. כמובן שחשוב להדגיש כי חשוב לשקול את הנושא בכל מערכת בהתאם לצורך שכן אין כלל זהב אחד המתאים לכל מערכת ויש לפיכך להתאים את הארכיטקטורה של המערכת לצרכים העסקיים המצופים ממנה.