إطار الكيان مع MySQL - انتهت مهلة أثناء توليد النموذج

Question

لقد قمت ببناء قاعدة بيانات في MySQL وأحاول تعيينه مع إطار الكيان، لكنني أبدأ في الركض في "Generatesslexception" وقتما أحاول إضافة أكثر من 20 طاولة إلى سياق EF.

حدث استثناء من نوع "Microsoft.Data.entity.design.visualstudio.modelwizard.engine.modelbuilderengine + generatesslexception" أثناء محاولة التحديث من قاعدة البيانات. رسالة الاستثناء هي: "حدث خطأ أثناء تنفيذ تعريف الأمر. انظر الاستثناء الداخلي للحصول على التفاصيل.'

خطأ فادح واجهته أثناء تنفيذ الأوامر.

انتهت مهلة. فترة المهلة المنقولة قبل الانتهاء من العملية أو الخادم لا يستجيب.

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

إذا قمت بإنشاء النموذج مع edmgen2. إنه يعمل بدون أي أخطاء، ولكن لا يمكن تحديث ملف edmx الذي تم إنشاؤه داخل Visual Studio دون إنتاج الاستثناء المذكور أعلاه.

في جميع الاحتمالات، يكمن مصدر هذه المشكلة في الأداة ضمن Visual Studio نظرا لأن edmgen2 يعمل بشكل جيد، لكنني آمل أن يقدم الآخرون بعض النصائح حول كيفية الاقتراب من هذه القضية الفريدة للغاية، لأنه يبدو أنا لست الشخص الوحيد الذي يعاني منه.

اقتراح واحد كان للزملاء المقدمين يحافظان على ملفين منفصلين ebmx مع بعض crossover الجدول، ولكن هذا يبدو وكأنه إصلاح قبيح جدا في رأيي. أفترض أن هذا ما أحصل عليه لتحاول استخدام "تقنية جديدة". :(

Answer 1

كان لدي صداع حول هذه المشكلة في فترة ما بعد الظهر كله. ومع ذلك، وجدت الحل الذي يمكنك فقط إضافة عبارة في App.config أو Web.config حيث يوجد اتصال EF Desinger ك "مهلة الأوامر الافتراضية = 300000؛". ذهب المشكلة.

Answer 2

النصيحة أعلاه غير صحيحة.

Default Command Timeout هي المعلمة سلسلة الاتصال الوحيدة التي تحتاج إلى تغييرها. Connect Time فقط ينظم مقدار الوقت للانتظار للحصول على اتصال في المقام الأول؛ هذه ليست مشكلتك.

Default Command Timeout يبدو أنه ليس له تأثير في سلسلة الاتصال مع موصل / صافي 6.3.4. أعتقد أن هذا خطأ في الموصل / الشبكة، قدمت تقرير الشوائب مع أوراكل. تحرير: تم الاعتراف بهذا الخطأ من قبل مطوري MySQL وتم إصلاحه اعتبارا من 10/13/2010. تم وضع إصلاحات في 6.0.8 و 6.1.6 و 6.2.5 و 6.3.5.

الطريقة الوحيدة التي حصلت عليها حول هذا هو تغيير بلدي ObjectContext أشياء CommandTimeout الممتلكات لشيء آخر غير فارغة. إذا كان ذلك فارغا، فمن المفترض أن تستخدم القيمة في "المزود الأساسي" لكل MSDN. إذا لم تكن فارغة، فمن القيمة الرسمية لعدد الثواني قبل المهلة.

علي سبيل المثال:

var context = new CitationData.de_rawEntities();
context.CommandTimeout = 180;

Answer 3

الدفع:

http://efvote.wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidency/

عفوا، أدركت فقط أن هذا الرابط تم نشره بالفعل! آسف

أود أيضا أن أفكر بشدة في "اقتراح واحد عرض لزملاء يحافظ على ملفين منفصلين ebmx مع بعض crossover الجدول"

قد تكون قبيحة، ولكن يجب أن تعمل!

Answer 4

يا رفاق ضعفاء عدم شرح كيفية إصلاح المشكلة بسهولة:

1. حذف جميع اتصالات البيانات الخاصة بك
2. قم بتنزيل أحدث موصل MySQL (6.3.x)
3. افتح Visual Studio> Sever Explorer> انقر بزر الماوس الأيمن فوق "اتصالات البيانات"> إضافة اتصال
4. اختر مزود قاعدة بيانات MySQL
5. أدخل تفاصيل الاتصال
6. انقر فوق "تقدم"
7. البحث عن مهلة الاتصال وجعلها شيء مثل 30،000
8. ابحث عن مهلة الأوامر الافتراضية وجعلها شيء مثل 30،000

احفظ كل شيء ثم حاول تحديث طراز EF مرة أخرى. لقد اختبرت هذا مع EF 4.0 و VS2010 لذلك أعرف أنه يعمل.

Answer 5

حاولت كل الحل المذكور أعلاه دون جدوى. قمت بتنزيل أحدث موصل .NET ل MySQL (6.3.6) واختفت المشكلة.

Answer 6

يحاول dotConnect ل mysql. مع مطور الكيان.
لقد حققنا بعض التحسينات في عملية توليد النموذج في أدواتنا. يمكنك إضافة نموذج كيان Devart إلى مشروعك، مما يشبه نموذج إطار كيان ADO.NET، ولكن لديه بعض التحسينات وليس لديه مشكلة مهلة.

Answer 7

اثنين من الاحتمالات الربيع إلى الذهن:

أولا هو أنه إصدار EF 1 (الذي يتم شحنه مع .NET 3.5 SP 1). يرى هذه و هذه.

والآخر هو أن هذا يشعر تماما مثل الأعراض نفسها حصلت مع SQL Server وبرامج تشغيل ما قبل ODBC (Circa 1991) حيث تم استخدام النوع الخطأ من المكالمة: يتم استخدام نوع واحد مع نتائج إرجاع الاستعلامات (select)، والآخر للبيانات - عدم إرجاع النتيجة (create table). في نهاية المطاف أصبح الاتصال غير مراقب بشكل يائس في محاولة لتتناسب مع النتائج المحددة إلى الاستعلام المقابل. (في تلك الأيام، شاشة الموت الزرقاء لم تكن موجودة: تميل الكمبيوتر إلى إعادة التشغيل طوعا بدلا من ذلك.)

أتساءل عما إذا كانت الأداة مربكة وضع الاتصال في مجموعة متنوعة من العمليات التي يتم إجراؤها: إنشاء الجداول، والتحقق من الهيكل المنشأ، وإضافة عمود جديد، ومثابة صفوف، والتحقق من محتوى الصف أو التحقق منه بعد ملء. إذا كان هذا هو السبب، فيمكن تجنبه من خلال كونه "Vener" حول تسلسل العمليات: لا تفعل شيئا سوى الجدول الكامل يخلق واحدا تلو الآخر - أي شيء، لا تفعل شيئا يتسبب في إنشاء جدول ثم alter table لإضافة أعمدة جديدة.