を実行するための十分なメモリが、私は、Windows XP（サービスパック3）[5.1.2600]MSアクセス：この操作
を実行し、4GBのRAMとデュオコアマシン上でアクセス2003を使用していないです定期的にエラーメッセージ "この操作を実行するのに十分なメモリがありません。不要なプログラムを閉じて、操作を再試行してください。"
タスクマネージャのチェックは、空きメモリが十分にあることを示します。開いている他のプログラムを閉じると違いはありません。
時々、フォームデザインやVBAコードの変更を保存しているときに、ときどきいくつかのフォームが開いていて、使用中のときに、状況が異なることがあります。
デザイン変更を保存しようとすると、このエラーが発生すると、Accessオブジェクトが破損して回復できません。
これを引き起こしている可能性のあることについてのご意見は大歓迎です。
MTIA
私はそれが最も可能性が高い壊れるのいずれかのフォームまたはレポートだ、私は新しいmdbファイルを作成し、のみ（付属）、インポートテーブル、クエリ、スクリプト（一つだけ）、モジュール、およびメニューのことを知っているように。次に、LoadFromTextを使用してフォームとレポートを関数を介してインポートし、通常の逆コンパイルとコンパイルと修復などを行いました。
これまでのところ、私は数日でクラッシュしていませんでしたおそらく、この回復方法に固執するでしょう。
あなたの提案に感謝します。
FWIW、私はLoadFromTextを使用してから〜4wksの重大なクラッシュを経験していないので、SaveAsTextとLoadFromTextを使用した上記のバックアップと復元の方法が最も価値があるようです。 – maxhugen
Oh my。
私は長年にわたって店舗で働いていましたが、彼らの選択のプラットフォームとしてAccessを使用しました。このアプリケーションは最終的に非常に大きくなり、Access 2003の内部メモリ制限を打ち始めました。彼らはあなたと同じ問題を経験し始めました。ご存知のように、これが起こると、メモリの問題の外部表示はありません。
マイクロソフトは問題についてマイクロソフトと長らく話し合いました。マイクロソフトは最終的にマイクロソフトにパッチを提供したと思います。したがって、同じパッチをユーザーに提供できる可能性があるため、体験しているのと同じような状況のように聞こえる場合は、これについてMicrosoftに問い合わせることをお勧めします。
最終的な解決策は、アプリケーションをより小さな部分に分割することです。 Access 2007への移行は役に立たなかった。実際、Access 2007にはより多くの可動部分があるため、状況が悪化しました。
ありがとうRobert。このアプリケーションは実際には非常に小さく、〜40のフォームとサブフォーム、レポートと同じ、〜11,000行のVBAコードです。 MSのサポートに関しては、私は数年前にあきらめました：自分のアプリにバグが見つかったときにそれらを支払うことは、私のお茶ではありませんでした:) – maxhugen
あなたはMSDN購読をしていると無料でインシデントがあります。この特定のケースでは、マイクロソフトは無料でパッチを提供する必要があります。 –
これは、Accessが問題の実際の内容を知らない場合のデフォルトのエラーメッセージです。あなたのMDBが特に大きい場合は、800以上のフォームとレポートをモジュールで作成してください。はい、MDBが大きすぎる可能性がありますが、MDEを作成するときにメッセージが表示されます。 ACC2000: "Microsoft Access Was Unable to Create an MDE Database" Error Message
私はこれを時々自分自身で起こしました。私の現在のMDBはそれほど大きくはありません。コンパクトおよび修復では、表、索引または関係以外のオブジェクトのエラーは検出されません。したがって、これらのエラーを修正する唯一の方法は、別のMDBにインポートすることです。
このMDBはネットワーク上で作業していますか？それは私がこの問題を引き起こす可能性があると考えることができる唯一のことです。
こんにちはトニー：アプリは小さいです。本当のコンパクト/修復は役に立たないので、すべてのオブジェクトを新しいmdbにインポートします。このアプリは開発中に私のローカルドライブに座っているFE/BEです。 ドキュメント化されていない関数Application.SaveAsTextと、Application.LoadFromTextを使用してオブジェクトをバックアップし、インポートできなかった破損オブジェクトを復元しました。 しかし、Accessの不安定さは私には気になっています。ユーザーには時折起こるためです。 – maxhugen
最大、破損したMicrosoft Access MDB http://www.granite.ab.ca/access/corruption/corruptobjects.htm内のリンクの1つに、すべてのオブジェクトを実行するツールがあります。私は確かにそれが破損しているVBAであるかどうかはわかりませんが、Davidの提案も見直すと思います。 –
ありがとうTony。私はArvin Meyerとほとんど同じ機能を持っています。バックアップ戦略の一環として、すべてのオブジェクトをタイムスタンプの付いたフォルダにダンプし、毎日何度も使用します。私はいくつかの腐敗した書式を輸出しており、書式の解読は???????VBAはOKと思われます。 – maxhugen
フロントエンドのVBAプロジェクトが壊れている可能性があります。 （理由の詳細についてはMichael Kaplan's article on DECOMPILEを参照）VBEオプションで
、ON DEMANDでCOMPILEをオフに：あなたは、最初からそれを再構築して、プラクティスをコーディング適切なアクセスを使用する必要があります。
VBEオプションでは、REQUIRE VARIABLE DECLARATIONをオンにします。
VBEでは、ツールバーをカスタマイズして、COMPILEボタンに簡単にアクセスできるようにします（デバッグメニューにあります）。ブレークモードでエラーをデバッグするのに便利なので、VIEWメニューのCALL STACKボタンを追加することをお勧めします。ここでのポイントは、できるだけ簡単にデバッグとコンパイルを行うことです。
あなたの環境を設定したら、新しく回復したプロジェクトのすべてのモジュールを通過し、OPTION EXPLICITをそれがないすべてのモジュールの先頭に追加します。コンパイルしてください。あなたは無効なコードがどこにあるのかをすぐに知り、修正する必要があります。
今から、プログラミングの際、頻繁にコンパイルし、2〜3行ごとに実行してください。私はおそらく、コーディング時に1日に100回以上プロジェクトをコンパイルします。
定期的にプロジェクトを逆コンパイルし、コンパイルして再コンパイルします。これは、定期的な開発中に蓄積するどんな荒れ果ててもきれいにします。
これらのプラクティスは、壊れていないプロジェクトのコードができるだけクリーンな状態にとどまることを保証します。すでに壊れているプロジェクトを復旧するために何もしません。
プロジェクトを再構築する方法に関しては、Application.SaveAsTextを使ってすべてのオブジェクトをエクスポートし、Application.LoadFromTextを使用して新しい空のデータベースにインポートするという劇的な道を行くと思います。インポートは、SaveAsText/LoadFromTextサイクルに耐えられない破損した構造体をインポートできるため、既存の破損したフロントエンドから単純にインポートする方が優れています。
私は、スタンドアロンのクラスモジュールをたっぷり含むコードの多くを使用して非自明なアプリでの作業、Accessで毎日プログラムします。私は5年以上にわたって腐敗をコードするオブジェクトを失っておらず、それはまだA97を使用していた日に戻ってきました。
Davidに感謝します。 Re 1、それは何ですか？ （マイケル・カプランの記事でカバーされていない）2：常にオン。 3：私はいつもコード変更ごとにコンパイルします。 4：常にこれを使用してください。 5：私もたくさんコンパイルします。 6：定期的に逆コンパイル/再コンパイルも行います。私もAccessで毎日10年間働いています。コードを失うことはありません - 私も多くのVBAモジュール/クラスを持っていますが、時々破損したフォームやレポートを取得します。しかし、最近私はこの 'メモリ'エラーが発生している。今日私はほとんどの書類やすべての報告書を失いました！幸いにも、私は昨日からすべてのオブジェクトをテキストバックアップし、LoadFromTextを使用してフォームとレポートを復元しました。 – maxhugen
この記事では、VBAが追跡しなければならないコンパイルレベルの数が増えるため、インクリメンタルコンパイルを望まない理由について説明します。明示的なコンパイルは完全なコンパイルです。 COMPILE ON DEMAND（OPTION | GENERALタブを表示しているときにF1キーを押す）のヘルプファイルの記事をチェックするとよいでしょう。 –
私はこの問題を何度も遭遇し、最終的に働いた解決策を発見しました。問題の原因はわかりませんが、解決方法はわかります。
通常、フォームを開くときにエラーが発生します。あなたがしなければならないことは、そのフォームを完全に再作成することです。これを行う最も簡単な方法は、文書化されていない関数Application.SaveAsTextを使用して、まずフォームをテキストファイルにエクスポートすることです。その後、データベースからフォームを削除し、Application.LoadFromTextでフォームを再ロードします。
は私のこの古いポスト渡ってつまずいた、それは興味の公平なビットを持っています見て、私は多分更新が順番になるだろうと思いましたか？ Accessオブジェクト -
トラックダウンだから、2年、2007年のアプリの多くの仕事をしているだけでなく、2003年の古い（とさえ'97）アプリを、私は2007は2003より本当に厄介なクラッシュを受けにくいことを発見しています定義（フォームとレポートの場合）が簡単に破損する可能性があります。
私はまだDavid-W-Fentonの示唆1-6（上記）に加え、Application.SaveAsText（上記のTony Toewsの提案とリンクを参照）を使用しています。
アクセスがに、任意のヒント与えた場合、それは、私が働いている97、2003または2007のかどうか、これらの日、「変ないるは| をクラッシュ|不可解なエラーを投げ」など、私は次のようにします：
これはすべてを解決するわけではありませんが、アクセスオブジェクトの破損の数を大幅に削減できます。
クイック解決策;仕事に保証：イミディエイトウィンドウで
オープンVBA（Alt-F11） は、次のように入力します。その後、
Application.LoadFromText acForm, "corrupt form name here", CurrentProject.Path & "\zzTempRevive"
Application.SaveAsText acForm, "corrupt form name here", CurrentProject.Path & "\zzTempRevive"
！
'Application.LoadFromText acFormを実行した後、"ここでフォーム名を破損しました "、CurrentProject.Path＆" \ zzTempRevive "ステートメントは_errors.txt_にいくつかのエラーがあります。エラーを修正し、ステートメントを再度実行します。 – yW0K5o
おそらく4GBではなく4GBのRAMを意味します。 –
James - 詳細、詳細。 –
これが4MBだった場合、これは簡単には考えられない問題でした。 – JohnFx