هل MS Access (Jet) مناسبة للوصول إلى Multiuser؟

Question

لدي منتج مصمم ليكون منتجا سطح المكتب باستخدام ملف Access MS ك DB.

الآن، يحتاج بعض المستخدمين إلى تثبيته في عدد قليل من أجهزة الكمبيوتر (دعونا نقول 2 أو 3) ومشاركة قاعدة البيانات.

فكرت في وضع ملف Access MS في مجلد مشترك والوصول إليه من جهاز الكمبيوتر، ولكن ... تم تصميم محرك Jet لوصول المستخدم المتعدد؟

أي نصائح أو أشياء يجب أن تكون على دراية بهذا؟

تحرير: التطبيق هو One .NET، باستخدام قاعدة البيانات كتخزين (عدم استخدام قاعدة البيانات ك Fountain)

Answer 1

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

1. محرك قاعدة بيانات Jet (وهو كل ما يشارك هنا، حيث تم توضيح المرجع مع تعديل) هو افتراضيا متعدد المستخدمين - تم بناؤه من الألف إلى الياء ليكون بهذه الطريقة.

2. مشاركة متجر بيانات النفاثة جدا موثوقة عندما لا تكون الشبكة دون مستوى دون المستوى. هذا يعني أن هذا ليس WAN وليس لاسلكيا، لأن عرض النطاق الترددي يجب أن يكون كافيا للحفاظ على ملف LDB (لأغلق متعدد المستخدمين)، مما يعني أن Ping من قبل مثيل الكمبيوتر المحلي لمشغل قاعدة بيانات Jet مرة واحدة في الثانية (مع الإعدادات الافتراضية)، ولأن الطائرة لا يمكن أن تتعافى من اتصال إسقاط (وهو أمر شائع جدا في بيئة لاسلكية).

3. الوضع الذي يسقط فيه الوصول إلى أسفل هو عندما يتم مشاركة تطبيق الوصول الأمامي MDB (وهو ليس الحال بالنسبة لهذا الملصق). السبب في فشله لأنك تقاسم الأشياء التي لا يمكن مشاركتها بشكل موثوق وليس لها سبب مشترك. نظرا للطريقة المخزنة كائنات الوصول في ملف MDB (يتم تخزين مشروع الوصول بأكمله في حقل Blob واحد في سجل واحد في أحد جداول النظام)، فهو عرض عرضة للفساد إذا فتحها عدة مستخدمين. في تقديري، مشاركة الواجهة الأمامية للوصول (أو MDB غير مكثف مع الجداول والنماذج / التقارير / إلخ. كل ذلك في MDB واحد) هو المصدر لمدة 99.99٪ من فساد الملفات للملفات Access / Jet.

إجابتي الأساسية لسؤال المرجع هي أنه، نعم، ستكون Jet متجر بيانات رائع لتطبيق هذا الحجم. ومع ذلك، إذا كان هناك أي إمكانية على الإطلاق بالنسبة للمستخدمين النمو فوق 25، فقد يكون من الأفضل أن تبدأ من نقطة الصفر مع محرك قاعدة بيانات أكثر قوة في عدد سكان المستخدمين العاليين.

Answer 2

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

سيكون بطيئا حيث ينشئ طائرة طن من حركة مرور الشبكة. تقوم Microsoft أيضا بإهمال الوصول تدريجيا كأداة تطوير. الوصول إلى 2007، على سبيل المثال، لديه نموذج أمان أقل تطورا بكثير من الوصول إلى 2003.

كمطور الوصول لفترة طويلة، وأنا الابتعاد تدريجيا عن الوصول.

Answer 3

لا تفعل ذلك ... تدعي قاعدة بيانات Jet أن تكون قادرا على دعم العديد من المستخدمين، ولكن من السهل بشكل لا يصدق استخدام "معالج تكبير الحجم" لتحويل ملف الوصول إلى قاعدة بيانات SQL Express. يمكن إغلاق ملف قاعدة البيانات هذا بسهولة من قبل مستخدم أو مسؤول، ولم يتمكن جميع مستخدمي المستخدمين من استخدام قاعدة البيانات.

