【テクニカル・上級編】CurrentDbとDBEngine(0)(0)の使い分け：DAOの接続効率を最大化するメモリ管理術 – Access VBA解析バイブル

Access VBAを掌握する極限の知見：CurrentDbとDBEngine(0)(0)のメモリ管理と接続効率の極意

レガシーシステムの寿命は、往々にして「データベース接続の雑さ」によって縮められる。
数万件のレコードをループ処理するバッチ処理、多重化されたフォーム、そしてリファクタリングされることなく継承されてきたスパゲッティコード。その中で、Access VBAの開発者が最も軽視し、そして最もシステムを崩壊させているのが DAO（Data Access Objects）のセッション管理 である。

今回は、DAOの接続基盤である `CurrentDb` と `DBEngine(0)(0)` の本質的な違いを解剖し、大規模データ処理におけるメモリリークの根絶とパフォーマンスの極限最適化について、アーキテクトの視点から解説する。

—

1. 内部構造の真実：CurrentDb と DBEngine(0)(0) の決定的な違い

多くのプログラマは、データベースオブジェクトを取得する際に「なんとなく」でこれらを使い分けている。しかし、オブジェクトのライフサイクルとメモリの観点から見れば、両者は全く異なる振る舞いをする。

CurrentDb メソッド：オーバーヘッドを代償にした「安全なキャッシュ」

`CurrentDb` はメソッドである。呼び出されるたびに、現在のデータベースへの新しい ADO/DAO接続インスタンス（正確には内部的なコールド/ホットなワークスペースの参照）を生成し、ローカルキャッシュに保持 する。

• メリット: 現在のユーザーセッションやトランザクション状態と完全に同期し、UIスレッドとの整合性が保たれる。
• デメリット: 呼び出しごとに内部でオブジェクトの構築・破棄（あるいはキャッシュの参照チェック）が発生するため、数千回・数万回のループ内で呼び出すと、凄まじいパフォーマンス劣化を引き起こす。

DBEngine(0)(0) 属性：インスタンス直撃の「生ポインター」

一方、`DBEngine(0)(0)` は、現在開いているデータベース（DefaultWorkspaceの最初のデータベース）への永続的な直接参照（ダイレクトポインター）である。

• メリット: オーバーヘッドが極めて小さく、最速でデータベースオブジェクトを返す。
• デメリット: カプセル化の概念を無視した生の状態に近いため、不適切な解放やマルチスレッド（Access内での非同期処理やアドイン環境）において予期せぬCOM例外やメモリリークを引き起こすリスクがある。

—

2. ベンチマークが暴くパフォーマンスの現実

10万件のレコードに対するトランザクション処理において、両者のアプローチがどれほどの速度差を生むか。体感レベルではなく、構造的な負荷の違いを理解する必要がある。

‘ 【アンチパターン】ループ内でCurrentDbを直接叩き続ける愚行
Sub BadPattern_CurrentDbLoop()
Dim i As Long
For i = 1 to 100000
‘ 毎回CurrentDbを呼ぶことで、内部でメモリ割り当てと解放が爆発的に発生する
CurrentDb.Execute “INSERT INTO LogTable (LogMessage) VALUES (‘Test’)”, dbFailOnError
Next i
End Sub

このコードを実行すると、Accessの内部ヒープ領域が急速に断片化し、ガベージコレクションが追いつかなくなる。最悪の場合、エラー 3043（ディスク I/O エラーまたはメモリ不足）を引き起こしてプロセスがクラッシュする。

—

3. 実践：メモリリークを防ぐ「極限の最適化」設計パターン

大規模データ処理やバッチ処理を書く場合、プログラマが遵守すべき鉄則はただ一つ。
「データベースオブジェクトは変数に一度だけキャッシュし、処理後は明示的に破棄（Nothing代入）する」 これに尽きる。

以下に、実務の現場で即座に採用すべき堅牢なコードパターンを示す。

‘ ==============================================================================
‘ 模範解答：CurrentDbを変数にキャッシュし、確実にメモリを解放するバッチ処理
‘ ==============================================================================
Sub Optimized_DatabaseProcessing()
Dim ws As DAO.Workspace
Dim db As DAO.Database
Dim rs As DAO.Recordset
Dim qdf As DAO.QueryDef

‘ 1. 明示的なワークスペースの取得（複数トランザクション制御の基礎）
Set ws = DBEngine.Workspaces(0)

