إطالة عمر تطبيقات VB6 / Access الخاصّة بالأعمال وترحيلها ── جدول قرار الإبقاء والتغليف والاستبدال

«جزء من النظام الأساسيّ لا يزال يعمل وهو مكتوب بـVB6» أو «السجلّ الذي أُنشئ بواسطة Access يدعم فعليّاً عمل أحد الأقسام» ── هاتان الحالتان لا تزالان تظهران بتردّد مرتفع جدّاً في استشارات الشركات الصغيرة والمتوسّطة. القاسم المشترك بينهما أنّ الشخص الذي أنشأهما قد ترك العمل بالفعل، أو أنّه لم يعد بإمكان أحد شرح سبب استمرار عملهما بدقّة. ومع ذلك، فبما أنّهما لا يزالان يعملان دون أعطال، تميل الأولويّة دائماً إلى التراجع.

كتبنا سابقاً على هذه المدوّنة عن عناصر تقنيّة منفردة، مثل ما هي COM / ActiveX / OCX، وكيف تتعامل مع ActiveX / OCX اليوم، وما هو VBA. في هذا المقال، نضيّق النطاق ونجمع دليلاً عمليّاً لتحديد «هل نُبقي الأمر كما هو» أو «نُغلِّف جزءاً منه فقط لإطالة عمره» أو «نستبدله»، بشأن أصلَين ضخمَين من التقنيات القديمة لا يزالان منتشرَين بكثرة اليوم في الشركات اليابانيّة الصغيرة والمتوسّطة ── تطبيقات VB6 وتطبيقات Access التجاريّة. يتّبع نمط القرار هنا الاختيارات الثلاثة نفسها المستخدمة في مقال ActiveX / OCX، وهي «الإبقاء، التغليف، الاستبدال»، لكن بما أنّ الهدف يختلف فإنّ طبيعة المخاطر تختلف أيضاً، لذا سنركِّز على النقاط الخاصّة بهذا المقال.

1. أولاً، الخلاصة

• انتهى الدعم الرسميّ لبيئة تطوير VB6 (IDE) نفسها في أبريل 2008. لم تعد هناك وسيلة رسميّة لإجراء تطوير جديد أو تعديلات.¹
• في المقابل، تعمل بيئة تشغيل VB6 (مثل msvbvm60.dll) طوال فترة دعم إصدار Windows الذي تُشحَن معه. لا يزال الافتراض القائل بأنّ «تطبيقات VB6 القائمة تستمرّ غالباً في العمل على إصدارات Windows المدعومة» صحيحاً حتى الآن، لكنّه يبقى تابعاً بالكامل لفترة دعم Windows نفسها.¹
• VB6 مخصّص لـ32bit فقط، ولا يمكن ترجمته أصليّاً (native) إلى 64bit. يعمل على أنظمة التشغيل 64bit داخل بيئة توافق 32bit تُسمّى WOW64.¹ وبمجرّد ظهور الحاجة إلى التكامل مع DLL أو SDK أو مكوّنات COM مخصّصة لـ64bit، لا يعود بالإمكان إنجاز الأمر داخل عمليّة واحدة فقط.
• «محرّك قاعدة بيانات Access (ACE)» الذي يقرأ ويكتب ملفّات .mdb / .accdb الخاصّة بـAccess يخضع أيضاً لقيد 32bit/64bit. لا يمكن تثبيت سوى إصدار واحد فقط على الجهاز الواحد، ويجب أن يتطابق مع bitness الخاصّ بـOffice.² وبما أنّ التثبيت الافتراضيّ لـOffice أصبح 64bit ابتداءً من Office 2019 / Microsoft 365، فإنّ تطبيقات Access أو مكوّنات ActiveX المبنيّة على افتراض 32bit القديم قد تتوقّف عن العمل بمجرّد استبدال الجهاز بجهاز جديد.³⁴
• لا يزال فتح عدّة أشخاص لملفّ .accdb في وقت واحد من مجلّد مشترك شائعاً في الميدان حتى الآن، لكنّه عامل خطر يؤدّي إلى تلف البيانات وتراجع الأداء. فالكتابة عبر الشبكة قد تؤدّي إلى تلف البيانات إذا أصبح الاتصال غير مستقرّ، وهذا موضَّح رسميّاً.⁵ وعندما يكبر حجم السجلّ أو يزداد عدد المستخدمين المتزامنين، يصبح الوقت مناسباً للنظر في الترقية (upsizing) إلى SQL Server أو ما شابهه.
• محور القرار هو نفسه المستخدم مع ActiveX / OCX: هل هذا الأصل مجرّد شاشة، أم واجهة حدوديّة تحمل منطق العمل والبيانات معاً. إذا كان يعمل باستقرار ونطاقه مغلق فنُبقيه، وإذا رغبنا في تحديث جزء منه فقط فنُغلِّفه، وإذا كانت قيود الـUI أو أساس التشغيل تُعيق الأعمال فنستبدله ── بهذا الترتيب نُفكِّر في الأمر.

2. وضع VB6 الحاليّ ── بيئة التشغيل حيّة، لكن لا سند تطويريّ خلفها

