これは、ODBCデータソース（通常はSQL Serverのみではありません）を使用するアプリケーションを開発する際に、Access開発者がAccessをトラブルシューティングして操作するのに役立つODBCトレースに関する6部構成の記事です。このシリーズは、ODBCトレースを使用して、クエリ、フォーム、レポートなどのオブジェクトを操作するとき、またはDAOオブジェクトに対してVBAコードを実行するときにも、バックグラウンドで問題にアクセスするODBCSQLステートメントを監視する方法を示すことを目的としています。このシリーズでは、AccessがODBCSQLステートメントを作成する方法についても説明します。最後に、このシリーズでは、トレースを解釈して潜在的な問題を特定する方法について説明します。シリーズが終了するまで、記事は毎日印刷されます。
更新： 64ビットWindowsに32ビットC2Rをインストールするためのレジストリキーを追加しました。ありがとう、ジャックマクドナルド！
「理由はわかりませんが、ハンドルを振るだけでうまくいく」と聞いたことはありますか？そのような反応を得るたびに、それはとても不満なので私を苛立たせます。私の配管工が、pトラップが何のためにあるのかわからないと言って、それを「流しの下の曲がりくねったもの」と呼び続けたら、私は非常に心配します。同様に、「なぜそのクエリが遅いのかわからないので、ランダムなことをいくつか試したところ、うまくいくトリックを見つけたので、クライアントは非常に心配する必要があります。でも、理由はわかりません。」これはおそらくソフトウェア開発の最大の悩みの種の1つです。私たちは複雑なシステムを使用しており、特定のシーケンスで0と1を非常に高速に切り替えることになり、なぜこの方法ではなくその方法で行われなかったのかを知ることが期待されます。
AccessとVBAを使用する開発者にとって、特にODBCバックエンドを使用して、AccessとVBAが何をしているのかを実際に理解することは時間と投資の価値があると思います。さまざまな理由でサーバー側のプロファイリングツールにアクセスできない可能性がある移行シナリオがありましたが、それが肩をすくめる理由ではなく、何かが機能するまでボタンをランダムにマッシュするだけです。さらに重要なことは、内部で何が起こっているのかをしっかりと理解することで、特定のシナリオに適用する必要のあるパフォーマンスの修正をより正確に予測できるようになることです。シリーズを読んでAccessがODBCデータソースでどのように機能するかを学んだとしても、Accessが何をする可能性があるかを知っているという理由だけで、はるかに優れた装備を身に付けることができます。
より複雑なシナリオの場合、トレースは通常、物事の実行が非常に遅い理由を明らかにするのに不思議に思うことがあります。サーバーではなくAccess側でトレースできるため、ODBCトレースを有効にするためにレジストリキーにアクセスする以外に、昇格されたアクセス許可は必要ありません。追加のボーナスは、これがSQL ServerだけでなくすべてのODBCデータソースで機能することです。したがって、MySQLまたはPostgreSQLを使用しているクライアントが何も知らない場合でも、ODBCトレースは、直接対処できる潜在的な問題を特定するのに役立ちます。アクセス側。
このシリーズは、AccessとDAOのコンテキストからのみ焦点を当てます。 VBAでADOを使用する場合は状況が異なる場合がありますが、DAOを使用する場合は常に、Accessが他の方法では不可能な要求を満たすためにいくつかのことを行うため、現時点では範囲外です。良い例は、VBA関数を参照するAccessクエリです。 SQL ServerでVBA関数を実行することはできませんが、Accessは文句を言いません。では、カーテンの後ろで実際に何が起こっているのでしょうか。 Accessが発行するODBCSQLコマンドをODBCデータソースにトレースすることで、Accessが何を行っているかを知ることができます。
この一連の記事で紹介されている情報の多くは、Jet＆ODBCに関するMicrosoftの古いホワイトペーパーの助けを借りて可能になっています。情報はまだ非常に有益だと思いますが、それはまた非常に密集していて、高度な技術的熟練を必要とします。一連のトレースを実行することで、よりアクセスしやすい方法で情報を理解し、提示するのに役立つことが期待されます。
なぜODBCをトレースする必要があるのですか？どのように役立ちますか？
これらの症状のいずれかを経験したことがある場合：
または、ODBCリンクテーブルを操作する際のその他のエラーの場合は、これらのメッセージが表示される理由とその修正方法を理解しておくと役立ちます。複数のAccess開発者が適用する一般的な修正は、再クエリを追加するか、レコードを保存しようとすることです。これでいくつかの問題は解決するかもしれませんが、複雑なAccessフォームにRequeryがたっぷりと散りばめられているのを見るのは前代未聞ではありません。 そして、パフォーマンスが低下し始めるいくつかのカスケードイベントチェーン。それらを魔法のピクシーダストのように振りかけるのではなく、アプリケーションの問題を修正するためのアプローチをより外科的に行う必要があります。
もう1つの説得力のある理由は、特定のフォームAが開くのに10秒かかるのに、同様のフォームBが開くのに2秒しかかからない理由を分析できることです。時間をかけてシャッフルしてフォームAをすばやく開くものを見つける代わりに、違いをトレースして比較することから始めて、違いに焦点を当てることで、より直接的な方法で問題を解決できます。
パフォーマンスの問題が発生するたびにトレースする必要がない場合でも、Accessが実行する必要があることを熟知していることは、非常に価値があります。したがって、シリーズを読んだだけでも、Accessを使用する方法について、反対するのではなく、よりよく理解できることを願っています。
SQLおよびODBCSQLダイアレクトへのアクセス
詳細に入る前に、AccessがODBCデータソースを操作するときは常に、最初にそのSQLステートメントを有効なODBCSQLステートメントに変換する必要があることを認識する必要があります。これは、バックエンドのターゲットSQLダイアレクト（SQL Server、Oracle、MySQL、PostgreSQLなど）とは異なります。ここでは、ODBCSQLの文法について説明します。 ODBCレイヤーでサポートされているすべての機能のリストも表示されます。 ODBCを使用している場合、実際にはAccessSQLからデータソースのネイティブSQLダイアレクトに直接変換していないことを覚えておくことが重要です。むしろ、AccessSQLをODBCSQLに変換し、指定されたデータソースのODBCドライバーがネイティブダイアレクトに変換します。お互いの言語を話さないが、両方とも英語を話す日本語話者とフランス語話者を想像できるとしたら、それは基本的にODBCレイヤーで起こっていることです。さらなる結果は、ODBC方言が機能Xをサポートしているからといって、どちらの側もそれをサポートしているという意味ではないということです。 ODBCレイヤーを介して移植できるようにするには、両方の側がその機能Xをサポートする必要があります。幸いなことに、そこにあるほとんどのODBCドライバーはかなり幅広く、ほとんどの機能をうまくカバーしています。機能が機能するはずなのに機能しない状況が発生した場合は、ODBCドライバーのドキュメントを参照して、サポートされていることを確認することをお勧めします。
ODBCSQLトレースの有効化
カーテンの後ろを覗くことができるようにするために最初に行うことは、ODBCSQLトレースを有効にすることです。 SQL Server Profilerを使用することはできますが、AccessがODBCSQLをどのようにフォーマットするかを確認することは非常に役立ちます。 SQL Serverだけでなく、すべてのODBCデータソースで機能します。さらに重要なことに、これにより、AccessがSQLServerProfilerやその他のサーバー側プロファイリングツールよりも直接的な方法でクエリをODBCに変換する方法を確認できます。 ODBC SQLトレースを使用するために特別なアクセス許可は必要ありませんが、サーバー側のプロファイリングツールを使用するには高レベルのアクセス許可が必要な場合があります。 ODBC SQLトレースの有効化はレジストリ設定であるため、適切なレジストリキーに移動してこれを構成できます。
2007より前のJetデータベースまたはOfficeバージョン
32ビットWindowsの場合：
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines\ODBC
32ビットJetエンジンまたは64ビットWindows上の2007以前のOfficeの場合：
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Jet\4.0\Engines\ODBC
注：廃止されたJetエンジンの64ビットバージョンはありません。
Office 2007から2016（MSIインストール）
32ビットWindows上の32ビットOffice、または64ビットWindows上の64ビットOfficeの場合：
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\X.Y\Access Connectivity Engine\Engines\ODBC
64ビットWindows上の32ビットOfficeの場合：
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Office\X.Y\Access Connectivity Engine\Engines\ODBC
（ここでX.Y インストールしたOfficeのバージョンに対応します）
Office2016またはOffice365（クリックして実行）
32ビットWindows上の32ビットOffice、または64ビットWindows上の64ビットOfficeの場合：
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Microsoft\Office\16.0\Access Connectivity Engine\Engines\ODBC
64ビットWindows上の32ビットOfficeの場合：
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Wow6432Node\Microsoft\Office\16.0\Access Connectivity Engine\Engines\ODBC
キーの下で、キーTraceSQLModeを見つけます 値を0から変更します 1へ 。
アクセスが既に開いている場合は、アクセスを再開する必要があります。それ以外の場合は、それを開いていくつかのクエリを実行します。 sqlout.txtという名前のファイル 現在のディレクトリに作成されます。これは通常、Accessファイルと同じフォルダまたはドキュメントフォルダのいずれかにあります。または、VBA関数CurDirを実行することもできます。 現在のディレクトリを決定します。
Notepad++またはそれが変更されたことを検出する機能を備えた同様のテキストエディタを使用することをお勧めします。次に、ファイルをリロードするように求められます。これにより、Accessがテキストファイルに新しいコマンドを発行するときに、定期的に再度開くことなく、新しい更新を表示できます。テキストファイルをアクティブにすると、Notepad++にダイアログが表示されます。
次に、[Yes]をクリックします。 Accessによって発行された最新のODBCSQLコマンドを確認します。 Accessは複数のODBCSQLコマンドを発行できるため、ログは急速に大きくなる可能性があります。何かをトレースしたい場所（たとえば、フォームを開いたり、クエリを実行したりする）に到達すると便利だと思います。次に、sqlout.txtに切り替えます。 、リロードしてからすべてを選択し、すべてのテキストを削除してから、空になったファイルを保存します。そうすれば、トレースしたいアクションを実行して、トレースされているアクションとは関係のない他のすべてのノイズなしで、関連するODBCコマンドのみを表示できます。
デモ用の簡単なビデオは次のとおりです。
結論
ODBCトレースをオンにして、Accessによって生成された出力を表示する方法を学習しました。テーブルを開く、クエリを実行するなどのアクションからでも出力を収集できることがわかります。これにより、Accessが実際にODBCデータソースに送信しているSQLクエリの種類を把握できます。
ご覧のとおり、ODBC SQLトレースは、直接発行しなかった場合でも、Accessによって発行されたすべてのODBCSQLコマンドをキャプチャします。したがって、適切な説明がないために速度が低下している任意の時点で使用できます。例として、開くのが遅いフォームがあり、それがフォームのOpenのVBAコードであるかどうかわからないとします。 またはLoad 問題となっているイベントまたはレコードソース。戦略は、そのフォームを開こうとしているようにAccessアプリケーションを設定し、sqlout.txtをクリアすることです。 次に、テキストファイルを開いてフォームを開きます。次に、トレースされたODBC SQLステートメントを確認して、改善できるものがあるかどうかを判断できます。
これは、サブフォーム/サブレポートも含む、または行ソースプロパティを満たすために独自のクエリを発行するコンボボックスまたはリストボックスを含む複雑なフォームまたはレポートを処理する場合に特に役立ちます。
次の記事では、レコードを参照するときに出力を分析します。
Microsoft Accessのサポートが必要ですか？ 773-809-5456で私たちのチームに連絡するか、[email protected]で私たちに電子メールを送ってください。