edbデータベースの多様なコレクションからデータ（ダンプと列の選択的読み取り）を抽出しようとしたときに、根本的な問題に直面しました。いくつかのログファイルが付属しているedbデータベースがあります。データベース内にどのような情報があるかはわかっていますが、その半分だけが抽出されています。残りの半分がログファイルのどこかで眠ってしまうのではないかと心配しています。EDBエンジンはログファイルの場所を認識しており、データベースを接続するときに自動的にログファイルをロードすると仮定しました（JET_paramSystemPath、JET_paramLogFilePath、およびJET_paramBaseNameが適切に設定されています）。それは間違った仮定ですか？もしそうなら、ログもロードするにはどうすればよいですか？
または、トランザクションをEDBファイルにコミットして、ログを削除することもできますか？
コミットされていないトランザクションがある場合、データベースは「不整合」としてマークされます。これは、データベースに対してESENTUTL/MHを使用して確認できます。一貫性のないデータベースに対してJetAttachDatabaseを呼び出すと、常に失敗します。
したがって、プログラムがデータベースをアタッチして開くことができる場合、それは一貫しています。データベースの一貫性を保つには、次の2つの方法があります。
JetInitが最初に行うことは、JET_paramLogFilePathおよびJET_paramBaseNameで指定されたログファイルを探すことです。ログファイルには、参照するデータベースのフルパスが含まれ、ログファイル内のトランザクションはデータベースにコミットされます。したがって、システムパラメータを適切に設定すると、ESENTはデータベースを接続するときにログをロードします。
一方、パラメータを適切に設定しないと、プログラムは実際にはリカバリを必要としないデータベースで動作します。JetInitはログファイルを検出しないため、何も実行せず、データベースに一貫性があるため、接続は成功します。
もう1つの工夫は、ログファイルにデータベースへのフルパスが含まれていることです。これは、データベースをコピー/移動した場合、リカバリが機能しないことを意味します。Windows Server 2003以降では、JET_paramAlternateDatabaseRecoveryPathをデータベースを含むディレクトリに設定することでこれに対処できます。
重要：安全のために、常に読み取り専用フラグを使用してデータベースを接続して開く必要があります。これにより、ログファイルの設定が正しくないために発生する問題を回避できます。一般的な問題は、読み取り専用アプリケーションが別のディレクトリに一連のログファイルを作成してしまい、データベースが適切に回復されないことです。