لنحدِّد الافتراض بدقّة أوّلاً. أعلنت مايكروسوفت بتاريخ 8 أبريل 2008 أنّ «بيئة تطوير Visual Basic 6.0 (وكذلك بيئة تطوير Visual Studio 6.0) لم تعد ضمن نطاق الدعم»، وأوضحت موقفها بأنّه لم تعد هناك وسيلة رسميّة لإنشاء تطبيقات VB6 وصيانتها، وأنّها توصي بشدّة بالانتقال إلى تقنيّات حديثة.¹

لكن في الإعلان نفسه، ذُكر أيضاً أنّ بيئة تشغيل VB6 تبقى ضمن نطاق الدعم طوال فترة دعم إصدار Windows الذي تُشحَن معه. ويُتوقَّع أن «تعمل تطبيقات VB6 القائمة كما هي» على إصدارات Windows المدعومة، على أن يقتصر نطاق الدعم على معالجة الانحدارات الخطيرة (regressions) والمشكلات الأمنيّة الجسيمة.¹ بعبارة أخرى، يمكن توقّع الحدّ الأدنى وهو «ألّا ينهار عند التثبيت على Windows جديد»، لكن لا يوجد دعم بمعنى «الحصول على إضافة ميزات أو تحقيق فرديّ عند الحاجة».

نقطة أخرى مهمّة من الناحية العمليّة هي أنّ بيئة تشغيل VB6 ملفّ مخصّص لـ32bit، ولا تُدعَم على أنظمة التشغيل 64bit إلّا داخل بيئة محاكاة 32bit تُسمّى WOW64.¹ وهذا يعني أنّ «تطبيقات VB6 لن تستطيع البقاء مستقبلاً إلا كعمليّة (process) بنظام 32bit». فعندما ترغب في استخدام SDK لجهاز قياس مخصّص لـ64bit أو مكتبة تشفير حديثة، لا يمكن من حيث المبدأ تحميلها مباشرةً داخل عمليّة VB6. والطريقة الوحيدة عمليّاً لتجاوز هذا الحاجز هي «استخراج ذلك الجزء إلى عمليّة منفصلة والتواصل معها»، ويمكن استخدام البنية المحدَّدة التي تناولها مقال «دراسة حالة لجسر COM يستدعي DLL بنظام 64 بت من تطبيق 32 بت» كما هي. الفكرة نفسها تنطبق عند استخدام جسر من تطبيق VB6: نحصر ميزات الـ64bit داخل خادم COM خارج العمليّة (Out-of-Process) أو ملفّ EXE مساعد، ويكتفي جانب VB6 باستدعائه فقط.

تحمل غالبيّة تطبيقات VB6 عناصر تحكّم ActiveX / OCX كمكوّنات للشاشة. وقد تناولنا بالتفصيل قرار الإبقاء أو التغليف أو الاستبدال لهذه المكوّنات نفسها في مقال «كيف تتعامل مع ActiveX / OCX اليوم»، فيُرجى الرجوع إليه بخصوص قرار كلّ عنصر تحكّم مضمَّن داخل تطبيق VB6 على حدة. أمّا في هذا المقال، فسنركِّز على القرار في مستوى أعلى: كيفيّة التعامل مع تطبيق VB6 ككلّ.

3. وضع Access الحاليّ ── تنسيق الملفّات، وbitness الخاصّ بـACE، وواقع المجلّدات المشتركة

3.1 bitness في .mdb / .accdb وACE

تُحفَظ بيانات Access في ملفّات .mdb (التنسيق القديم) أو .accdb (منذ عام 2007)، والمكوِّن الذي يشغِّل قراءتها وكتابتها هو Access Database Engine (ACE، خليفة Jet). أكثر ما يتكرّر في الميدان هو مشكلة عدم تطابق bitness. فمزوِّد Jet OLE DB القديم لا يُقدَّم إلا بإصدار 32bit، أمّا ACE فيُقدَّم بإصدارَي 32bit و64bit، لكن لا يمكن تثبيت سوى أحدهما على الجهاز الواحد، ويجب أن يتطابق مع bitness الخاصّ بـOffice على ذلك الجهاز، وفق ما هو موضَّح رسميّاً.² كما يُذكَر صراحةً في جانب Visual Studio أنّه ابتداءً من Visual Studio 2022 أصبحت العمليّة بنظام 64bit، ما يجعل أدوات البيانات التي تستخدم مزوِّد Access بنظام 32bit عاجزة عن الاتصال في بعض الحالات.⁶

والأكثر إزعاجاً هو تغيّر القيمة الافتراضيّة في جانب Office. كان الإصدار الافتراضيّ المثبَّت لـOffice 2010 حتى 2016 هو 32bit، لكن ابتداءً من Office 2019 وMicrosoft 365 أصبح التثبيت الافتراضيّ بإصدار 64bit.³ وبالإضافة إلى ذلك، لا تستطيع عمليّة Office بإصدار 64bit تحميل ملفّات ثنائيّة (binary) بنظام 32bit، لذا فإنّ عناصر تحكّم ActiveX القائمة أو إضافات COM المبنيّة على 32bit لا تعمل كما هي مع Office بإصدار 64bit.⁴ بعبارة أخرى، فإنّ كثيراً من الحوادث من نوع «استخدمنا نفس تطبيق Access لسنوات، لكن بمجرّد استبدال جهاز الكمبيوتر توقّف فجأة عن العمل» سببها تحوّل bitness الخاصّ بـOffice افتراضيّاً، وعجز bitness الخاصّ بـACE والعناصر المضمَّنة عن مواكبة ذلك التحوّل. وقد لخّصنا خطوات تشخيص هذا النوع من المشكلات في مقال «أسباب عدم عمل ActiveX على Office 2024/Microsoft 365 وخطوات التحقّق منها».

