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

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

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

لقراءة هذه المقالة يكفيان افتراضان فقط. الأوّل أنّ VB6 وAccess كليهما تقنيتان محورهما 32bit مبنيّتان على COM (ActiveX / OCX)، وأنّ التوافق مع Windows وOffice الحاليَّين بعد التحوّل إلى 64bit سرعان ما يصبح مشكلة. والثاني أنّنا نستخدم إطار القرار الثلاثيّ «الإبقاء، التغليف، الاستبدال». أمّا الشروح التفصيليّة لتقنيات منفردة مثل COM وVBA فنربطها في موضعها في المتن، وإذا أردت جمعها كمعرفة مسبقة فهي كلّها في «مقالات ذات صلة» في نهاية المقالة، لذا يمكنك في القراءة الأولى أن تمرّ على المتن دون تتبّع الروابط.

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

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

في المخطّط، يشير الخطّ المتّصل إلى علاقة قائمة دائماً، ويشير الخطّ المتقطّع إلى علاقة مشروطة (شروط قيامها مذكورة في شرح كلّ علاقة في الصفحة التفصيليّة). القائمة الكاملة للعلاقات (المجموع 22، مع الأدلّة ودرجة اليقين) وتعريفات المفاهيم الرئيسة مجمّعة في صفحة تفاصيل خريطة المعرفة (باليابانية). البيانات: JSON-LD / Turtle

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

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

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

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

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

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

3.1 .mdb / .accdb وbitness في 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 لا تستطيع تحميل ثنائيّات 32bit، لذا فإنّ عناصر تحكّم ActiveX وإضافات COM القائمة بـ 32bit لا تعمل كما هي في Office 64bit.⁴ أي أنّ كثيراً من حوادث «استخدمنا تطبيق Access نفسه سنوات ثمّ توقّف فجأة بعد استبدال الجهاز» سببها أنّ bitness الافتراضيّ لـ Office تغيّر، وأنّ ACE وعناصر التحكّم المضمَّنة لم تلحق به. خطوات فصل هذا النوع من الأعطال مجمّعة في سبب توقّف ActiveX على Office 2024/Microsoft 365 وإجراءات التحقّق.

«من يقيَّد بـ bitness من؟» يسهل أن يختلط، لذا نضع علاقات التبعية في جدول (أدلّة كلّ صفّ كما في هذا القسم والفصل 2).

ترتيب الصفوف في الجدول هو مسار انتشار الحادث نفسه. إذا تغيّر bitness الخاصّ بـ Office (الصفّ الأوّل)، تأثّر ACE وأجزاء Access التي يحمّلها والتطبيقات الخاصّة المتّصلة بها جميعاً. أوّل بند ينبغي التحقّق منه قبل تحديث الجهاز هو دائماً: «كم bit إصدار Office على الجهاز الجديد؟».

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

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

المخرج الشائع عندما يزيد عدد المستخدمين المتزامنين أو يثقل المعالجة هو نقل جداول Access إلى SQL Server أو Azure SQL، وجعل Access يشير إليها كـ linked tables. بأدوات مثل SQL Server Migration Assistant (SSMA) تُرحَّل جداول Access ثمّ تُستبدل الجداول الأصليّة بروابط إلى الجداول في الوجهة، فتبقى الشاشات (النماذج والتقارير والاستعلامات) كما هي، بينما تنتقل البيانات وحدها إلى أساس أصلب.⁸ غير أنّ التحويل إلى linked tables له مشكلات معروفة بعد الترحيل: قد تبطؤ التجميعات (إذا اعتمدت على دوالّ لا يمكن تنفيذها على الخادم، يسحب Access الجدول كاملاً إلى الجهاز ثمّ يعالجه)، ويتغيّر سلوك أعمدة الترقيم التلقائيّ، وقد تحتاج إلى استبدالها بـ pass-through queries أو views.⁸ كذلك يُوصى منذ زمن بتقسيم تطبيق Access إلى قاعدة بيانات «Backend» تحمل الجداول وقاعدة بيانات «Frontend» تحمل الشاشات والاستعلامات والماكرو.⁹ المهمّ هنا أنّ التقسيم وحده لا يكفي. ضع الـ Backend (الجداول) فقط على المجلّد المشترك، وانسخ الـ Frontend إلى جهاز كلّ مستخدم واستخدم النسخة المحلّيّة. إذا واصل الجميع فتح ملفّ Frontend واحد على المجلّد المشترك، يبقى خطر القراءة والكتابة المتزامنة على الشاشات والاستعلامات والماكرو حتّى بعد التقسيم، فيطول الانتظار قبل الفتح وتحدث تعارضات عند تغيير التصميم. سواء أطلتَ العمر على المجلّد المشترك أم اتّجهت إلى SQL Server، أوّل نقطة فحص هي ما إذا كان «مشاركة الـ Backend» و«توزيع الـ Frontend على كلّ جهاز» متحقّقَين معاً.

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

flowchart TB
    subgraph CLIENTS["جهاز كلّ مستخدم ── نسخة واحدة لكلّ شخص"]
        FE1["Frontend .accdb<br/>نماذج واستعلامات وتقارير وVBA"]
        FE2["Frontend .accdb<br/>نسخة أخرى بالمحتوى نفسه"]
    end
    BE["Backend على مجلّد مشترك .accdb<br/>الجداول فقط"]
    SQL[("SQL Server / Azure SQL<br/>انقل إلى هنا إذا زاد الاستخدام المتزامن")]
    FE1 -->|"linked table"| BE
    FE2 -->|"linked table"| BE
    BE -.->|"upsizing"| SQL
    FE1 -.->|"وجهة الربط بعد الترحيل"| SQL
    FE2 -.->|"وجهة الربط بعد الترحيل"| SQL

الشكل 1: تقسيم Backend وFrontend، ثمّ الـ upsizing بعد ذلك. الخطأ الشائع هو وضع Frontend واحد على المجلّد المشترك وفتحه من الجميع. وعند الترحيل تبقى الشاشات (الـ Frontend) كما هي، ويُستبدل هدف الربط فقط بـ SQL Server.

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

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

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

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

5. كيف نطبّق الحكم حسب السيناريو

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

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

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

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

6. أنماط فشل شائعة

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

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

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

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

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

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

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

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

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

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

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

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

إذا رتّبنا الخيارات الثلاثة:

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

9. كيف تتقدّم عند الاستبدال

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

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

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

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

قبل إسقاط جدول القرار (الفصل 4)، يختصر الجرد بالترتيب التالي وقت اتخاذ السياسة اختصاراً كبيراً.

1. استخرج الأهداف. أدرج ملفات VB6 من نوع .exe / .dll / .ocx وملفات Access من نوع .mdb / .accdb حسب اسم الملفّ والإصدار ومكان النشر.
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
• كيفية استدعاء 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 Database Engine) الذي يقرأ ويكتب بيانات 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 أو تحويل الجداول إلى linked tables على SQL Server. وإذا لم يعد بالإمكان الصيانة بسبب غياب المطوّر، أو كان هناك طلب على التحوّل إلى الويب، فالاستبدال هو الخيار، لكن الأقرب إلى الواقع ليس إعادة كتابة كاملة مفاجئة، بل ترحيل مرحليّ يبدأ أوّلاً بالتحقّق من ترحيل البيانات وجرد منطق العمل.

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

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

غو كومورا

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

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