MS Access: Il n'y a pas assez de mémoire pour effectuer cette opération

Question

J'utilise Access 2003 sur une machine duo-core avec 4 Go de RAM, fonctionnant sous Windows XP (Service Pack 3) [5.1.2600]

Régulièrement, je reçois une erreur msg « Il n'y a pas assez de mémoire pour effectuer cette opération. Fermez les programmes non nécessaires et recommencez l'opération. »

Une vérification du Gestionnaire des tâches indique qu'il ya beaucoup de mémoire libre. La fermeture des autres programmes ouverts ne fait aucune différence.

Cela se produit de façon sporadique, et dans des circonstances différentes: parfois tout en économisant la conception de formulaire ou des changements de code VBA, parfois, lorsque plusieurs formulaires sont ouverts et utilisés

.

Si vous essayez d'enregistrer les modifications de conception, et cette erreur se produit, les objets d'accès sont corrompus et ne peuvent pas être récupérés.

Toutes les suggestions sur ce qui pourrait être la cause serait la bienvenue.

MTIA

Answer 1

Comme je sais que c'est soit des formes ou des rapports qui, très probablement corrompue, j'ai créé une nouvelle mdb, et seules les tables importées (ci-joint), des requêtes, des scripts (un seul), des modules et des menus. Ensuite, je LoadFromText importer les formulaires et rapports via une fonction, puis ne l'habituel décompiler / compilation et compact / réparation etc.

Jusqu'à présent, touchons du bois, je ne l'ai pas eu un autre accident dans quelques jours, donc je vais probablement rester avec cette méthode de récupération.

Un grand merci à tous pour vos suggestions.

Answer 2

Le projet VBA dans votre extrémité avant est probablement endommagée. Vous devez reconstruire à partir de zéro, puis utiliser des pratiques de codage approprié d'accès:

1. dans les options VBE, éteignez COMPILE SUR DEMANDE (voir Michael Kaplan sur DÉCOMPILER pour plus de détails pourquoi).

2. dans les options VBE, activez EXIGER DÉCLARATION VARIABLE.

3. dans le VBE, personnaliser votre barre d'outils afin que le bouton COMPILE est facilement accessible (il est dans le menu Debug). Je recommande également d'ajouter le bouton CALL STACK (dans le menu VIEW), comme il est pratique pour le débogage des erreurs en mode pause. Le point ici est de faire le débogage et la compilation aussi facile que possible.

4. avoir mis en place votre environnement, passer par tous les modules dans votre projet nouvellement récupéré et ajoutez l'option EXPLICITE en haut de chaque module qui en manque. Puis compiler. Vous trouverez rapidement où vous avez du code invalide et vous aurez besoin de le corriger.

5. à partir de maintenant, lors de la programmation, la compilation souvent, après tous les deux ou trois lignes de code. Je compile probablement mon projet 100 fois ou plus par jour lors du codage.

6. périodiquement décompiler votre projet et compact et recompiler. Cela va nettoyer toute crud qui accumule au cours du développement régulier.

Ces pratiques assurent que le code dans un projet non corrompu reste dans un état aussi propre que possible. Il ne fera rien pour récupérer un projet déjà corrompu.

En ce qui concerne la façon de reconstruire le projet, je pense que je vais la route drastique d'exporter tous les objets avec Application.SaveAsText et de les importer dans une nouvelle base de données avec Application.LoadFromText. Ceci est supérieur à importer simplement à partir de votre extrémité avant corrompue existante, car l'importation peut importer des structures corrompues qui ne survivront pas un cycle SaveAsText / LoadFromText.

I programme quotidien dans Access, en travaillant avec des applications non triviales qui utilisent beaucoup de code, y compris beaucoup de modules de classe autonome. Je ne l'ai pas perdu un objet à coder la corruption dans plus de 5 ans, et qui était de retour dans la journée quand j'utilisais encore A97.

Answer 3

Après avoir trébuché à travers cet ancien poste de la mine, et le voir a eu un certain intérêt, je pensais que peut-être une mise à jour serait en ordre?