3.2 مخاطر الاستخدام من عدّة أشخاص عبر مجلّد مشترك

من التصميمات الشائعة الأخرى لتطبيقات Access هو فتح عدّة أشخاص لملفّ .accdb موضوع في مجلّد مشترك في وقت واحد. في النطاق الصغير يعمل هذا لسنوات دون مشكلة، لكنّه بنيويّاً تصميم محفوف بالمخاطر. فالكتابة عبر الشبكة قد تؤدّي إلى فشل الكتابة أو تلف الملفّ إذا أصبح الاتصال غير مستقرّ، وهذا موضَّح رسميّاً،⁵ كما أنّ حالات إبلاغ Access عن أخطاء في القرص أو الشبكة عند تأخّر الوصول إلى خادم الملفّات أو انتهاء مهلته معروفة منذ زمن طويل.⁷ وبذرة التلف نفسها، من حيث كونها وصولاً متزامناً إلى ملفّ مشترك، تشبه بنيويّاً أنماط التنافس التي تناولها مقالنا «أساسيّات التحكّم في التزامن لتكامل الملفّات» في هذه المدوّنة. يتضمّن Access آليّة تحكّم في التزامن مدمجة عبر ملفّ القفل (.laccdb)، لكن كلّما زادت «المسارات المعرَّضة لعدم استقرار الاتصال» مثل أجهزة الكمبيوتر المحمولة عبر Wi-Fi، أو العمل من المنزل عبر VPN، أو إعادة الاتصال بعد الاستيقاظ من وضع السكون، ارتفع معدّل الحوادث.

المخرج المعتاد عند زيادة عدد المستخدمين المتزامنين أو ثقل المعالجة هو نقل جداول Access إلى SQL Server أو Azure SQL، مع الإبقاء على جانب Access كمرجع عبر جدول مرتبط (Linked Table). باستخدام أدوات مثل SQL Server Migration Assistant (SSMA)، وبعد ترحيل جداول Access، يُستبدَل جدول Access الأصليّ بارتباط إلى الجدول في الوجهة الجديدة، ما يسمح بنقل البيانات فقط إلى أساس أكثر متانة مع إبقاء الشاشات (النماذج والتقارير والاستعلامات) كما هي.⁸ غير أنّ تحويل الجداول إلى جداول مرتبطة يحمل مشكلات معروفة خاصّة بما بعد الترحيل، مثل تباطؤ معالجة التجميع (إذا اعتمدت على دوال لا يمكن تنفيذها في جانب الخادم، يسحب Access الجدول بأكمله محليّاً ثمّ يعالجه)، وتغيّر سلوك عمود الترقيم التلقائيّ، وقد يلزم أحياناً استبدالها باستعلامات تمريريّة (Pass-Through Queries) أو Views.⁸ كما يُوصَى منذ زمن طويل بتصميم تطبيقات Access عبر تقسيمها إلى قاعدة بيانات «خلفيّة (Backend)» تحوي الجداول، وقاعدة بيانات «أماميّة (Frontend)» تحوي الشاشات والاستعلامات والماكرو.⁹ والمهمّ هنا هو أنّ التقسيم وحده غير كافٍ. البنية الصحيحة هي وضع الخلفيّة (الجداول) فقط في المجلّد المشترك، بينما تُنسَخ الواجهة الأماميّة إلى جهاز كلّ مستخدم ويُستخدَم من نسخته المحليّة الخاصّة. أمّا استمرار فتح الجميع لملفّ واحد على المجلّد المشترك حتى بالنسبة للواجهة الأماميّة، فيبقى فيه خطر «القراءة والكتابة المتزامنة للشاشات والاستعلامات والماكرو على ملفّ مشترك» حتى مع التقسيم، ويسبِّب مشكلات مثل تدهور وقت الانتظار عند الفتح، أو التعارض عند تغيير التصميم. سواء استمررتَ في تشغيل المجلّد المشترك أو انتقلتَ إلى SQL Server، فإنّ أوّل نقطة تحقّق هي التأكّد من إنجاز كلّ من «مشاركة الخلفيّة» و«وضع الواجهة الأماميّة على جهاز كلّ مستخدم» معاً.

4. جدول القرار

بتنظيم تطبيقات VB6 وAccess حسب حالة الاستخدام وعوامل الخطر، يمكن التوصّل إلى القرار التالي.

كملاحظة إضافيّة، فإنّ «التغليف» في هذا الجدول يعني في معظم الحالات تحديث البيانات فقط أو الحدود فقط أوّلاً، مع الإبقاء مؤقّتاً على الشاشة وتجربة الاستخدام. لا تعتبره إعادة بناء كلّ شيء دفعة واحدة، بل نقطة هبوط مؤقّتة تسمح بالبدء من الأجزاء الأعلى خطورة أوّلاً.

