MSAccessのクラッシュを診断する方法

Question

Accessで記述されたカスタムプログラムがあり、奇妙なクラッシュが発生しています。独自のコード内で発生したクラッシュを記録して電子メールで送信するエラー処理を追加しました。これにより、生成されたほとんどのエラーを修正できますが、コードの外部でクラッシュが発生する場合があります。

2013年に新しく作成されたものの例（特定のフィールドのデータを編集するとクラッシュするフォームがあります）新しいエントリは問題ありませんでしたが、レコードの作成後に編集すると完全にクラッシュし、 MSAccessのシャットダウン。私たちは時間を費やし、最終的に、フォームの一部のコードがフォームを次のレコードに移動するように強制していることを追跡しました。このフィールドは行の最後のフィールドでしたが、Access自体も次のレコードに移動しようとしていました。これは2007年からシステムにありましたが、2013年にプログラムのシャットダウンを引き起こし始めました。

mS Access内のプログラムレベルのクラッシュをトラップして診断する方法はありますか？
Windowsイベントビューアには、次の情報のみが表示されます。

障害のあるアプリケーション名：MSACCESS.EXE、バージョン：15.0.4454.1501、タイムスタンプ：0x50a35ef4障害のあるモジュール名：MSACCESS.EXE、バージョン：15.0.4454.1501、タイムスタンプ：0x50a35ef4例外コード：0xc0000005障害オフセット：0x00116452障害のあるプロセスID：0x1398障害アプリケーションの開始時刻：0x01ce6e665043d8be障害のあるアプリケーションパス：C：\ Program Files（x86）\ Microsoft Office\Office15\MSACCESS.EXE障害のあるモジュールパス：C：\ Program Files（x86）\ Microsoft Office\Office15\MSACCESS.EXEレポートID： 6cfcb0eb-da62-11e2-8966-842b2b86f028

Answer 1

これは古いスレッドですが、グーグルでトップの結果の一つとして出てきたので、答えたいと思いました。 「Accessで問題が発生したため、閉じる必要があります」というメッセージが表示された場合、どのような手順を実行できますか。通常、イベントログには次の内容が表示されます。

Faulting application name: MSACCESS.EXE, version: 15.0.4869.1000, time stamp: 0x57e12b41
Faulting module name: MSACCESS.EXE, version: 15.0.4869.1000, time stamp: 0x57e12b41
Exception code: 0xc0000005

これらはトラブルシューティングにイライラする可能性があります。以下は、私がとる行動のリストです。最も侵襲性の低いものから最も侵襲性の高いものまでです。私はこれらの修正を発明しているだけではありません-何年にもわたって、各修正が問題を解決するのを個人的に目撃してきました。

データベースの逆コンパイル

あなたは、すべてのリリースを逆コンパイルすることがポリシーであることを示しました。良いポリシーですが、エラーが発生するたびに明示的に実行してください。その理由は、コアの問題を修正している可能性があるが、コンテナーが破損しているために気付かないためです。

• 「/ decompile」スイッチを使用してデータベースをロードするショートカットを作成します。
• このショートカットをダブルクリックするときにShiftキーを押したままにすると、自動実行がスキップされ、ナビゲーションウィンドウに直接移動します。
• データベースがロードされたら、[圧縮して修復]ボタンをクリックする必要があります。データベースがリロードされるときに、Shiftキーをもう一度押し続けます。
• 次に、コードをコンパイルして保存します。それが私が逆コンパイルに使用するプロセスです。

コンピュータメモリのテスト

特にクラッシュが1台または2台のマシンに制限されている場合は、これを実行してください。
イベントビューアを確認してください。アプリケーションのクラッシュを説明する「エラー」メッセージがかなりあり、障害のあるモジュールが異なりますか？もしそうなら、それが壊れたウィンドウズのインストールでなければ、あなたはメモリの問題を見ている可能性が高いです。

優れたメモリテスタはたくさんあると思いますが、ドロップされたビットをキャッチする適切なテストを使用することをお勧めします。 MemTest86はオールディーズですが、良いものです。 現在のバージョン といくつかの同様に良い フォーク があります。

テストを開始し、勤務時間中に実行します。建物の電源が悪いとメモリエラーが発生するので、変数を同じに保ちます。

フォームからバイナリデータを削除

クラッシュは、単一のフォームまたはレポートで発生する場合があります。破損したバイナリデータの場合、クラッシュはさまざまなユーザーのさまざまなコンピューターで発生しているはずです。この場合は、次の手順に従ってください。 （上級ユーザーのみ）

