MS Access: لا توجد ذاكرة كافية لأداء هذه العملية

Question

أنا أستخدم Access 2003 على جهاز ثنائي النواة مع ذاكرة وصول عشوائي 4 جيجابايت ، حيث يعمل على تشغيل Windows XP (حزمة الخدمة 3) [5.1.2600

بشكل دوري ، أحصل على خطأ في MSG "لا توجد ذاكرة كافية لأداء هذه العملية. أغلق البرامج غير الضرورية وتجربة العملية مرة أخرى."

يشير فحص مدير المهام إلى أن هناك الكثير من الذاكرة المجانية. إغلاق البرامج المفتوحة الأخرى لا فرق.

يحدث هذا بشكل متقطع ، وفي ظل ظروف مختلفة: في بعض الأحيان ، يتغير تصميم النماذج أو رمز VBA ، وأحيانًا عندما تكون عدة نماذج مفتوحة واستخدامها.

إذا حاولت حفظ تغييرات التصميم ، ويحدث هذا الخطأ ، يتم تالف كائنات الوصول ولا يمكن استردادها.

أي اقتراحات بشأن ما قد يسبب هذا سيكون موضع ترحيب كبير.

Mtia

Answer 1

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

حتى الآن ، لمس الخشب ، لم أتعرض لحادث آخر في بعض الأيام ، لذلك ربما سألتزم بطريقة الاسترداد هذه.

شكرا جزيلا للجميع على اقتراحاتك.

Answer 2

من المحتمل أن يكون مشروع VBA في الواجهة الأمامية تالفًا. تحتاج إلى إعادة بنائها من نقطة الصفر ثم استخدام ممارسات الترميز المناسبة للوصول:

1. في خيارات VBE ، قم بإيقاف تشغيل الترجم عند الطلب (انظر مقال مايكل كابلان عن فك الشفرة للحصول على تفاصيل لماذا).

2. في خيارات VBE ، يتطلب تشغيل إعلان متغير.

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

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

5. من الآن فصاعدًا ، عند البرمجة ، قم بالتجميع بشكل متكرر ، بعد كل سطرين أو ثلاثة من الكود. ربما أقوم بتجميع مشروعي 100 مرة أو أكثر في اليوم عند الترميز.

6. قم بفك مشروعك بشكل دوري ومضغوط وإعادة ترجمة. سيؤدي ذلك إلى تنظيف أي كرود يتراكم أثناء التطوير العادي.

تؤمن هذه الممارسات أن يبقى الرمز في المشروع غير الفلفل في حالة نظيفة قدر الإمكان. لن تفعل شيئًا لاستعادة مشروع تالف بالفعل.

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

أقوم بالبرمجة يوميًا في الوصول ، والعمل مع التطبيقات غير التافهة التي تستخدم الكثير من التعليمات البرمجية ، بما في ذلك الكثير من وحدات الفئة المستقلة. لم أفقد كائنًا لترميز الفساد منذ أكثر من 5 سنوات ، وكان ذلك مرة أخرى في اليوم الذي كنت فيه لا أزال أستخدم A97.

Answer 3

بعد أن تعثرت عبر هذا المنشور القديم الخاص بي ، ورؤية أنه كان له الكثير من الاهتمام ، اعتقدت أنه ربما يكون التحديث في حالة جيدة؟

لذا ، بعد عامين من المسار ، وأقوم بالكثير من تطبيقات تطبيق 2007 بالإضافة إلى تطبيقات 2003 الأقدم (وحتى '97) ، أجد أن عام 2007 أقل عرضة للانكماشات السيئة حقًا من عام 2003 - حيث تعريفات الكائنات (النماذج و تقارير esp.) سوف تفسد بسهولة.

ما زلت أتابع الاقتراحات 1-6 (أعلاه) من قبل David-W-Fenton دينيًا ، بالإضافة إلى استخدام Application.SaveAstext (انظر اقتراح Tony Toews والرابط أعلاه).

في هذه الأيام ، سواء كان 97 أو 2003 أو 2007 أعمل عليها ، إذا كان الوصول يعطي أي تلميح على "كونها غريبة | تحطم | إلقاء أخطاء لا يمكن تفسيرها"إلخ ، أفعل ما يلي:

1. أغلق تطبيق الوصول فورًا
2. النسخ الاحتياطي ملف MDB/ACCDB
3. أعد فتح التطبيق أثناء الضغط على [التحول] لذلك لا شيء يعمل
4. قم بتصدير جميع الكائنات كنص باستخدام Application.SaveAstext (كنسخة احتياطية أخرى)
5. أغلق التطبيق وإعادة فتحه باستخدام مفتاح /decompile
6. إعادة ترجمة رمز VBA
7. القيام مضغوط/إصلاح.

هذا لا يحل كل شيء ، لكنه يقلل بشكل كبير من عدد الفساد من كائنات الوصول مما يمكنني ملاحظته.

Answer 4

يا بلدي.

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

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

في النهاية ، يكون الحل طويل الأجل هو تقسيم التطبيق إلى قطع أصغر. الانتقال إلى الوصول إلى عام 2007 لم يساعد ؛ في الواقع ، لقد جعل الأمور أسوأ لأن Access 2007 يحتوي على المزيد من الأجزاء المتحركة.

Answer 5

حل سريع مضمون للعمل:

فتح VBA (Alt-F11) في النافذة الفورية أدخل ما يلي:

Application.SaveAsText acForm, "corrupt form name here", CurrentProject.Path & "\zzTempRevive"

من ثم

Application.LoadFromText acForm, "corrupt form name here", CurrentProject.Path & "\zzTempRevive"

هذا كل شيء :) أتمنى أن يساعد هذا الآخرين!

Answer 6

هذه هي أيضًا رسالة الخطأ الافتراضية عندما لا يكون للوصول أي فكرة عن المشكلة بالفعل. الآن إذا كان MDB كبيرًا بشكل خاص ، فقل أكثر من 800 نموذج وتقارير مع وحدات ، نعم ، قد يكون MDB كبيرًا جدًا على الرغم من أن ذلك أعطاك رسالة عندما ذهبت لإنشاء MDEs. ACC2000: "لم تتمكن Microsoft Access من إنشاء رسالة خطأ MDE"

لقد حدث هذا في بعض الأحيان بنفسي. و MDBs الحالية الخاصة بي ليست كبيرة جدًا. لاحظ أن الإصلاح والإصلاح لا يكتشفان الأخطاء في كائنات أخرى غير الجداول أو الفهارس أو العلاقات. لذا فإن الاستيراد إلى MDB آخر هو الطريقة الوحيدة لتصحيح هذه الأخطاء.

هل تعمل على هذا MDB عبر الشبكة؟ هذا عن الشيء الوحيد الذي يمكنني التفكير فيه قد يسبب هذه المشكلة.

Answer 7

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

عادة ما يحدث الخطأ عند فتح نموذج. ما عليك القيام به هو إعادة إنشاء هذا النموذج بالكامل. أسهل طريقة للقيام بذلك هي تصدير النموذج أولاً إلى ملف نصي مع تطبيق الوظيفة غير الموثقة. ثم تقوم بحذف النموذج من قاعدة البيانات الخاصة بك وإعادة تحميله باستخدام Application.LoadFromText.