طريقة استخدام جدول القرار هي أوّلاً تضييق صفّ «الهدف»، ثمّ التحقّق مما إذا كانت حالتك تنطبق على «حالة الاستخدام / عامل الخطر». من المهمّ أنّه حتى ضمن تطبيق VB6 واحد، يمكن تقسيم القرار على مستوى الصفّ أو الميزة الواحدة، كأن نُبقي شاشة معيّنة ونُغلِّف ميزة أخرى. فإذا جمعنا كلّ شيء تحت عبارة «إنّه تطبيق VB6 فلنعامله جميعاً بالطريقة نفسها»، فسنُقحم حتى الأجزاء المستقرّة التي كان بالإمكان الإبقاء عليها، ما يضخِّم حجم العمل.

5. تطبيق القرار حسب السيناريو

عند تطبيق جدول القرار على استشارات فعليّة، غالباً ما ينتهي الأمر إلى واحد من الأنماط الثلاثة التالية.

السيناريو 1: تطبيق VB6 لإدارة المخزون للاستخدام الداخليّ فقط، ومتطلّبات التغيير صغيرة. إذا كانت الأجهزة المستهدَفة ثابتة على عدد قليل من الوحدات ولا تخرج البنية إلى الشبكة، فإنّ جدول القرار يميل إلى «الإبقاء». الإجراء العمليّ هنا يقتصر على تكديس تدابير تخفيف المخاطر في الفصل 7 (النسخ الاحتياطيّ، التوثيق، تثبيت بيئة التشغيل) بشكل منهجيّ. وما لم يكن هناك دافع قويّ للانتقال إلى .NET، فغالباً ما لا تتوافق جدوى التكلفة مع ذلك.

السيناريو 2: سجلّ Access مشترك بين عدّة أقسام، وقد ازداد عدد المستخدمين. من الاستشارات الشائعة أن يتحوّل تطبيق Access الذي كان يستخدمه شخصان أو ثلاثة قبل بضع سنوات إلى وصول متزامن على نطاق 10 أشخاص بسبب دمج الأقسام أو توسّع العمل. في هذه الحالة، يميل جدول القرار إلى «التغليف». أوّلاً، تحقّق مما إذا كانت مشاركة الخلفيّة ووضع الواجهة الأماميّة محليّاً على كلّ جهاز مُنجَزَين (القسم 3.2)، وإن لم يكونا كذلك، أعِد التقسيم والوضع أوّلاً. بعد ذلك، إذا ظهرت مؤشّرات على التلف أو تراجع الأداء (تزايد وقت الانتظار حتى الفتح، أو بقاء ملفّ .laccdb دون تحرير القفل، وغيرها)، انقل الجداول إلى SQL Server وحوِّل جانب Access إلى مرجع عبر جدول مرتبط.⁸ وبما أنّ الشاشات يمكن استخدامها كما هي تقريباً، يمكن تعزيز أساس البيانات فقط مع تقليل تكلفة تدريب المستخدمين.

السيناريو 3: تطبيق VB6 الأساسيّ الذي ترك مطوّره العمل، وظهرت الحاجة إلى التحوّل نحو الويب. في وضع يتوفّر فيه المصدر لكن لا يوجد من يستطيع التعامل معه، مع ظهور طلب على الاستخدام من خارج الشركة، يميل جدول القرار إلى «الاستبدال». لكن كلّما كان التطبيق أساسيّاً، زادت مخاطر إعادة الكتابة الكاملة المفاجئة إلى درجة عالية جدّاً. الأقرب إلى الواقع هو البدء - وفق خطوات الفصل 9 - بجرد منطق العمل واستخراج الميزات ذات النطاق المحدود من التأثير، ثمّ التقدّم عبر ترحيل تدريجيّ.

6. أنماط مضادّة شائعة

سنشارك أوّلاً أنماط الفشل المتكرِّرة في مشاريع إطالة عمر VB6 وAccess وترحيلها. قبل تطبيق جدول القرار، تحقّق أوّلاً مما إذا كنتَ تقع في أحد هذه الأنماط.

من بين هذه الأنماط، أكثرها تكراراً هما اثنان: ترك تزامن bitness دون معالجة، وزيادة عدد مستخدمي المجلّد المشترك. وكلاهما يشترك في أنّهما ليسا مسألة «تنهار اليوم»، بل تظهران عند حدث محتوم يأتي عاجلاً أم آجلاً، مثل استبدال الجهاز أو زيادة عدد المستخدمين.

7. تدابير واقعيّة لتخفيف المخاطر في حال الإبقاء

توجد حالات كثيرة يكون فيها قرار الإبقاء واقعيّاً، وهذا في حدّ ذاته ليس خطأً. لكن كلّما استمررنا في نهج «إنّه يعمل فلا تلمسه»، تراكمت مخاطر عدم القدرة على شرح الافتراضات لأحد. ينبغي في الحدّ الأدنى تجهيز ما يلي.