1. 即時ウィンドウで、オブジェクトをテキストとして保存します。

   Application.SaveAsText acForm、 "MyForm"、CurrentProject.Path＆ "\ MyForm.txt"

2. 元のフォームアイテムの名前を変更します（例：MyForm_Bakに名前を変更します）

3. エクスポートしたファイルをメモ帳で開きます
4. 「Checksum =」行を削除します（3行目にある必要があります）
5. バイナリデータを消去します
   • ファイルに目を通します。
   • 「Parameter = Begin」で始まり、エンコードされたバイナリデータの行があり、「End」で構成される行で終わる行があります。
   • これらの行の1つを見つけたら、最初から最後まですべての行を（包括的に）削除する必要があります。
   • 削除する必要のあるパラメーターは、NameMap、PrtMip、PrtDevMode、PrtDevNames、PrtDevModeW、PrtDevNamesWです。
   • これらのブロックはすべて、フォームコントロール定義の前に表示されます。
6. ファイルを開いている間に、ファイルの残りの部分をスクロールして、特に下部のVBAモジュールコードで、目を引くものを探します。
7. ファイルを保存します

8. Accessのイミディエイトウィンドウで、フォームをロードし直します。

   Application.LoadFromText acForm、 "MyForm"、CurrentProject.Path＆ "\ MyForm.txt"

9. 逆コンパイル/コンパクト修復/再コンパイル

10. フォームを開くと、うまくいけばすべてがうまく機能しています。

「OLEオブジェクト」フィールドを削除する

Access自体に画像やその他のデータが保存されている場合は、より良いアプローチを見つける必要があります。 OLEデータが保存されると、それを保存しているコンピューター上のソフトウェア（およびソフトウェアのバージョン）に従って保存されます。別のコンピューターがそのOLEオブジェクトデータをフォームに表示しようとしたが、正確なソフトウェア/バージョンがインストールされていない場合、クラッシュすることがよくあります。

画像データを保存する場合は、ファイル名を保存し、代わりに画像を標準の場所に保存することをお勧めします。新しいバージョンのアクセスには、これを実現するためのネイティブコントロールがあります。

データベース全体を再構築する

これは大変な作業なので、他のすべてのオプションを使い果たしたときのためにこれを保存しておきます。これを行う必要があるのは、すべてのユーザーで問題が発生している場合のみです。すべてのユーザーで発生しているわけではない場合は、データベースが破損しているわけではありません。

バイナリデータを削除する手順と同様に、データベースを最初から再構築します。このステップに到達するまでに、私は完全な妄想モードになっています。少し儀式的かもしれませんが、直接コピーやインポート/エクスポートによって破損を「保存」しないように、近道をせずに細心の注意を払ってすべてを行います。私の最後の抵抗として、これが問題の解決に失敗したことはないと思います。ありがたいことに、Access 2000の時代から、これを行う必要はありませんでした。

• 新しいAccessデータベースコンテナを作成します。
• インポート/エクスポート機能は使用しないでください
• 表：
  • 古いアクセスコンテナ内のテーブルごとに、新しいコンテナ内に新しいテーブルを作成します。デザインビューから、フィールド定義をコピーして貼り付けます。
  • 古いデータをXMLまたはCSVにエクスポートしてから、そこからインポートします。
• クエリ：
  • 元のクエリのSQLビューに移動し、SQLテキストをコピーして新しいデータベースのクエリに貼り付けます。
• フォーム/レポート：
  • Application.SaveAsText関数を使用して、フォーム/レポートをエクスポートします
  • フォームからバイナリデータを取り除き、確認します
  • Application.LoadFromText関数を使用してそれらを再インポートします
• マクロ
  • マクロを再作成します。
  • Access 2007以降では、新しいマクロシステムを使用すると、マクロを開き、すべてを選択（Control + A）して、空白のメモ帳ドキュメントに貼り付けることができます。メモ帳からもう一度コピーして、新しいアクセスコンテナ内の空白のマクロに貼り付けます
• モジュール
  • すべてのコードを選択し（Control + A）、新しいデータベースコンテナに貼り付けます（Control + V）
• データマクロ
  • データマクロが出てきたので、これを行う必要はありませんでしたが、SaveAsText/LoadFromText関数を使用して、テーブルからデータマクロをエクスポートします。

すべてのことを言い終えたら、非常にクリーンなデータベースコンテナが必要です。

テストから他の変数を削除する

ネットワークの破損

ネットワークからクライアントをロードしないでください。ローカルドライブに配置し、そこから実行します。

企業ビルド