‘ 2. CurrentDbを変数に一度だけ格納（これ以降、ループ内ではCurrentDbを叩かない）
Set db = CurrentDb()

‘ トランザクションの開始（パフォーマンスと整合性の両立）
ws.BeginTrans

On Error GoTo ErrorHandler

‘ パラメータクエリの事前コンパイル（Jet/ACEエンジンへの負荷軽減）
Set qdf = db.CreateQueryDef(“”, “UPDATE TargetTable SET ProcessedFlag = -1 WHERE ID = [pID]”)

‘ レコードセットのオープン（ForwardOnlyでメモリ消費を極限まで抑制）
Set rs = db.OpenRecordset(“SELECT ID FROM TargetTable WHERE ProcessedFlag = 0”, dbOpenSnapshot, dbForwardOnly)

Do Until rs.EOF
‘ 処理ロジック（例としてのパラメータバインド）
qdf.Parameters(“pID”).Value = rs!ID
qdf.Execute dbFailOnError

rs.MoveNext
Loop

‘ コミット
ws.CommitTrans

‘ — 正常終了時のリソース解放 —
CleanUp rs, qdf, db
Exit Sub

ErrorHandler:
‘ 異常終了時はロールバック
ws.Rollback
MsgBox “致命的なエラーが発生しました: ” & Err.Description, vbCritical

‘ — 異常終了時のリソース解放 —
CleanUp rs, qdf, db
End Sub

‘ ——————————————————————————
‘ 共通クリーンアッププロシージャ（オブジェクトのライフサイクルを完全に掌握する）
‘ ——————————————————————————
Private Sub CleanUp(ByRef rs As DAO.Recordset, ByRef qdf As DAO.QueryDef, ByRef db As DAO.Database)
‘ オブジェクトの存在確認と明示的な破棄
If Not rs Is Nothing Then
rs.Close
Set rs = Nothing
End If

If Not qdf Is Nothing Then
‘ テンポラリクエリの場合は自動破棄されるが、明示的に参照を切る
Set qdf = Nothing
End If

If Not db Is Nothing Then
db.Close
Set db = Nothing
End If

‘ VBAのガベージコレクションを促すための強制開放（必要に応じて）
DoEvents
End Sub

コードの急所解説

1. `CurrentDb` の単一キャプチャ: ループの外側で `Set db = CurrentDb()` を実行することにより、ループ内のオーバーヘッドをゼロに近づけている。
2. `dbForwardOnly` と `dbOpenSnapshot`: 巨大なデータセットを扱う際、デフォルトのダイナセット（`dbOpenDynaset`）を使用すると、Accessは変更検知のための膨大なロック情報をメモリ上に保持する。読み取り専用のバッチであれば、前方スクロール専用のSNAPSHOTを使うべきである。
3. 明示的な `Nothing` 代入: VBAの参照カウンタ方式において、ローカル変数はプロシージャ終了時に解放されるが、DAOやCOMオブジェクトは即座にメモリから消えないケースがある。`Set xxx = Nothing` を明示的に記述することで、メモリリークを物理的に遮断する。

—

4. チーフアーキテクトからの提言：レガシー環境における極限の知見

Access VBAは、マネージドコード（C#等）のような高度なGC（ガベージコレクション）を持たない。したがって、開発者自身が「OSリソースの所有権」を完全にコントロールしなければならない。

特に、次のような環境では今回の知見が生命線となる。

• Windows Server上での無人バッチ実行（タスクスケジューラ連携）: 画面描画（UI）が存在しない環境では、`CurrentDb` の内部キャッシュ機構が誤作動を起こしたり、メモリが開放されずに数日でサーバがフリーズする現象が多発する。この環境では `DBEngine(0)(0)` を適切に活用し、かつ処理ごとのインスタンス破棄を徹底することが求められる。
• 外部API連携との複合処理: VBAからHTTPリクエスト（WinINoやXMLHTTP）を飛ばしつつ、ローカルのAccessへ高速にバルクインサートを行うようなシステムでは、データベース接続がリークしていると、ネットワークの遅延と相まって瞬く間にリソースが枯渇する。

「動けばいい」というアマチュアのコードから脱却し、ハードウェアの限界を見据えたメモリ管理を行うこと。それこそが、レガシーの呪縛を断ち切り、10年耐えうる堅牢なシステムを構築唯一の道である。