• تشغيل إدارة أجيال النسخ الاحتياطيّ بشكل آليّ. بما أنّ ملفّ .accdb الخاصّ بـAccess يكتمل في ملفّ واحد، فإنّ مجرّد أخذ نسخة احتياطيّة يوميّة بترقيم الأجيال يمكن أن يمتصّ عدداً كبيراً من الحوادث. أمّا تطبيقات VB6 فيجب حفظ مصدرها كاملاً (.vbp، .frm، .bas، .cls) مع ملفّات OCX وDLL التابعة ومعلومات تسجيل السجلّ (Registry) معاً.
• توثيق افتراضات بيئة التشغيل كتدبير احترازيّ لغياب الخلَف. احتفظ على الأقلّ بمستوى تفصيل يوضِّح «ما الذي يجب التحقّق منه عند التوقّف عن العمل على جهاز جديد»، ويشمل ذلك نظام التشغيل المدعوم، وbitness الخاصّ بـOffice، وبيئة التشغيل المطلوبة، وDLL التابعة، وإجراءات التسجيل.
• تثبيت بيئة التشغيل عمداً. بما أنّ التحديث التلقائيّ لـWindows أو Office قد يغيِّر bitness أو الإعدادات الافتراضيّة ويكون سبباً للحوادث (القسم 3.1)، اجعل سياسة التحديث للأجهزة المستهدَفة فقط منفصلة، واعتمد تشغيلاً يتحقّق قبل التحديث ثمّ ينشره.
• تجهيز اختبار دخان (smoke test) في بيئة نظيفة. قبل النشر على جهاز جديد، أعدّ إجراءً يتحقّق من نجاح التثبيت والتسجيل والتشغيل والعمليّات الرئيسيّة في بيئة نظيفة تماماً، فهذا يقلِّل الوقت الضائع في كلّ عمليّة نشر بسبب «كان من المفترض أن يعمل لكنّه لا يعمل».
• تجميع مواضع الاستدعاء في مكان واحد. بدلاً من نثر استدعاءات COM الخاصّة بـVB6 أو مراجع الجداول المرتبطة الخاصّة بـAccess في أنحاء التطبيق كافّة، اجعل نقطة الدخول محصورة قدر الإمكان، فهذا يوضِّح نقطة البداية عند التغليف أو الاستبدال مستقبلاً.

من النقاط الخاصّة بـVB6 التي تستحقّ الذكر أيضاً هي الحفاظ على جهاز التطوير نفسه. فوسائط تثبيت بيئة التطوير (IDE) والترخيص، والنسخة المخصّصة للمطوّرين من عناصر التحكّم الخارجيّة (OCX) اللازمة للبناء، ومذكّرات إجراءات البناء، كلّها أصول أسهل تشتّتاً من بيئة التشغيل نفسها. حتى لو لم تكن هناك خطط للتعديل في الأمد القريب، فإنّ حفظ حالة يمكن من خلالها إعادة إنتاج البناء في بيئة واحدة (مثل لقطة (snapshot) لآلة افتراضيّة) يوسِّع كثيراً من الخيارات المتاحة عند الحاجة إلى تعديل صغير لاحقاً.

إذا كنتَ ترغب في صيانة برنامج Windows القائم وتعديله دون كسره، فهذا يقع ضمن نطاق تعديل وصيانة برامج Windows القائمة.

8. خيارات واقعيّة في حال التغليف

«التغليف» هو نهج يحصر الأصل القديم داخل حدود ضيّقة، ويُظهره للمحيط كواجهة جديدة. في حالة VB6 وAccess، يتلخّص الأمر غالباً في الأنماط الثلاثة التالية.

(أ) استدعاء مكوّنات COM الخاصّة بـVB6 من .NET عبر التشغيل البيني (interop) لـCOM. إذا كانت وحدة الفئة (Class Module) المكتوبة بـVB6 منشورة كـ ActiveX DLL (أو EXE في حال كانت خارج العمليّة)، يمكن استدعاؤها من جانب .NET عبر التشغيل البيني لـCOM. وبما أنّ جانب VB6 يبقى بنظام 32bit، فعند استدعائه من تطبيق .NET بنظام 64bit، يقف نفس حاجز bitness الذي تناولناه في الفصل 2 عائقاً بالشكل نفسه. أمّا الاختيار بين مطابقة جانب الاستدعاء لنظام 32bit، أو حصره داخل عمليّة 32bit كخادم COM خارج العمليّة، فيمكن تطبيقه مباشرةً من خلال قلب البنية المستخدمة في مقال «دراسة حالة لجسر COM يستدعي DLL بنظام 64 بت من تطبيق 32 بت». ويُرجى الرجوع إلى مقال «ما هي COM / ActiveX / OCX» بخصوص أساسيّات COM نفسها.

(ب) نقل منطق VBA في Access تدريجيّاً إلى .NET / الويب. تختلط في تطبيقات Access حالات يتركّز فيها منطق عمل كثيف خلف النماذج، وحالات تقتصر على إدخال بيانات بسيط أو عرض قوائم. النهج الأقرب إلى الواقع هو جرد وحدات VBA أوّلاً، ثمّ استخراج منطق الحساب والتحقّق الخالص - الذي لا يعتمد على أنظمة أخرى - إلى مكتبة فئات (Class Library) بلغة .NET، وتحويل جانب Access ليستدعيها عبر COM أو عبر واجهة Web API وسيطة. وقد نظّمنا بالتفصيل قيود VBA نفسها ومحور القرار بشأن ما ينبغي إبقاؤه في VBA في مقال «ما هو VBA».

