私はこのトピックについて広範な調査を行い、同僚と集中的に議論しました。
一般的なコンセンサスは、データベース接続は必要なときに開き、すぐに閉じるべきだということです。接続のキャッシング/プーリングは、アプリケーション自体ではなく、データベース ドライバーまたはその他のレイヤーで行う必要があります。
しかし、Jet/ADO に関しては疑問があります。Jet や ADO は読み取りキャッシュと遅延書き込みを使用するため、「同期されていない」接続が発生する可能性があります。もちろん、JRO を使用して接続を使用するたびに再同期することもできますが、それはかなり面倒で、パフォーマンスが低下する可能性があるようです。
各接続を閉じてすべての新しい接続を再同期するという「ベスト プラクティス」を使用する必要がありますか、それとも Jet/ADO の癖のためにグローバル接続オブジェクトを使用する必要がありますか?
Jet/ACE の問題の 1 つは、ロック ファイル (*.ldb) を作成すると、パフォーマンスが大幅に低下する可能性があることです。また、LDB がすでに存在する場合 (別のユーザーが接続されているため)、ロックの設定にかなりの時間がかかることがあります。
したがって、アプリが接続する回数を最小限に抑える必要があります。これは、LDB ファイルを絶えず再作成して再接続することに時間を浪費する可能性があるためです。
Access アプリでは、永続的な接続を維持することが多くのプログラマーの間で一般的に行われています。
通常は、非表示のフォームでテーブルを開くか、テーブルのレコードセットを開くことをお勧めします。バックエンドを指すデータベース変数を初期化することを好みます。引用された記事での Tony の反論は、私にはまったく重要ではないように思えます。たとえば、Mid(CurrentDB.TableDefs("MyLinkedTable").Connect, 11) などの接続文字列を解析することはそれほど難しくありません。
これは Jet/ACE データベース エンジンの問題であるため、Access 以外のコンテキストでも同じ問題が発生します。もちろん、開いた接続を維持する特定の方法は異なりますが、ポイントは、接続を開いたままにしておくことは、ロックファイルに対する db エンジンによる競合が少なくなることを意味するということです。
VB6 デスクトップ アプリケーションには 1 つのグローバル接続を使用するのが最善だと思います。理想的には、データベース ドライバーは透過的に接続プールを管理しますが、VB6 で ADO または DAO と共に Jet を使用している場合はそうではありません。OLE DB Jet プロバイダーには接続プールがありません。私は、.NET プロバイダーがそうしていると信じています。
あなたのアプリケーションはデスクトップ アプリであると想定していますが、実際には指定していません。IIS アプリケーションや COM+ の経験がないため、何が最適かわかりません。おそらく、Jet Access を使用しないでください。ただし、デスクトップ アプリでは問題ありません。
最新の DBMS のほとんどは、接続を管理するために ConnectionPool を提供しています。ただし、connection.close(); を使用する場合。接続を実際に閉じるのではなく、接続をプールに戻すだけで、connection.open(); を書き込むときに接続を閉じます。実際には、新しい接続を作成するのではなく、ConnectionPool で準備された接続を取得して使用するだけです。
したがって、クエリを DBMS に渡すたびに接続を開いて閉じることが最善の方法であり、パフォーマンスに問題はありません。さらに、複数のデータ リーダー SQLDataReader で同じ接続を使用することはできません。
そのため、特に Web サイトを開発する場合はグローバル接続を使用しないでください。これは、サイトに大量のトラフィックがある場合、2 人のユーザーがページを解析しているときに例外がランダムにスローされ、2 人のデータ リーダーが同じ接続を使用しようとするためです。