MS Access：この操作を実行するのに十分なメモリがありません
Windows XP（Service Pack 3）[5.1.2600]を実行している4GBのRAMを搭載したデュオコアマシンでAccess2003を使用しています
定期的に、「この操作を実行するのに十分なメモリがありません。不要なプログラムを閉じて、操作を再試行してください。」というエラーメッセージが表示されます。
タスクマネージャをチェックすると、空きメモリが十分にあることがわかります。他の開いているプログラムを閉じても違いはありません。
これは散発的に発生し、さまざまな状況で発生します。フォームのデザインやVBAコードの変更を保存しているとき、複数のフォームが開いていて使用されているときなどです。
設計変更を保存しようとしてこのエラーが発生した場合、Accessオブジェクトが破損しており、回復できません。
これを引き起こしている可能性のあるものについての提案は大歓迎です。
MTIA
破損する可能性が最も高いのはフォームまたはレポートのいずれかであることがわかっているので、新しいmdbを作成し、テーブル（添付）、クエリ、スクリプト（1つのみ）、モジュール、およびメニューのみをインポートしました。次に、LoadFromTextを使用して関数を介してフォームとレポートをインポートし、通常の逆コンパイル/コンパイル、コンパクト化/修復などを行いました。
これまでのところ、木に触れてください、私は数日で別のクラッシュがなかったので、私はおそらくこの回復方法に固執するでしょう。
あなたの提案に感謝します。
フロントエンドのVBAプロジェクトが破損している可能性があります。最初から再構築してから、適切なAccessコーディング手法を使用する必要があります。
vBEオプションで、COMPILE ON DEMANDをオフにします（理由の詳細については、 Michael KaplanのDECOMPILEに関する記事 を参照してください）。
vBEオプションで、REQUIRE VARIABLEDECLARATIONをオンにします。
vBEで、[コンパイル]ボタンに簡単にアクセスできるようにツールバーをカスタマイズします（[デバッグ]メニューにあります）。また、ブレークモードでエラーをデバッグするのに便利なため、（[表示]メニューから）[コールスタック]ボタンを追加することをお勧めします。ここでのポイントは、デバッグとコンパイルをできるだけ簡単にすることです。
環境をセットアップしたら、新しく復元したプロジェクトのすべてのモジュールを調べて、それがないすべてのモジュールの先頭にOPTIONEXPLICITを追加します。次にコンパイルします。無効なコードがある場所をすばやく見つけて、修正する必要があります。
これ以降、プログラミングするときは、コードの2〜3行ごとに頻繁にコンパイルします。コーディングするときは、おそらく1日に100回以上プロジェクトをコンパイルします。
プロジェクトを定期的に逆コンパイルし、圧縮して再コンパイルします。これにより、定期的な開発中に蓄積したクラッドがすべて削除されます。
これらのプラクティスにより、破損していないプロジェクトのコードが可能な限りクリーンな状態に保たれます。すでに破損しているプロジェクトを回復することはできません。
プロジェクトを再構築する方法に関しては、Application.SaveAsTextを使用してすべてのオブジェクトをエクスポートし、Application.LoadFromTextを使用して新しい空のデータベースにインポートするという抜本的なルートをたどると思います。これは、既存の破損したフロントエンドから単純にインポートするよりも優れています。これは、インポートによって、SaveAsText/LoadFromTextサイクルに耐えられない破損した構造がインポートされる可能性があるためです。
私はAccessで毎日プログラミングし、多くのスタンドアロンクラスモジュールを含む多くのコードを使用する重要なアプリを操作しています。私は5年以上の間、コードの破損に対するオブジェクトを失っていません。それは、私がまだA97を使用していた当時のことです。
私のこの古いポストにつまずいて、それがかなりの関心を持っているのを見て、私はおそらく更新が必要だろうと思いましたか？
したがって、2年後、2007年のアプリの多くの作業と古い2003年（さらには'97年）のアプリを実行すると、2007年は2003年よりも本当に厄介なクラッシュを起こしにくいことがわかりました-Accessオブジェクトの定義（フォームとレポート、特に）は簡単に破損します。
私はまだDavid-W-Fentonによる提案1-6（上記）に忠実に従い、さらにApplication.SaveAsTextを使用しています（上記のTony Toewsの提案とリンクを参照）。
最近、私が取り組んでいるのが97、2003、2007のいずれであっても、Accessがany「奇妙な」のヒントを与える場合|crashing|不可解なエラーをスローする "など、次のようにします。
- Accessアプリをすぐに閉じます
- Mdb/accdbファイルをバックアップします
- [Shift]キーを押しながらアプリを再度開いて、何も実行されないようにします
- Application.SaveAsTextを使用して（別のバックアップとして）すべてのオブジェクトをテキストとしてエクスポートします
- / decompileスイッチを使用して、アプリを閉じて再度開きます
- VBAコードを再コンパイルします
- コンパクト/修理を行います。
これはすべてを解決するわけではありませんが、Accessオブジェクトの破損の数を私が観察できるものから大幅に減らします。
ああ、私の。
私は、Accessをプラットフォームとして使用するショップで長年働いていました。アプリケーションは最終的に非常に大きくなり、Access 2003の内部メモリ制限に達し始めました。彼らは、あなたが抱えているのとまったく同じ問題を経験し始めました。お気づきのように、これが発生した場合、メモリの問題を外部から示すことはありません。
同社はこの問題についてマイクロソフトと詳細に話し合ったが、マイクロソフトは最終的にパッチを提供したと思う。したがって、これについてMicrosoftに相談することをお勧めします。これは、同じパッチを提供できる可能性があるため、発生している状況と同様の状況のように思われる場合です。
最終的に長期的な解決策は、アプリケーションをより小さな部分に分割することです。 Access2007への移行は役に立ちませんでした。実際、Access 2007には可動部分が多いため、事態はさらに悪化しました。
迅速な解決策;動作が保証されています：
VBAを開きます（Alt-F11）即時ウィンドウで、次のように入力します。
Application.SaveAsText acForm, "corrupt form name here", CurrentProject.Path & "\zzTempRevive"
その後
Application.LoadFromText acForm, "corrupt form name here", CurrentProject.Path & "\zzTempRevive"
それだけです:)これが他の人に役立つことを願っています！
これは、Accessが実際に問題が何であるかわからない場合のデフォルトのエラーメッセージでもあります。 MDBが特に大きい場合、たとえば800を超えるフォームとモジュールを含むレポートの場合、MDEを作成するときにメッセージが表示されますが、MDBが大きすぎる可能性があります。 ACC2000： "Microsoft AccessはMDEデータベースを作成できませんでした"エラーメッセージ
私はこれを時々自分で起こしたことがあります。そして、私の現在のMDBはそれほど大きくありません。コンパクトと修復では、テーブル、インデックス、またはリレーションシップ以外のオブジェクトのエラーは検出されないことに注意してください。したがって、別のMDBにインポートすることが、これらのエラーを修正する唯一の方法です。
ネットワーク経由でこのMDBに取り組んでいますか？それがこの問題を引き起こすかもしれないと私が考えることができる唯一のことについてです。
私はこの問題に何度も遭遇し、ついにうまくいく解決策を見つけました。何が問題を引き起こしているのかわかりませんが、解決方法は知っています。
通常、エラーはフォームを開いたときに発生します。あなたがする必要があるのは、そのフォームを完全に再作成することです。これを行う最も簡単な方法は、最初に、文書化されていない関数Application.SaveAsTextを使用してフォームをテキストファイルにエクスポートすることです。次に、データベースからフォームを削除し、Application.LoadFromTextを使用してフォームを再ロードします。