(ج) استبدال الـUI فقط أوّلاً، مع الإبقاء على البيانات والمنطق. إذا كانت الشكاوى الرئيسيّة تتمحور حول قِدَم نماذج Access وبطئها وعدم إمكانية استخدامها من خارج الشركة، فهناك خيار استبدال الـUI فقط بتقنيّات حديثة على الويب أو سطح المكتب، مع الإبقاء على طبقة البيانات (الجداول المحوَّلة إلى SQL Server) والمنطق كما هما. وبدمج هذا مع تحويل الجداول إلى جداول مرتبطة الموضَّح في القسم 3.2، يصبح ممكناً أيضاً تشغيل مزدوج انتقاليّ من نوع «البيانات في SQL Server، وكلّ من الـUI القديم (Access) والـUI الجديد يرى البيانات نفسها». مع ذلك، إذا كان VBA في جانب Access يربط الـUI بالمنطق ربطاً وثيقاً، فإنّ عمليّة الفصل هذه نفسها لن تنجح ما لم يُنجَز جرد الخيار (ب) أوّلاً.

بتنظيم الخيارات الثلاثة، تصبح كالتالي:

إذا كنتَ في مرحلة الرغبة أوّلاً في استشارة بشأن تنظيم الحدود أو سياسة الترحيل، فهذا يقع ضمن نطاق الاستفادة من الأصول القائمة ودعم الترحيل، أمّا مراجعة التصميم قبل الدخول في التنفيذ فتقع ضمن نطاق الاستشارة التقنيّة ومراجعة التصميم.

9. خطوات العمل في حال الاستبدال

يُختار الاستبدال في حالات مثل أن تكون قيود الـUI أو bitness تُعيق سرعة الأعمال مباشرةً، أو أن تتعذّر الصيانة نفسها بسبب غياب المطوّر. وبدلاً من البدء فوراً بإعادة كتابة كاملة، فإنّ اتّباع الترتيب التالي يقلِّل الحوادث.

1. التحقّق من ترحيل البيانات أوّلاً. في عمليّات ترحيل البيانات من نوع Access إلى SQL Server، توجد اختلافات لا تظهر إلا بعد الترحيل، مثل اختلاف توقيت منح الترقيم التلقائيّ، والاعتماد على دوال موجودة فقط في جانب Access، وغياب فهرس فريد.⁸ أنجِز اختبار الترحيل وسيناريوهات العمل ذهاباً وإياباً باستخدام نسخة من بيانات الإنتاج، ثمّ انتقل إلى التبديل الفعليّ.
2. جرد منطق العمل. استخرج محتوى نماذج/وحدات VB6، وVBA/الماكرو/الاستعلامات في Access على مستوى الميزة الواحدة، وميِّز بين ما هو «مجرّد شاشة» وما هو «واجهة حدوديّة تحمل مواصفات». طريقة التمييز هذه نفسها المستخدمة في قرار ActiveX / OCX، لكن في حالة VB6 وAccess توجد صعوبة خاصّة تتمثّل في أنّ فهم العمل المتراكم عبر سنوات من التشغيل أصبح هو نفسه أصلاً، ما يجعل استخراجه يستغرق وقتاً أطول عادةً.
3. التقدّم عبر ترحيل تدريجيّ (نمط الخانق / Strangler Pattern). بدلاً من استبدال جميع الميزات دفعة واحدة، استخرج الميزات منخفضة الخطورة وعالية الاستقلاليّة إلى النظام الجديد أوّلاً، وشغِّل التطبيق القديم والجديد بالتوازي لفترة محدَّدة. أدنى شرط لعدم انهيار هذا النهج هو توضيح أيّ من البيانات - القديمة أم الجديدة - هي الصحيحة على مستوى كلّ ميزة، وتحديد شرط إنهاء فترة التشغيل الموازي مسبقاً.
4. إنجاز استبدال مكوّنات الـUI أو بنية الشاشات مسبقاً يجعل الأمر أسهل. إذا كان تطبيق VB6 يستخدم ActiveX / OCX كمكوّنات UI، فإنّ استبدال هذه المكوّنات فقط بعناصر تحكّم حديثة مسبقاً يُسهِّل تقدير الاستبدال الشامل في المرحلة اللاحقة. يُرجى الرجوع إلى «كيف تتعامل مع ActiveX / OCX اليوم» بخصوص القرار الفرديّ لكلّ مكوِّن.
5. تجهيز وسيلة مراقبة أثناء فترة التشغيل الموازي. أثناء تشغيل التطبيق القديم والجديد بالتوازي، جهِّز سجلّات أو آليّة مطابقة تسمح بمقارنة النتائج الصادرة من كلّ منهما. فإذا استمررت في التبديل دون وسيلة مراقبة، فقد لا تلاحظ حادثة من نوع «بعد التبديل إلى النظام الجديد لم تعد الأرقام متطابقة» إلا بعد مرور عدّة أشهر.

من الخدمات التي تغطّي النطاق من جرد مواصفات تطبيقات Windows القديمة إلى الاستبدال التدريجيّ، تتوفّر خدمة استبدال تطبيقات Windows.

10. قائمة تحقّق عند بدء الترحيل

قبل تطبيق جدول القرار (الفصل 4)، فإنّ إجراء الجرد بالترتيب التالي يقلِّل كثيراً من الوقت اللازم لتحديد السياسة.