「コンピュータービルド」を使用している企業環境で、逆コンパイル、メモリのテスト、およびバイナリデータの削除に成功しなかった場合は、ITチームがユーザーに次のようなテストマシンを提供できるようになるまで、それ以上のテストを拒否します。 Windows、Office、およびServicePackのみがインストールされています。私は通常、自分でインストールすることを好みます。そうすれば、信頼できることがわかります。すべてのソフトウェアとアップデートは、無人インストールを使用せずに手動でインストールする必要があります。このマシンにアンチウイルスをインストールしないでください。

私はIT部門にこれを完全なF.U.D.から拒否させました。そして不合理-これがあなたが遭遇するものであるならば、「私があなたを助けるのを手伝ってください」という文脈の下で問題の手を洗ってください。

バッドパワー

メモリのセクションで述べたように、電力の変動はコンピュータエラーを引き起こす可能性があります。データベースが工業ビルにある場合は、クリーンな電力を供給するパワーコンディショナーまたはUPSを手に入れてみてください（金属酸化物バリスタを通過するメインからではなく、バッテリーから）

また、電源バーまたはコンセントに接続されている電源ケーブルを確認してください。ゲージと電圧の仕様が十分であることを確認してください。これは、IT部門がステーションに電源ケーブルを接続したままにして、マシンを取り外すだけであることが多いためです。何年も経った後、彼らはより強力な電源を使用していますが、ケーブルを切り替えていません。それは違いを生みます。疑わしい場合は、新しい太いケーブルを持参してください。

補遺

最初にこれを投稿して以来、私はいくつかの新しいものに出くわしました。 Access 2016に移行するときに何度も私を襲ったのはODBCドライバーです。Access2013では正常に動作するが、Access 2016では非常に確実にクラッシュするデータベースがある場合、問題はODBCドライバー。オフホップで、更新されたドライバーがあるかどうかを調べてみてください。そこで成功しない場合は、新しいデータベースを作成し、VBSでODBC呼び出しを行って、それがODBCドライバーであるかどうかを確認します。同じクラッシュが発生した場合は、そのドライバーです。更新されたドライバーがない場合は、2013年のままにしておく必要があります。いくつかのデータベースを備えたPostGreSQL ODBCドライバーでこれに遭遇しました。

Answer 2

すべてのAccessデータベースのすべてのフォームのすべての関数には、次のようなフローが必要です。

Private Sub btnMyButton_Click()
Dim MyVar as String
On Error GoTo ErrorHappened

'Do some stuff here...

ExitNow:
    Exit Sub

ErrorHappened:
    MsgBox Err.Description
    Resume ExitNow
End Sub

ErrorHappenedセクションでは、バグを追跡するテーブルに書き込むことができます。すべてのサブと関数をこのようにフローするように変更すると、データベースにあるすべての問題をトラップできるはずです。たぶん、Err.NumberとErr.Descriptionを書きます。

Answer 3

グーグルでこのスレッドに出くわした他の人のために、ここにランダムアクセスクラッシュの別のいくつかの原因があります：

背景として、サーバー上のリンクされたテーブルからデータをロードするサブフォームを含むフォームがあります。

• 親フォームのフィールドに「_Enter」イベントがある場合、Accessが無限ループに入り、これらのイベントが繰り返し発生する可能性があります。これは、サブフォームを表示していて、親フォームのボタンを押したときに発生しました。これらすべてを「_GotFocus」イベントに置き換えて、問題を修正しました。

• 親フォームであっても、onLoadでサブフォームを参照しないでください。これはランダムで、フォームは正常に読み込まれ、次に同じレコードで同じフォームに入ると、Accessがクラッシュしていました。そのため、親フォームのonLoadイベントでサブフォームへのすべての参照を削除しましたが、正常に機能しているようです。私は特にインターネット接続が遅いときにこれに気づきました。メインフォームはサブフォームの前にロードされていたようで、それを参照するとロードされなかったため、Accessであらゆる種類の問題が発生し、不変にランダムにクラッシュしました。アクセスの。

Answer 4

Access 2010を使用しています。[ファイル]-> [オブジェクトを名前を付けて保存]-> [フォームの名前をレポートとして]に移動して、レポート（特定のフォームの真のコピー）を作成しました。デザインビューでレポートを開いたとき、いくつかの変更を加えた後、変更を保存しようとしました。アクセスがクラッシュし続けました。ようやく何時間も経った後、レポートにいくつかのボタンが含まれていることがわかりました。これらをコントロールボックスに交換したとき。それだけです。すべてがうまく機能しています。これにより、何を探すべきかわからない貴重な時間を節約できることを願っています。