... و SQL Express مجاني. وبعد مسار الترقية الخاص بك من هناك إلى مثيل كامل لخادم SQL أو بعض قاعدة البيانات التجارية الأخرى بسيطة.

Answer 4

مع 2 أو 3 مستخدمين على شبكة محلية موثوقة، يجب أن تكون على ما يرام، طالما أنك تعود إلى تشغيل الشبكة في كثير من الأحيان.

تجنب أي حقول القليل / Bool في الجداول الخاصة بك - Jet لديه بعض مشكلات الفساد السيئة مع الوصول إلى عدة وصول إليها.

ضع في اعتبارك أيضا أن جميع القفل في الوصول متفائل: سوف تحصل على القوارئ من بعض الأحيان.

تم تصميم MS Access لسيناريوهات Office الصغيرة مثل هذا: استخدام مكتب الضوء غير الحرج الذي يمكنك إعداده بحد أدنى البرمجة.

توقع أن يتم تفسير ملف البيانات بين الآن ثم - النسخ الاحتياطي بانتظام.

Answer 5

محرك ACE / Jet هو قطعة كبيرة من البرامج ولكن، في حين كان صمم لدعم المستخدمين المتعددين، فإن دعم المستخدمين المتعددين في الواقع ليسوا أحد نقاطها القوية. القشة الأخيرة بالنسبة لي هو المكان الذي إزالته بعد ذلك أمن لمستخدم المستخدم (ULS) من المحرك: أفترض أنني أستطيع أن أتخيل حالة قاعدة بيانات بسيطة حيث سيكون لجميع المستخدمين نفس الامتيازات (أي الوصول إلى المسؤول الكل كائنات قاعدة البيانات) لكن المنظمة البحرية الدولية التي لا تدعم العديد من المستخدمين جيدا، مقارنة مع، قل، MS SQL Server.

Answer 6

نعم، فإنه يدعم الوصول عن طريق متعددة (أي رقم صغير بحجم العمل، وحجم مجموعة العمل) للمستخدمين عبر مشاركة ملف الشبكة. ومع ذلك، فإن بنية مشاركة الملفات هي ببساطة غير مثالية لدعم الكتابة المتزامنة إلى ملف من قبل عدة مستخدمين. يوفر نظام قاعدة بيانات العميل / الخادم (SQL Server، وما إلى ذلك) بشكل عام أداء وأمان وموثوقية أفضل.

Answer 7

كوسمطان، من فضلك لا تستخدم الوصول إلى أي شيء متعدد المستخدمين. افعل ما يقترحه Jeff Fritz واستخدام قاعدة بيانات تم تصميمها للوصول متعدد المستخدمين. قد تعتقد أن التطبيق الصغير الخاص بك سيكون مشتركا فقط بين عدد قليل من الناس، لكنني أضمن لك أنه سيكون لديك مائة مستخدم وخمسين ميزات جديدة بحلول نهاية العام. وإذا كانت هذه كلها وصول، بدلا من vb / sql Express، فسيقتح الناس في منزلك في منزلك ليلة واحدة وإشحن حلقك.

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

Answer 8

لقد تم القيام بذلك عدة مرات من خلال العديد من مهندسي البرامج العامة حيث رأينا .MDB تالفة في وضع المستخدم المتعدد. إذا كان الكثير من مطورو الوصول المتخصصين ذوي الخبرة يمكنهم الحصول عليها بشكل صحيح، لأنني أميل إلى الاعتقاد، ثم يجب أن نفعل عمالون شيئا خاطئا وأن شيئا ما يجب أن يكون أساسيا إلى حد ما غير واضح حتى الآن منا أن يهرب من الشيء يصرخ "مرة أخرى!" لذلك إذا كنت تعتبر نفسك مطورا متخصصا في الحصول على أخصائي (أو تعرف كيفية العثور على واحد) ثم اذهب إليه. ولكن إذا كنت عملا عاما أو مستخدميا يبحث عن نهاية ظهر خفيفة الوزن، فأنا أقترح عليك أن تنظر إلى مكان آخر (SQL Server جيد IMO).