1. استخراج الأهداف. أعِدّ قائمة بملفّات .exe / .dll / .ocx الخاصّة بـVB6، وملفّات .mdb / .accdb الخاصّة بـAccess، مرتَّبة حسب اسم الملفّ والإصدار وموقع الوضع.
2. التحقّق من حالة الاستخدام. تحقّق من عدد المستخدمين، ووجود وصول متزامن من عدمه، وهل التشغيل عبر مجلّد مشترك، وما إذا كان الاستخدام يوميّاً أم شهريّاً.
3. التحقّق من افتراضات بيئة التشغيل. استخرج إصدار Windows المدعوم، وbitness الخاصّ بـOffice، وبيئة التشغيل المطلوبة، وDLL التابعة، ووجود تسجيل COM من عدمه (الفصلان 2 و3).
4. التحقّق من موقع البيانات وحجمها. بالنسبة لـAccess، تعرَّف على حجم الملفّ، وعدد الجداول، وعدد السجلّات ووتيرة زيادتها. تُستخدَم هذه المعلومات كمعطيات لتقرير الحاجة إلى التحوّل إلى SQL Server.
5. تقدير تعقيد منطق العمل. من عدد أسطر وحدات VBA، وعدد الماكرو، وعدد النماذج، وعدد نماذج/وحدات فئة VB6، كوِّن تقديراً تقريبيّاً لحجم العمل المتوقَّع للجرد.
6. التحقّق من وجود نسخ احتياطيّة وإجراءات استعادة. بالنسبة للأهداف التي لا تُؤخَذ لها نسخ احتياطيّة أو لم تُختبَر استعادتها من قبل، عالِج هذه النقطة أوّلاً قبل اتّخاذ أيّ قرار.
7. تطبيق النتائج حتى الآن على جدول القرار. بعد تنظيم الهدف وحالة الاستخدام، قارنها بجدول الفصل 4 وحدِّد مؤقّتاً - على مستوى كلّ ميزة - أيّ الخيارات الثلاثة (الإبقاء، التغليف، الاستبدال) هو الأقرب.

إذا تخطّيتَ هذه الخطوات، فغالباً ما ينتهي الأمر بتضخّم حجم العمل دون القدرة على شرح «ما الذي كان صعباً» لاحقاً.

11. الخلاصة

عند تحديد كيفيّة التعامل مع VB6 وAccess، فإنّ أوّل ما يجب النظر إليه ليس «هل هو قديم أم لا»، بل النقاط الثلاث التالية:

• هل تفهم بشكل صحيح الافتراض القائل بأنّ VB6 هو بيئة تشغيل مخصّصة لـ32bit فقدت سند بيئة التطوير (IDE) خلفها (الفصل 2)؟
• هل استوعبتَ الافتراض القائل بأنّ ACE وActiveX في Access مقيَّدان بـbitness الخاصّ بـOffice، وأنّ تشغيل المجلّد المشترك ترتفع فيه مخاطر التلف كلّما زاد الوصول المتزامن (الفصل 3)؟
• هل تستطيع التمييز بين كون هذا الأصل مجرّد شاشة، أو واجهة حدوديّة تحمل منطق العمل والبيانات معاً (جدول القرار في الفصل 4)؟

إذا استطعتَ تنظيم هذه النقاط الثلاث، فستصل بشكل طبيعيّ إلى: إذا كان القرار «الإبقاء»، ثبِّت بيئة التشغيل ولا تُهمِل النسخ الاحتياطيّ والتوثيق (الفصل 7)؛ وإذا كان «التغليف»، احمِ البيانات والمنطق عبر جسر 32/64bit أو التحوّل التدريجيّ إلى .NET/الويب (الفصل 8)؛ وإذا كان «الاستبدال»، ابدأ بالتحقّق من ترحيل البيانات وجرد منطق العمل أوّلاً (الفصل 9). VB6 وAccess ليسا هدفَين يجب التخلّص منهما عشوائيّاً لمجرّد القِدَم، بل هما أصلان ماديّان يحملان معرفة عمل تراكمت عبر سنوات طويلة. غير أنّه لا يمكن الاستمرار إلى الأبد في تجنّب الواجب المتمثِّل في تثبيت بيئة التشغيل، وتنظيم الحدود، والتحقّق من الترحيل، اللازم للاستمرار في التعامل مع هذا الأصل الماديّ. نوصي بالبدء أوّلاً بالجرد وفق قائمة التحقّق في الفصل 10.

مقالات ذات صلة

• ما هو VBA: حدوده، آفاقه المستقبليّة، متى يجب استبداله، وأنماط الترحيل العمليّة
• كيف تتعامل مع ActiveX / OCX اليوم - جدول قرار للإبقاء / التغليف / الاستبدال
• ما هي COM / ActiveX / OCX - دليل عمليّ للفروق والعلاقات بينها
• ما يجب التحقّق منه عندما لا يعمل ActiveX على Office 2024 / Microsoft 365 - الترتيب العمليّ لتغطية التعطيل الافتراضيّ، 32bit / 64bit، تسجيل COM، DLL التابعة، ووصولًا إلى IE mode
• كيفية استدعاء DLL بنظام 64 بت من تطبيق 32 بت - دراسة حالة عملية لجسر COM
• التحكّم الآمن في تزامن تكامل الملفّات - أفضل الممارسات لـ file lock والمطالبة الذرّيّة والمعالجة idempotent

