オンデマンドでこのエラー状態を再現できるはずです:
1. データベース接続を開く (クライアント アプリケーションで)
2. ネットワーク ケーブル
を抜く 3. ネットワーク ケーブルを再び差し込む (ネットワーク接続が回復するまで待つ)
4. を使用するデータベースを照会するために以前に開かれた接続
私が経験から知る限り、クライアント側の ADO コードは、基盤となるネットワーク接続が実際に有効かどうかを一貫して判断することはできません。データベース接続が (クライアント コードで) 開いているかどうかを確認すると、true が返されます。ただし、その接続に対して何らかの操作を実行すると、General network error.
接続プールは、接続がいつ「不良」になるかを判断できるように見えるため、不良な接続をアプリケーションに返すことはありません。代わりに、単に新しい接続を開きます。
そのため、データベース接続がアプリケーションによって長期間 (使用または未使用で) 維持されると、基盤となる TCP/IP 接続が切断される可能性があります。
肝心なのは、データベース接続が使用されていないときは閉じて、接続プールに戻す必要があるということです。
編集
また、データベースに接続しているクライアントの数によっては、接続プールを使用しないと別の問題が発生する可能性があります。サーバー側で開いているソケットの最大数に達する可能性があります。これは記憶からです。クライアント側で接続が閉じられると、サーバー上の接続は TIME_WAIT 状態になります。デフォルトでは、サーバー ソケットが閉じるのに約 4 分かかるため、その間、他のクライアントは使用できません。肝心なのは、サーバーで使用できるソケットの数が限られているということです。あまりにも多くの接続を開いたままにしておくと、問題が発生する可能性があります。
私が取り組んだ 1 つのプロジェクトでは、約 120 人のユーザーでこのソケット制限に簡単に達しました。サーバーに完全に打撃を与える新しい「機能」が追加され、アプリを数時間使用した後、突然、すべての人がクロールするように遅くなりました. SQL サーバーは、新しい接続要求に間に合うように十分なソケットを閉じていませんでした。全体で 65K のソケットがありますが、ADO で使用できるのは最初の 5000 個だけです (これは既定のレジストリ設定なので、変更できます)。
TIME_WAIT 状態のソケットの数は、OS がそれ以上割り当てられなくなるまでゆっくりと増加します。そのため、クライアントはサーバー側のソケットが閉じられ、新しい接続が作成されるまで待たなければなりませんでした。