ADOでConnectionを開きっぱなしだと拙いですか？ (ID:86637)

名前

ホームページ(ブログ、Twitterなど)のURL (省略可)

本文 > ADOでConnectionを開きっぱなしだと拙いですか？ 画面表示等を伴わないプログラム(バッチ的な更新処理など)の場合は、 いちいち切断せず、連続で処理した方がスマートでしょう。 画面表示を伴うようなアプリの場合は、どちらとも言えません。 Connectionを切断するかどうかは、設計手法によるでしょうね。 抽象的な話になりますが、ADO以前のミドルウェアでは、起動時に接続して、 終了時に切断する形態が多く取られていました。が、ADO や ADO.NET などでは、 (データの取得や更新などが)必要な時にだけ接続し、不要な時は切断する 形態の方が好ましいとされています。 これは、一般的なアプリケーションの多くが、データを取得/更新している 時間よりも、画面に表示されたデータをユーザーが処理するを待っているだけの 無通信時間の方が長いためです。不要なコネクションを開き続けていると、 サーバーリソースを、その分、圧迫する事になりますからね。 (ADOには、切断された状態でRecordsetを更新するための機能が備わっています) なお、接続と切断を繰り返すため、トータルの処理時間は長くなりますが、 接続プーリング機構を利用する事で、この問題に対処する事ができます。 とはいえ、Jet の場合は、処理が(サーバではなく)クライアント上で 行われますので、他のデータベースほどには問題が顕在化しません。 接続を張り続ける方が、コーディングとしては容易ですから、 今の形態のままでも良いと思いますよ。 > 更新結果が最適化ファイルに反映されない現象が発生します。 そのような現象に経験した事がないため、何とも言えませんが、まずは 更新前後でトランザクションを利用しているかを確認してみてください。 1レコードだけを更新する場合でも、トランザクション処理は重要です。 Jetの場合、BeginTrans無しで更新処理を行った場合、その更新処理は 「非同期」で行われる事になります。この場合、SQL文やAddNew等で 処理した結果が、若干のタイムラグを伴う可能性があります。 (BeginTrans/CommitTransをしていれば、同期更新になります) http://www.canalian.com/workshop/access/JetCache.html それと、ローカルのHDDの空き容量が十分にあるかなども確認してみてください。 > レコードセットのいくつかををdatファイル化しているのですが datファイル、というのが少々曖昧ですが、イメージ的には、 ADODB.RecordsetのSaveメソッドで、データをファイル化するような 感じの処理を想像すれば良いのでしょうか? > やはり更新処理毎にコネクションもクローズしないと更新 > 結果のMDBへの保存は保証されないのでしょうか？ 再Openする事で保証されるのは、リードキャッシュだけで、 非同期処理のライトキャッシュに関しては別問題かと。