مجالات الاستشارة ذات الصلة

تتعامل شركة كومورا سوفت المحدودة مع جرد الأصول القائمة بما فيها VB6 وAccess وتنظيم سياسة الترحيل، وتصميم إطالة العمر بما يشمل جسر 32bit/64bit، وتخطيط وتنفيذ الاستبدال التدريجيّ.

• الاستفادة من الأصول القائمة ودعم الترحيل
• استبدال تطبيقات Windows
• تعديل وصيانة برامج Windows القائمة
• الاستشارة التقنيّة ومراجعة التصميم
• تواصل معنا

روابط مرجعيّة

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

أين يتصل هذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

هل تعمل تطبيقات VB6 على إصدارات Windows الحاليّة؟

انتهى الدعم الرسميّ لبيئة تطوير VB6 (IDE) في أبريل 2008، لكن بيئة تشغيل VB6 (مثل msvbvm60.dll) تبقى ضمن نطاق الدعم طوال فترة دعم إصدار Windows الذي تُشحَن معه. أي أنّ تطبيقات VB6 القائمة تستمرّ في العمل غالباً على إصدارات Windows المدعومة. غير أنّ VB6 مخصّص لـ32bit فقط، ويعمل على أنظمة التشغيل 64bit داخل بيئة توافق تُسمّى WOW64، لذا فبمجرّد الحاجة إلى التكامل مع DLL أو SDK أو مكوّنات COM مخصّصة لـ64bit، يصبح من الضروريّ استخراج ذلك الجزء إلى عمليّة منفصلة والتواصل معها.

لماذا توقّف تطبيق Access عن العمل بعد استبدال جهاز الكمبيوتر؟

السبب في معظم الحالات هو تغيّر إصدار bitness الخاصّ بـOffice. كان الإصدار الافتراضيّ لـOffice 2010 حتى 2016 هو 32bit، لكن ابتداءً من Office 2019 وMicrosoft 365 أصبح التثبيت الافتراضيّ 64bit. أمّا ACE (محرّك قاعدة بيانات Access) الذي يقرأ ويكتب بيانات Access، فلا يمكن تثبيت سوى إصدار واحد منه (32bit أو 64bit) على الجهاز الواحد، ويجب أن يتطابق مع bitness الخاصّ بـOffice. كما أنّ إصدار Office 64bit لا يستطيع تحميل عناصر تحكّم ActiveX أو إضافات COM المصمَّمة بـ32bit، لذا فإنّ المكوّنات المبنيّة على افتراض 32bit القديم تتوقّف عن العمل بمجرّد الانتقال إلى جهاز جديد.

هل توجد مشكلة في فتح عدّة أشخاص ملفّ Access نفسه من مجلّد مشترك في وقت واحد؟

هذا عامل خطر يؤدّي إلى تلف البيانات وتراجع الأداء. فالكتابة عبر الشبكة قد تؤدّي إلى تلف البيانات إذا أصبح الاتصال غير مستقرّ. وكلّما زاد استخدام أجهزة كمبيوتر محمولة عبر Wi-Fi أو العمل من المنزل عبر VPN، ارتفع معدّل الحوادث. ينبغي في الحدّ الأدنى اعتماد بنية مقسَّمة: مشاركة الخلفيّة (Backend) التي تحوي الجداول فقط، مع نسخ الواجهة الأماميّة (Frontend) التي تحوي الشاشات والاستعلامات إلى جهاز كلّ مستخدم على حدة. وعندما يزداد عدد المستخدمين المتزامنين، يصبح الوقت مناسباً للنظر في ترحيل الجداول إلى SQL Server واستخدام Access كجدول مرتبط (Linked Table) فقط.

هل ينبغي اختيار الإبقاء أو التغليف أو الاستبدال لتطبيقات VB6/Access؟

محور القرار هو ما إذا كان هذا الأصل مجرّد شاشة، أم واجهة حدوديّة تحمل منطق العمل والبيانات معاً. إذا كانت الأجهزة وإصدار Windows ثابتَين ومتطلّبات التغيير صغيرة، فإنّ الإبقاء - على أساس النسخ الاحتياطيّ والتوثيق وتثبيت بيئة التشغيل - هو الخيار الأفضل من حيث جدوى التكلفة. أمّا إذا احتجتَ إلى تكامل 64bit أو تعزيز أساس البيانات، فيمكن تغليف جزء فقط عبر جسر COM أو تحويل الجداول إلى جداول مرتبطة بـSQL Server. وإذا لم يعد بالإمكان الصيانة بسبب غياب المطوّر، أو كان هناك طلب على التحوّل إلى الويب، فالاستبدال هو الخيار، لكن الأقرب إلى الواقع ليس إعادة كتابة كاملة مفاجئة، بل ترحيل تدريجيّ يبدأ أوّلاً بالتحقّق من ترحيل البيانات وجرد منطق العمل.

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

يركّز على تطوير برامج ويندوز، والاستشارات التقنية، والتحقيق في الأخطاء، ويتميّز في المشاريع التي تبقى فيها الأصول القديمة ناشطة، وفي تشخيص الأعطال التي يصعب تحديد سببها.