Access מציג Unrecognized Database Format: מה לעשות ומה בשום אופן לא

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

מה ההודעה בעצם אומרת?

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

| התרחיש | הסימן | הכיוון | |---|---|---| | פער גרסאות | הקובץ נפתח במחשב אחר | להתקין גרסה מתאימה או להמיר במחשב שכן פותח | | קובץ פגום | לא נפתח בשום מחשב | שחזור מגיבוי, ואז Compact and Repair על עותק | | סיומת שגויה | הקובץ הועתק או שונה שמו ידנית | לבדוק מקור, לא לשנות סיומת בתקווה | | קובץ נעול | קיים קובץ `.laccdb` פעיל | לוודא שאף אחד לא מחובר לפני טיפול |

סדר הפעולות לשחזור

1. סגרו את הקובץ אצל כל המשתמשים ואל תפתחו אותו שוב.
2. העתיקו את הקובץ למקום אחר. כל העבודה מכאן היא על העותק.
3. בדקו אם קיים גיבוי אחרון תקין - הוא כמעט תמיד המסלול המהיר והבטוח.
4. נסו לפתוח את העותק במחשב עם גרסת Access אחרת, כדי לזהות אם זו בעיית גרסה.
5. רק אחרי גיבוי, הריצו Compact and Repair על העותק.
6. אם השחזור הצליח חלקית, ייצאו את הטבלאות למסד נתונים חדש במקום להמשיך לעבוד בקובץ הפגוע.

למה זה חוזר שוב ושוב

תקלה חד-פעמית קורית. תקלה שחוזרת מצביעה כמעט תמיד על אחד מאלה:

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

מתי זו כבר לא תקלה אלא החלטה

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

1. פיצול ל-front end ו-back end כפתרון מיידי שמקטין נזק.
2. העברת הנתונים ל-SQL Server, כשה-Access נשאר בינתיים כממשק.
3. החלפת המסכים בהדרגה, מודול אחר מודול, לפי מה שהכי כואב.

איך מפצלים ל-front end ו-back end

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

1. גבו את הקובץ הקיים.
2. צרו קובץ חדש שיכיל רק את הטבלאות - זהו ה-back end. הוא יושב על השרת או התיקייה המשותפת.
3. הקובץ המקורי, עם הטפסים, השאילתות והדוחות, הופך ל-front end. מוחקים ממנו את הטבלאות ומקשרים אותן מה-back end כטבלאות מקושרות.
4. לכל משתמש עותק משלו של ה-front end, מקומית על המחשב שלו. זו הנקודה שרוב האנשים מפספסים, וזו כל הפואנטה.
5. גיבוי אוטומטי של ה-back end בלבד, בתדירות שמתאימה לקצב העבודה.

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

סימנים שהקובץ מתקרב לגבול

פורמט Access מוגבל ל-2GB לקובץ. הרבה לפני שמגיעים למספר הזה מופיעים סימנים:

• הקובץ תופח במהירות ומצטמצם דרמטית אחרי Compact - סימן לכתיבה ומחיקה אינטנסיביות.
• פעולות שהיו מיידיות לוקחות שניות.
• נעילות תכופות בין משתמשים על אותה טבלה.
• דוחות שנופלים רק על טווח תאריכים רחב.

כשמופיעים שניים מאלה יחד, העברת הטבלאות ל-SQL Server היא לרוב זולה יותר מהמשך התחזוקה.

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

מקורות

• Microsoft Support - Access