מעבר מ-Access לאתר: איך מחליפים מערכת בלי לשבור את התהליך שמסביב

החלק המסוכן בעזיבת Access הוא לרוב לא הטבלאות. הוא כל מה שמחובר לקובץ מסביב: מיזוג הדואר ב-Word, מדפסת המדבקות, הייצוא החודשי שרואה החשבון מצפה לו, והשאילתה שמישהו מריץ כל יום ראשון. תוכנית שמעבירה רק נתונים שוברת את העסק בשבוע העלייה לאוויר.

ממפים את התהליך, לא רק את בסיס הנתונים

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

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

באיזה סדר מחליפים?

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

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

שלב 1: הנתונים עוברים, המסכים נשארים

זהו הצעד עם היחס הטוב ביותר בין הפחתת סיכון למאמץ, והוא לא נוגע בלוגיקה העסקית. SSMA - SQL Server Migration Assistant for Access - הוא כלי חינמי ונתמך של מיקרוסופט שממיר את אובייקטי Access ומעביר את הנתונים ל-SQL Server או ל-Azure SQL. סימון האפשרות לקישור טבלאות גורם לו לקשר את הטבלאות בחזרה לקובץ Access בסיום, כך שהמסכים הקיימים ממשיכים לעבוד מול השרת.

שתי נקודות טכניות ששוות תשומת לב מראש:

• בהעברה ל-SQL Server 2016 ואילך, כדאי להוסיף עמודת rowversion לטבלה מקושרת שצריך לעדכן. Access משתמש בשדה הזה כדי לזהות מתי הרשומה עודכנה לאחרונה.
• כברירת מחדל SSMA לא שומר את פרטי ההתחברות במחרוזת החיבור, ולכן צריך להחליט מראש איך המשתמשים מתחברים.
• אחרי המעבר, מגבלת 2GB של פורמט Access חלה רק על קובץ החזית, שמכיל מעכשיו טפסים בלבד.

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

להריץ שתי מערכות בלי שתי אמיתות

הכשל הנפוץ בהרצה מקבילה הוא שכל צד כותב לעותק משלו, ואז מנסים "לסנכרן". שלושה כללים מונעים את זה:

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

בפועל הבדיקה היומית היא שתי שאילתות: כמה רשומות נוצרו אתמול בכל ישות, ומה סכום השדה הכספי המרכזי שלהן. שתיהן רצות על אותו בסיס נתונים, ולכן הן לא אמורות להיפרד לעולם. ברגע שהן נפרדות, מצאתם כתיבה שממשיכה מהצד שכבר היה אמור להיות קורא בלבד - וזה הכשל הנפוץ ביותר בהרצה מקבילה.

מה קובע את תאריך המעבר?

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

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

מה משתבש בחודש השלישי

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

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

בהקשר רחב יותר, אותה החלטה מתעוררת גם במעבר מגיליונות - ראו מתי גיליון גדל מעבר לגודלו.

מקורות

• Migrate an Access database to SQL Server - Microsoft Support
• SQL Server Migration Assistant for Access - Microsoft Learn