エンジンを掌握せよ：DAO vs ADO トランザクション性能の深淵と、リンクテーブルにおける真実
「とりあえず動く」コードを書くのは、誰にでもできる。しかし、数百万件のデータを扱うエンタープライズ環境、あるいはネットワーク遅延が牙を剥く分散環境において、そのコードが「システムを停止させる引き金」になることを理解しているエンジニアは、驚くほど少ない。
Access VBAの世界において、DAO（Data Access Objects）とADO（ActiveX Data Objects）の選択は、単なるライブラリの好みではない。それは、ACE（Access Connectivity Engine）の内部アーキテクチャをどう利用するかという、設計思想の決断である。
本稿では、ローカルテーブルおよびリンクテーブルにおけるトランザクション処理のパフォーマンス差を、オブジェクトのライフサイクルとメモリ管理の観点から徹底的に解剖する。
1. アーキテクチャの断絶：なぜ速度に差が出るのか
まず、我々は「抽象化のコスト」を理解しなければならない。
DAO：ACEエンジンへの直通経路
DAOは、Accessの心臓部であるACEエンジン（旧Jetエンジン）のために設計されたネイティブなインターフェースである。DAOオブジェクトは、エンジンのデータ構造に極めて近いレイヤーで動作する。
ローカルテーブルに対するDAOの操作は、メモリ上のバッファとディスクI/Oを直接制御する感覚に近い。トランザクションの管理も、`Workspace`オブジェクトを通じてエンジンのログファイル（.ldb / .laccdb）と密接に同期される。
ADO：OLE DBという名の抽象化レイヤー
対してADOは、OLE DBという汎用的なデータアクセスプロバイダを介して動作する。ADOは「あらゆるデータベースに同じ書き方でアクセスできる」という強力なメリットを持つが、その代償として変換オーバーヘッドを支払っている。
DAOが「エンジンの言語」で話すのに対し、ADOは「通訳（プロバイダ）」を介して話す。この通訳のプロセスが、特に大量のレコードを更新するトランザクションにおいては、無視できない累積的な遅延を生む。
2. リンクテーブルという名の「遅延増幅器」
エンジニアを最も苦しめるのは、SQL Serverや別環境のAccessから参照している「リンクテーブル」だ。
リンクテーブルに対するトランザクションを考える際、以下のメカニズムを脳内に叩き込んでおく必要がある。
1. DAOの場合: リンクテーブルへの操作であっても、トランザクションの制御権はローカルのACEエンジンが握り続ける。ネットワーク越しに「ロック」の要求を投げ、データの整合性を保とうとするが、その制御ロジックはクライアント側（Access側）に重くのしかかる。
2. ADOの場合: プロバイダの設定（CursorLocationなど）によっては、トランザクションの挙動がサーバーサイドへ委ねられる可能性がある。しかし、Accessからリンクテーブル越しにADOを使う場合、多くはクライアントサイドカーソルが介在し、ネットワークの往復（Round-trip）回数が爆発的に増加する。
3. 実証実験：極限のパフォーマンス検証
以下のコードは、同一のデータ更新処理をDAOとADOで実行し、その差を計測するためのベンチマーク・フレームワークである。
実験設定
- 対象: 10,000件のレコードに対する一括更新（Update）
- 環境: ローカルテーブルおよびSQL Serverリンクテーブル
Option Explicit
' ---------------------------------------------------------------------------------------
' 伝説的アーキテクトによるパフォーマンス検証モジュール
' 注意: このコードは計測用である。本番環境での乱用は避け、アーキテクチャの理解に用いること。
' ---------------------------------------------------------------------------------------
Public Sub Benchmark_Transaction_Comparison()
Dim startTime As Double
Debug.Print "--- Starting Benchmark ---"
' 1. DAO Local Test
startTime = Timer
RunDAOTechnique "LocalTable", True
Debug.Print "DAO Local: " & Format(Timer - startTime, "0.000") & " sec"
' 2. ADO Local Test
startTime = Timer
RunADOTechnique "LocalTable", True
Debug.Print "ADO Local: " & Format(Timer - startTime, "0.000") & " sec"
' 3. DAO Linked Test (SQL Server Link想定)
' startTime = Timer
' RunDAOTechnique "LinkedTable", True
' Debug.Print "DAO Linked: " & Format(Timer - startTime, "0.000") & " sec"
' 4. ADO Linked Test
' startTime = Timer
' RunADOTechnique "LinkedTable", False
' Debug.Print "ADO Linked: " & Format(Timer - startTime, "0.000") & " sec"
Debug.Print "--- Benchmark Completed ---"
End Sub
''' <summary>
''' DAOによるトランザクション処理
''' </summary>
Private Sub RunDAOTechnique(tableName As String, isLocal As Boolean)
Dim db As DAO.Database
Dim ws As DAO.Workspace
Dim rs As DAO.Recordset
Dim i As Long
On Error GoTo ErrorHandler
Set ws = DBEngine.Workspaces(0)
Set db = CurrentDb
' トランザクション開始
ws.BeginTrans
Set rs = db.OpenRecordset(tableName, dbOpenDynaset)
' 大量更新シミュレーション
For i = 1 To 10000
If Not rs.EOF Then
rs.Edit
rs.Fields("UpdateField").Value = i
rs.Update
rs.MoveNext
End If
Next i
' コミット
ws.CommitTrans
CleanUp:
' オブジェクトの明示的解放は、メモリリークとロック残留を防ぐための鉄則である
If Not rs Is Nothing Then
rs.Close
Set rs = Nothing
End If
If Not db Is Nothing Then Set db = Nothing
Exit Sub
ErrorHandler:
ws.Rollback
Debug.Print "DAO Error: " & Err.Description
Resume CleanUp
End Sub
''' <summary>
''' ADOによるトランザクション処理
''' </summary>
Private Sub RunADOTechnique(tableName As String, isLocal As Boolean)
Dim conn As ADODB.Connection
Dim rs As ADODB.Recordset
Dim i As Long
On Error GoTo ErrorHandler
' Access内部のエンジンに接続
Set conn = CurrentProject.Connection
' トランザクション開始
conn.BeginTrans
' カーソル位置の設定がパフォーマンスを左右する
' adUseClient はネットワーク越しでは致命的な遅延を招く
conn.CursorLocation = adUseServer
Set rs = conn.Execute("SELECT * FROM " & tableName)
For i = 1 To 10000
If Not rs.EOF Then
rs.Edit
rs.Fields("UpdateField").Value = i
rs.Update
rs.MoveNext
End If
Next i
conn.CommitTrans
CleanUp:
If Not rs Is Nothing Then
If rs.State = adStateOpen Then rs.Close
Set rs = Nothing
End If
If Not conn Is Nothing Then Set conn = Nothing
Exit Sub
ErrorHandler:
If Not conn Is Nothing Then conn.Rollback
Debug.Print "ADO Error: " & Err.Description
Resume CleanUp
End Sub4. 導き出される最適解：エンジニアが取るべき戦略
検証の結果、以下の結論が導き出される。これを選択基準の「黄金律」とせよ。
ケースA：ローカルのAccessファイル（.accdb）を操作する場合
【最適解：DAO】
迷う必要はない。DAOを選択せよ。ACEエンジンに対するオーバーヘッドが最小限であり、トランザクションのログ書き込み効率も極めて高い。ADOを使用する理由は、他のデータソース（SQL Server等）とのコード共通化を狙う場合を除き、存在しない。
ケースB：リンクテーブル（SQL Server等）を操作する場合
【最適解：条件付きでADO（またはPass-through SQL）】
ここが最も巧妙な判断を要する。
1. DAO + リンクテーブル:
大量の更新を行う場合、DAOは「クライアント側で一括してトランザクションを管理しようとする」ため、ネットワークの往復回数が爆発し、最悪の場合、ネットワークの瞬断でトランザクションが不整合を起こすリスクがある。
2. ADO + リンクテーブル:
`CursorLocation = adUseServer` を適切に設定し、可能であればADOの `Command` オブジェクトを用いた Pass-through SQL（パススルー・クエリ） を実行せよ。これにより、トランザクションの制御権を完全にサーバーサイドへ委譲できる。
究極の知見：メモリとオブジェクトのライフサイクル
シニアエンジニアとして忘れてはならないのは、`Set obj = Nothing` の重要性だ。
VBAのガベージコレクションは、C#やJavaのように洗練されてはいない。特にループ内で `Recordset` を生成する場合、明示的に `Close` および `Set Nothing` を行わなければ、メモリ上のヒープ領域を食いつぶし、さらには「ファイルが別のプロセスによって使用されています」という、忌々しいエラーを招くことになる。
結論
- ローカル操作は、DAOの速度を信じろ。
- サーバー操作は、ADO（Pass-through）で権限を委譲せよ。
- オブジェクトの解放は、生存本能として組み込め。
アーキテクチャを理解することは、コードを書くことではなく、データの流れを制御することである。この知見を、君のシステム設計の武器として刻んでほしい。
