هل تواجه مشكلات في استخدام MS Access كواجهة أمامية لقاعدة بيانات MySQL الخلفية؟
https://stackoverflow.com/questions/5842
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
أراد مستخدمان مشاركة نفس قاعدة البيانات، المكتوبة أصلاً في MS Access، دون التعارض مع بعضهما البعض في ملف MDB واحد.
لقد قمت بنقل الجداول من قاعدة بيانات MS Access بسيطة إلى MySQL باستخدام مجموعة أدوات الهجرة (والذي يعمل بشكل جيد بالمناسبة) وقم بإعداد Access للربط بهذه الجداول عبر ODBC.
حتى الآن واجهت ما يلي:
- لا يمكنك إدراج/تحديث/حذف صفوف في جدول بدون مفتاح أساسي (ليس هناك مفاجأة).
- يجب أن تكون حقول "الرقم التلقائي" في MS Access هي المفتاح الأساسي وإلا سينتهي بها الأمر كأعمدة عدد صحيح في MySQL (لماذا لا يكون PK؟)
- تم ترحيل الجداول إلى نوع جدول MySQL's InnoDB، لكن علاقات Access لم تصبح قيود مفتاح خارجي لـ MySQL.
بمجرد استخدام قاعدة البيانات، هل يمكنني توقع حدوث أي مشكلات أخرى؟خاصة عندما يعمل كلا المستخدمين في نفس الجدول؟
المحلول
كان لدي تطبيق يعمل بالمثل:الواجهة الأمامية لـ MS Access إلى الواجهة الخلفية لـ MySQL.لقد كان الأمر مؤلمًا جدًا لدرجة أنني انتهيت من كتابة واجهة Win32 الأمامية بدلاً من ذلك.من أعلى رأسي واجهت المشاكل التالية:
- يبدو أن تطوير رابط ODBC قد توقف منذ فترة طويلة.هناك العديد من الإصدارات المختلفة التي تطفو على السطح --- مربكة للغاية.لا يدعم رابط ODBC Unicode/UTF8، وأتذكر أنه كانت هناك مشكلات أخرى معه أيضًا (على الرغم من إمكانية التغلب على بعضها عن طريق التكوين الدقيق).
- ربما تريد تعديل مخطط قاعدة البيانات يدويًا لجعله متوافقًا مع MS Access.أرى أنك تعرفت بالفعل على المفاتيح البديلة المطلوبة (أي المفاتيح الأساسية int):-)
- يجب أن تضع في اعتبارك أنك قد تحتاج إلى استخدام الاستعلامات التمريرية لإجراء عمليات معالجة SQL أكثر تعقيدًا لقاعدة بيانات MySQL.
- كن حذرًا عند استخدام الكثير من VBA، حيث يؤدي ذلك إلى إتلاف ملف الواجهة الأمامية لديك.ضغط قاعدة البيانات بانتظام (باستخدام القائمة الرئيسية، الأدوات | الأدوات المساعدة لقاعدة البيانات | الضغط والاستعادة، أو شيء من هذا القبيل --- أنا أستخدم النسخة الهولندية) وإجراء الكثير من النسخ الاحتياطية أمر ضروري.
- يميل الوصول إلى التسبب في الكثير من حركة مرور الشبكة.مثل، الكثير حقا ضخمة.ولم أتمكن من إيجاد حل لذلك.يوصى باستخدام شاشة الشبكة إذا كنت تريد مراقبة ذلك!
- يصر Access على تخزين القيم المنطقية كـ 0/-1.IMHO، 0/+1 منطقي أكثر، وأعتقد أنها الطريقة الافتراضية للقيام بالأشياء في MySQL أيضًا.ليست مشكلة كبيرة، ولكن إذا لم تعمل مربعات الاختيار الخاصة بك، فيجب عليك بالتأكيد التحقق من ذلك.
أحد البدائل المحتملة هو وضع الواجهة الخلفية (مع البيانات) على محرك أقراص مشترك.أتذكر أن هذا موثق جيدًا، أيضًا في المساعدة.قد ترغب في إلقاء نظرة على بعض النصائح العامة حول التقسيم إلى واجهة أمامية وخلفية و الكود الذي يعيد الاتصال تلقائيًا بالواجهة الخلفية عند بدء التشغيل;يمكنني أيضًا أن أرسل لك المزيد من نماذج التعليمات البرمجية، أو أنشرها هنا.
بخلاف ذلك، قد ترغب أيضًا في التفكير في MS SQL.ليس لدي خبرة في ذلك، ولكني أفترض أنه يعمل مع MS Access بشكل أفضل بكثير!
نصائح أخرى
أعلم أن هذا الموضوع ليس جديدًا جدًا، ولكنه مجرد بعض التوضيحات الإضافية:
إذا كنت تريد استخدام MS Access بشكل فعال، خاصة مع قواعد البيانات الأكبر حجمًا والمتعددة المستخدمين، فيرجى القيام بما يلي:
قم بتقسيم MDB الخاص بك إلى ملفات تطبيق الواجهة الأمامية وملفات الواجهة الخلفية (البيانات فقط) - سيكون لديك ملفين MDB منفصلين بعد ذلك.
ترحيل كافة الجداول مع البيانات والبنية إلى قاعدة بيانات خارجية.يمكن أن يكون:MySQL (يعمل بشكل جيد للغاية، ولا توجد قيود على حجم قاعدة البيانات، ويتطلب المزيد من المهارات لأنه ليس تقنية MS، ولكنه خيار جيد في كثير من الحالات - علاوة على ذلك، يمكنك توسيع نطاق الواجهة الخلفية الخاصة بك باستخدام المزيد من ذاكرة الوصول العشوائي ووحدات المعالجة المركزية الإضافية، لذلك يعتمد كل شيء على احتياجاتك وقدرات الأجهزة)؛Oracle (إذا كان لديك ما يكفي من المال أو نوع من ترخيص الشركة) أو Oracle 10g XE (إذا لم تكن هذه مشكلة، فإن حجم قاعدة البيانات يقتصر على 4 جيجابايت وستستخدم دائمًا 1 جيجابايت من ذاكرة الوصول العشوائي ووحدة معالجة مركزية واحدة)، MS SQL Server 2008 (إنه زوج رائع أن يكون لديك واجهة MS Access الأمامية وواجهة MS SQL Server الخلفية في جميع الحالات، ولكن عليك أن تدفع مقابل الترخيص!- المزايا هي:التكامل الوثيق، كلتا التقنيتين من نفس البائع؛من السهل جدًا الحفاظ على MS SQL Server فعالاً في نفس الوقت) أو إصدار Express (نفس القصة كما هو الحال مع Oracle XE - نفس القيود تقريبًا).
أعد ربط الواجهة الأمامية لـ MS Access بقاعدة البيانات الخلفية.إذا قمت بتحديد MS SQL Server للواجهة الخلفية، فسيكون من السهل استخدام المعالج من MS Access.بالنسبة إلى MySQL - يتعين عليك استخدام برامج تشغيل ODBC (وهي بسيطة وتعمل بشكل جيد جدًا).بالنسبة إلى Oracle - يرجى عدم استخدام برامج تشغيل ODBC من Microsoft.ستقوم هذه البرامج من Oracle بعملها بشكل أفضل بكثير (يمكنك مقارنة الوقت اللازم لتنفيذ استعلام SQL من MS Access إلى Oracle عبر برامج تشغيل Oracle ODBC وMS Oracle ODBC).في هذه المرحلة، سيكون لديك واجهة خلفية صلبة لقاعدة البيانات وواجهة أمامية كاملة الوظائف لـ MS Access - ملف MDB.
قم بتجميع الواجهة الأمامية لـ MDB الخاصة بك إلى MDE - ستمنحك الكثير من السرعة.علاوة على ذلك، فهو الشكل المعقول الوحيد لتوزيع تطبيق MS Access على المستخدمين النهائيين لديك.
للعمل اليومي - استخدم ملف MDE مع واجهة MS Access الأمامية.لمزيد من تطوير الواجهة الأمامية لـ MS Access، استخدم ملف MDB.
لا تستخدم مكونات ActiveX المكتوبة بشكل سيئ لتحسين قدرات الواجهة الأمامية لـ MS Access.من الأفضل أن تكتبها بنفسك أو تشتري المناسب منها.
لا تصدق الخرافات القائلة بأن هناك الكثير من المشكلات في MS Access - فهذا منتج رائع يمكن أن يساعد في بعض المناسبات.المشكلة هي أن الكثير من الناس يفترضون أنها لعبة أو أن MS Access بسيط بشكل عام.عادة ما يولدون الكثير من الأخطاء والقضايا من تلقاء أنفسهم وافتقارهم إلى المعرفة والخبرة.لتحقيق النجاح مع MS Access، من المهم فهم هذه الأداة - وهذه هي نفس القاعدة، كما هو الحال مع أي تقنية أخرى موجودة.
أستطيع أن أخبرك أنني أستخدم MS Access المتقدم جدًا في الواجهة الخلفية لـ MySQL وأنا راضٍ جدًا (كمطور يحافظ على هذا التطبيق).أصدقائي، المستخدمون راضون أيضًا لأنهم يشعرون براحة شديدة تجاه واجهة المستخدم الرسومية (الواجهة الأمامية)، والسرعة (MySQL)، وليس لديهم أي مشاكل في قفل السجلات أو أداء قاعدة البيانات.
علاوة على ذلك، من المهم أن تقرأ الكثير عن الممارسات الجيدة وتجارب الآخرين.أود أن أقول أنه في كثير من الحالات يعد MS Access حلاً جيدًا.أعرف الكثير من الأنظمة المخصصة والمخصصة والتي بدأت كتجربة في شكل قاعدة بيانات MS Access خاصة (ملف MDB) ثم تطورت إلى:تقسيم MS Access (MDE - الواجهة الأمامية، MDB - الواجهة الخلفية) وأخيرًا إلى:الواجهة الأمامية لـ MS Access (MDE) والواجهة الخلفية لقاعدة البيانات "الخطيرة" (أساسًا MS SQL Server وMySQL).من المهم أيضًا أنه يمكنك دائمًا استخدام حل MS Access الخاص بك كنموذج أولي عملي - فأنت على استعداد لاستخدام الواجهة الخلفية في قاعدة البيانات الخاصة بك (MySQL - لنفترض) ويمكنك إعادة كتابة الواجهة الأمامية للتكنولوجيا التي تختارها (حل الويب؟ربما تطبيق سطح المكتب C# - ما تحتاجه!).
آمل أن أكون قد ساعدت بعضًا منكم في التفكير في العمل مع MS Access.
تحياتي ، وورزينhttp://dcserwis.pl
قال غاريث سيمبسون:
إذا كان هناك مستخدمان فقط ، فيجب أن يكون الوصول على ما يرام إذا وضعت .mdb على محرك أقراص مشترك.
إيه لا.لا يوجد تطبيق وصول متعدد المستخدمين حيث لا ينبغي أن يكون لدى كل مستخدم نسخة مخصصة من الواجهة الأمامية.وهذا يعني أنه يجب أن يكون لدى كل مستخدم MDB على محطة العمل الخاصة به.لماذا؟لأن الكائنات الموجودة في الواجهات الأمامية لا تتم مشاركتها بشكل جيد (ليست تقريبًا بنفس جودة جداول بيانات Jet، على الرغم من عدم وجود أي منها في هذا السيناريو يستخدم MySQL كواجهة خلفية).
وتابع غاريث سيمبسون:
أعتقد أن مستخدمي Max Conversion الموصى به للوصول هو 5 ، لكن في بعض الأحيان دفعته إلى ما بعد هذا ولم يأتِ أبدًا.
لا، هذا غير صحيح تماما.الحد النظري لمستخدمي MDB هو 255.هذا ليس واقعيًا، بالطبع، لأنه بمجرد وصولك إلى حوالي 20 مستخدمًا، يتعين عليك برمجة تطبيق Access الخاص بك بعناية ليعمل بشكل جيد (على الرغم من أن الأشياء التي تحتاج إلى القيام بها في تطبيق Access-to-Jet هي نفس أنواع الأشياء التي تريدها يجب القيام به لجعل أي تطبيق لقاعدة بيانات الخادم فعالاً، على سبيل المثال، استرداد أصغر مجموعات البيانات القابلة للاستخدام).
في هذه الحالة، نظرًا لأن كل مستخدم يجب أن يكون لديه نسخة فردية من MDB للواجهة الأمامية، فإن حدود المستخدمين المتعددين لـ Access/Jet ليست ذات صلة على الإطلاق.
أعلم أن هذا لا يجيب على سؤالك مباشرة، ولكن قد يكون من المفيد التحقق من ذلك أداة ترحيل SQL Server 2005 للوصول.لم أستخدم الأداة مطلقًا، ولكن قد يكون من المفيد استخدامها مع SQL Server 2005 Express Edition لمعرفة ما إذا كانت هناك نفس المشكلات التي واجهتها مع MySQL
لا تنس أن تضع طابعًا زمنيًا/تاريخيًا على كل سجل.في بعض الأحيان، يعتقد MS Access أن "مستخدمًا آخر قام بتغيير السجل أو حذفه" ولن يسمح لك بإجراء تغيير!لقد وجدت هذا بالطريقة الصعبة.
على العموم يعتمد :)
لم أواجه الكثير من المشاكل عندما كان جانب التطبيق قد قام للتو بتحديث البيانات من خلال النماذج.يمكنك الحصول على تحذيرات/أخطاء عندما يتم تحديث نفس الصف من قبل أكثر من مستخدم واحد؛ولكن يبدو أن Access يعمل باستمرار على تحديث مجموعات السجلات المباشرة الخاصة به طوال الوقت.
يمكن أن تحدث المشكلات إذا كانت Alice تعمل بالفعل مع السجل 365، وقام Bob بتحديثه، ثم تحاول Alice تحديثه بالتغييرات التي أجرتها.على ما أذكر، ستتلقى أليس رسالة خطأ غامضة.سيكون الأمر أسهل بالنسبة للمستخدمين إذا قمت بمحاصرة هذه الأخطاء ومنحهم على الأقل رسالة خطأ أكثر ودية.
لقد واجهت المزيد من المشاكل عندما كنت أقوم بتحرير السجلات في تعليمات VB البرمجية من خلال RecordSets، خاصة عند دمجها مع تحرير نفس البيانات في النماذج.هذه ليست بالضرورة مشكلة متعددة المستخدمين؛ومع ذلك، لديك نفس الموقف تقريبًا نظرًا لوجود مستخدم واحد لديه اتصالات متعددة لنفس البيانات.
إذا كان هناك مستخدمين اثنين فقط، فمن المفترض أن يعمل Access بشكل جيد إذا قمت بوضع ملف .mdb على محرك أقراص مشترك.
هل جربته أولاً بدلاً من الافتراض أنه سيكون مشكلة.
أعتقد أن الحد الأقصى الموصى به للمستخدمين المتزامنين لـ Access هو 5 ولكن في بعض الأحيان قمت بدفعه إلى ما هو أبعد من ذلك ولم يفشل أبدًا.
من ناحية أخرى، استخدمت Access ذات مرة كواجهة أمامية لـ MySQL في بيئة مستخدم واحد (أنا).لقد كانت تجربة غير سارة على الإطلاق، ولا أستطيع أن أتخيل أنها ستصبح أجمل مع وجود مستخدمين اثنين.