Answer 9

إذا كان بإمكان المستخدمين الانتظار مرتين طالما لتطبيق مع نصف الميزات التي يريدونها، فلا تستخدم الوصول إليها.

Answer 10

ليس لدى Jet منطق قفل متطور مطلوب لدعم سيناريوهات المستخدم المتعدد. يمكنك الابتعاد عن استخدامه إذا كان طلبك يقرأ في الغالب والتنافس المنخفض.

لقد رأيت مواقع الويب تدعم العديد من المستخدمين، لكنني أوصى SQL Express إلا إذا كان لديك سبب مقنع لاختيار طائرة.

Answer 11

أستطيع أن أقول لك من تجربة مؤلمة أن Jet 3 / 3.5 لم تكن موثوقة. رأيت تحطمها في كثير من الأحيان تحت الحمل الإضافي وعندما كانت هناك حوادث تتعطل، تخاطر بفساد البيانات. لقد اعتادت أن تكون حساسة للغاية لأي مشاكل في الطاقة، أي عميل يتعطل ضده (حتى واجهة المستخدم المرتبطة MDB)، وأي مشاكل LAN. قد يكون الإصدارات الحديثة من Jet أفضل ولكن التبديل إلى SQL Server من الواضح أن طريقة الذهاب في رأيي لأي شيء آخر غير إدخال البيانات التافهة مع عدد صغير من المستخدمين. SQL Express مجاني ولا تفقد أي شيء، خاصة إذا كنت واجهة المستخدم في .NET، بدلا من الوصول.

تحرير: Microsoft لا تعتقد أنك يجب أن تعتمد على Jet 4 أيضا.

من: http://support.microsoft.com/kb/303528.

Microsoft Jet غير مخصص للاستخدام مع تطبيقات الخادم عالية الإجهاد وتطبيقات خادم التزامن عالية، أو 24 ساعة في اليوم، سبعة أيام تطبيقات خادم الأسبوع. يتضمن ذلك تطبيقات الخادم، مثل تطبيقات الويب وتطبيقات التجارة وتطبيقات المعاملات وتطبيقات خادم المراسلة. بالنسبة لهذه الأنواع من التطبيقات، فإن أفضل الحلول هو التبديل إلى نظام قاعدة بيانات يعتمد على العميل / الخادم، مثل Microsoft Data Engine (MSDE) أو Microsoft SQL Server. عند استخدام Microsoft Jet في تطبيقات الضغط العالي مثل Microsoft Internet Information Server (IIS)، قد تواجه أي من المشكلات التالية: مشكلات استقرار الفساد في قاعدة البيانات، مثل IIS تعطل أو قفل الفشل المفاجئ أو الفشل المستمر للسائق للاتصال بقاعدة بيانات صالحة تتطلب إعادة بدء تشغيل خدمة IIS

Answer 12

فقط تحقق مما إذا كان ملف قفل DB (مثل .ldb) موجودا أم لا. إذا كان هناك، فإن شخص ما يصل إلى هذا الملف. إذا لم يكن هناك، فلا يوجد أحد الوصول إلى هذا الملف ويمكنك المتابعة. خلاف ذلك، انتظر متى لم يعد هذا الملف (.ldb) موجودا.

Answer 13

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

مشاكل:

• يمكن للجميع نسخ البيانات MDB
• لا حقوق الوصول
• إجراءات محدودة المتجر
• تحسين (ضغط وإصلاح) ممكن فقط مع عدم استخدام قاعدة بيانات البيانات
• الحد إلى 2 غيغابايت!