Access VBAの深淵：CurrentDbの「乱用」が招くアーキテクチャの崩壊
Access VBAでコードを書き始めた者が最初に覚えるのが `CurrentDb` だ。しかし、真に拡張性のあるシステムを構築するエンジニアにとって、それは「安易に触れてはならない毒」にもなり得る。
今回は、ループ処理や大規模なバッチ処理において、なぜ `CurrentDb` を繰り返し呼び出すことが致命的なパフォーマンス低下を招くのか、そしてプロフェッショナルがDAOオブジェクトをどう「支配」すべきかを解説する。
—
1. なぜ `CurrentDb` の連続呼び出しは「罪」なのか
多くの初学者が陥る罠がある。
‘ 悪い例：ループのたびにCurrentDbを呼び出す
Dim i As Long
For i = 1 To 10000
CurrentDb.Execute “INSERT INTO LogTable (Msg) VALUES (‘Log ” & i & “‘)”, dbFailOnError
Next i
このコードが抱える問題は、単なる「遅さ」ではない。`CurrentDb` を呼び出すたびに、Accessは内部的に現在のデータベースへの新しい参照（DAO.Databaseオブジェクト）を再構築している。
- コンテキストの再生成: 毎回、データベースエンジンへのセッションやロック管理のコンテキストが再構築される。
- メモリのフラグメンテーション: 不要なオブジェクトが生成・破棄され続けることで、GC（ガベージコレクション）に余計な負荷がかかる。
- APIの隠蔽: 背後では `Application.CurrentDb` メソッドが走っており、これは単なるプロパティ参照ではなく、複雑な内部処理を伴う関数呼び出しである。
レガシーなシステム環境であればあるほど、このオーバーヘッドはボディーブローのように積み重なり、数分で終わるはずの処理を数時間に引き延ばす。
—
2. DAOオブジェクトのキャッシュ：エンジニアの所作
プロフェッショナルは、資源を一度確保し、使い回す。これが鉄則だ。`Database` オブジェクトを明示的に変数に格納し、ライフサイクルを管理する。
‘ 良い例：オブジェクトをキャッシュし、リソースを掌握する
Sub ProcessLogOptimized()
Dim db As DAO.Database
Dim i As Long
‘ オブジェクトを一度だけロードする
Set db = CurrentDb
‘ 処理の開始（トランザクションを併用するとさらに高速化する）
db.Execute “BEGIN TRANSACTION”, dbSQLPassThrough ‘ 必要に応じてトランザクション制御
For i = 1 To 10000
‘ キャッシュされたdbオブジェクトを使用する
db.Execute “INSERT INTO LogTable (Msg) VALUES (‘Log ” & i & “‘)”, dbFailOnError
Next i
db.Execute “COMMIT TRANSACTION”, dbSQLPassThrough
‘ 明示的な解放
Set db = Nothing
End Sub
この書き方であれば、メモリ上の単一の参照先を指し続けるため、オブジェクト生成コストはゼロになる。
—
3. 極限の最適化：メモリとAPIの観点から
さらに踏み込もう。大規模なデータ連携システムを構築する場合、単に `CurrentDb` をキャッシュするだけでは不十分なケースがある。
1. 明示的な解放（Nothing）の哲学
VBAにおいて `Nothing` を設定することは、単なる気休めではない。循環参照の防止、およびメモリを解放する「意思表示」だ。特にCOMオブジェクトを扱う際、明示的な解放を怠ることはリークへの近道である。
2. Windows APIとの共存
もしあなたが、VBAから `Kernel32.dll` 等のAPIを叩いてメモリ管理やファイル制御を行っているなら、`CurrentDb` のようなAccess固有のオブジェクト管理とAPIの呼び出し順序には細心の注意が必要だ。API側でメモリを確保した後にAccess側で重いクエリを走らせると、メモリ空間が圧迫され、API側で予期せぬ例外が発生することがある。
3. DAO vs ADODB
現代のAccess開発において、純粋なAccess内データ操作であればDAO一択だ。ADODBはSQL Server等の外部ソースと接続するためのものであり、DAOの方がJet/ACEエンジンとの親和性が圧倒的に高い。不必要にADODBに逃げるのは、アーキテクチャの妥協でしかない。
—
結論：伝説的エンジニアへの道
`CurrentDb` をキャッシュする。これ自体は入門書に書かれているような初歩的なテクニックかもしれない。しかし、「なぜそうするのか」をメモリレベル、コンテキストレベルで理解しているかが、ただの作業者と、システムを掌の上で転がすチーフアーキテクトの分かれ道だ。
コードは「動けばいい」のではない。「資源をどう制御するか」という設計思想が、その一行一行に宿っていなければならない。
次にあなたが `CurrentDb` と書こうとしたとき、その背後で蠢くオブジェクトの鼓動を感じ取ってほしい。それが、卓越への第一歩だ。
