【テクニカル・上級編】【初心者】CurrentDb.ExecuteとDoCmd.RunSQL:実行時の「警告メッセージ」を制御するスマートな方法 – Access VBA解析バイブル

スポンサーリンク

Accessの「警告」を制する者は、基幹システムを制す:CurrentDb.Execute の極意

Access開発の現場で、初心者から一歩抜きん出るための登竜門がある。それは「アクションクエリ実行時の警告ダイアログ」との付き合い方だ。

多くの駆け出しエンジニアは `DoCmd.SetWarnings False` を使って警告を消し、処理が終われば `True` に戻すという場当たり的な実装を行う。だが、大規模なシステムにおいてこの手法は「悪手」だ。エラーハンドリングで処理が中断された際、警告メッセージが非表示のまま残るという致命的なバグを誘発するからだ。

真のエンジニアは `DoCmd.RunSQL` に頼らず、`CurrentDb.Execute` を掌握する。今日は、その理由と、メモリの断片化やリソース消費を最小限に抑える「アーキテクト流の実装」を伝授しよう。

1. なぜ `DoCmd.RunSQL` は「レガシーの遺物」なのか

`DoCmd` はAccessのUI操作をプログラムからシミュレートするためのインターフェースだ。つまり、内部的には「ユーザーが画面を操作している」のと同等のオーバーヘッドが発生する。

対して `CurrentDb.Execute` は、DAO(Data Access Objects)を直接叩く。UIを介さない分、処理速度は圧倒的に速く、メモリの消費もクリーンだ。何より、「警告を出さない」ことがメソッドのデフォルト仕様であるという点が、システム運用におけるリスクを激減させる。

2. 現場で使える「最強の実行パターン」

単純にメソッドを叩くだけでは、エンジニアとしての仕事は半分だ。実行結果の検証(RecordsAffected)を組み込み、トランザクションを意識した書き方が、堅牢なシステムを構築する。

‘ @brief アクションクエリを安全に実行するアーキテクト・テンプレート
Public Sub ExecuteQuerySafely(ByVal strSQL As String)
Dim db As DAO.Database

‘ CurrentDbを直接呼ぶと都度新しい参照が生成され、メモリリークの温床になる。
‘ 変数に格納して利用するのが鉄則である。
Set db = CurrentDb

On Error GoTo ErrorHandler

‘ dbFailOnError オプションを付与せよ。
‘ これにより、クエリ実行時にエラーが発生すれば即座にトラップされる。
‘ ロールバックが必要な複雑な処理には必須のパラメーターだ。
db.Execute strSQL, dbFailOnError

‘ 処理された行数を確認し、ログやデバッグに活用する
Debug.Print “影響を受けたレコード数: ” & db.RecordsAffected

Cleanup:
‘ オブジェクトの明示的解放。VBAの参照カウンタを過信してはならない。
Set db = Nothing
Exit Sub

ErrorHandler:
MsgBox “クエリ実行エラー: ” & Err.Description, vbCritical
Resume Cleanup
End Sub

3. シニアエンジニアが意識する「隠れた最適化」

CurrentDb のキャッシュ管理

`CurrentDb` は呼び出すたびに新しい Database オブジェクトのインスタンスを生成する。ループ内で `CurrentDb.Execute` を繰り返すような愚行は避けねばならない。必ず一度変数に格納(Set)し、そのインスタンスを使い回すこと。

トランザクションの重要性

複数のテーブルを更新する場合、`db.Execute` を連発するだけでは不十分だ。データの一貫性を保証するために `db.BeginTrans` と `db.CommitTrans` を併用せよ。万が一の障害時に、データベースを破壊から守る最後の砦となる。

Windows API との連携(発展)

もし、クエリ実行中に外部システムとの疎結合を維持する必要がある場合、`DoEvents` を適切に配置してUIのフリーズを防ぐ必要がある。さらに高度な監視が必要な場合は、`GetTickCount` API を利用して、クエリの実行にかかったミリ秒を計測し、実行計画のパフォーマンス分析に役立てるのがプロの流儀だ。

結論:技術の「作法」がシステム寿命を左右する

初心者とシニアの境界線は、コードが動くかどうかではなく、「異常系をどれだけ想定できているか」にある。

`DoCmd.SetWarnings` を多用するコーディングは、場当たり的な修正を繰り返す泥沼の始まりだ。`CurrentDb.Execute` を使い、`dbFailOnError` でエラーを能動的に拾い上げ、オブジェクトを綺麗に解放する。この「作法」を身につけることが、10年先も稼働し続ける堅牢なAccessシステムを作る唯一の道である。

次は、あなたのコードから不要な `SetWarnings` を消し去ることから始めよう。それが、伝説への第一歩だ。

タイトルとURLをコピーしました