2 ans sur la piste, faire beaucoup de travail d'application 2007 ainsi que les anciennes 2003 (et même '97) des applications, je trouve que 2007 est moins sujette aux accidents vraiment désagréables que 2003 - où les définitions d'objets d'accès (formulaires et rapports esp.) seraient facilement corrompus.

Je suis toujours les suggestions 1-6 (ci-dessus) par David-W-Fenton religieusement que, plus l'utilisation de Application.SaveAsText (voir la suggestion de Tony Toews et le lien ci-dessus).

Ces jours-ci, que ce soit 97, 2003 ou 2007 je travaille, si l'accès donne tout soupçon de « être bizarre | plantage | lancer des erreurs inexplicables » etc, je fais ce qui suit:

1. Fermez immédiatement l'application d'accès
2. Sauvegardez le fichier mdb / ACCDB
3. Re-ouvrir l'application tout en maintenant la touche [Maj] donc rien fonctionne
4. Exporter tous les objets sous forme de texte à l'aide Application.SaveAsText (comme une autre sauvegarde)
5. Fermer et rouvrir l'application à l'aide du commutateur / décompiler
6. recompiler le code VBA
7. Faites un Compact / réparation.

Cela ne résout pas tout, mais il ne réduit considérablement le nombre d'objets de corruptions d'accès de ce que je suis en mesure d'observer.

Answer 4

Oh mon.

Je travaillais dans un magasin depuis de nombreuses années qui ont utilisé l'accès comme plate-forme de choix. L'application a finalement obtenu si grand qu'il a commencé à frapper une limitation de la mémoire interne d'Access 2003. Ils ont commencé à expérimenter exactement le même problème que vous rencontrez. Comme vous l'avez remarqué, il n'y a aucune indication externe des problèmes de mémoire lorsque cela se produit.

La société a parlé longuement avec Microsoft au sujet du problème, et je crois que Microsoft a finalement leur a fourni un patch. Donc, vous voudrez peut-être parler à Microsoft à ce sujet, si elle ressemble à une situation semblable à ce que vous vivez, car ils peuvent être en mesure de vous fournir le même patch.

En fin de compte la solution à long terme est de briser l'application en petits morceaux. Le passage à Access 2007 n'a pas aidé; en fait, il fait qu'empirer les choses car Access 2007 a plus de pièces mobiles.

Answer 5

Solution rapide; garanti au travail:

Ouvrir VBA (Alt-F11) Dans la fenêtre immédiate entrez les informations suivantes:

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

puis

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

Ca y est :) Espérons que cela aide les autres!

Answer 6

Ceci est également le message d'erreur par défaut lorsque l'accès n'a aucune idée de ce que le problème est en réalité. Maintenant, si votre MDB est particulièrement grand, disons plus de 800 formulaires et rapports avec les modules puis, oui BMD pourrait être trop grand bien que vous avez donné un message lorsque vous êtes allé à créer MDEs. ACC2000: "Microsoft Access n'a pas pu créer une base de données MDE" message d'erreur

J'ai eu moi-même cela arrive de temps en temps. Et mes BDM actuels ne sont pas tout à fait que les grandes. Notez que compact et la réparation ne détecte pas d'erreurs dans les objets autres que les tables, les index ou relations. Ainsi, l'importation dans un autre MDB est la seule façon de corriger ces erreurs.

Travaillez-vous sur ce MDB sur le réseau? C'est à peu près la seule chose que je peux penser à qui pourrait causer ce problème.

Answer 7

Je l'ai rencontré ce problème à plusieurs reprises et a finalement trouvé une solution qui a fonctionné. Je ne sais pas ce qui cause le problème, mais je ne sais comment le résoudre.

En général, l'erreur se produit lorsque vous ouvrez un formulaire. Ce que vous devez faire est complètement recréer cette forme. La meilleure façon de le faire est d'abord exporter la forme d'un fichier texte avec la fonction non documentée Application.SaveAsText. Ensuite, vous supprimez la forme de votre base de données et re-charger avec Application.LoadFromText.