データの二重奏を支配する：DAOとADOの共存におけるアーキテクチャ設計と命名の規律
Access VBAの世界において、エンジニアが直面するもっとも「低俗で、かつ致命的な」問題の一つが、DAO (Data Access Objects) と ADO (ActiveX Data Objects) の名前空間の衝突である。
ローカルのACEエンジン（旧Jet）を極限まで叩き起こすためのDAOと、SQL ServerやOracleといった外部の堅牢なデータソースへ接続するためのADO。これらは、Accessというエコシステムにおいて、車の両輪である。しかし、両者を同一プロジェクト内で不用意に混在させた瞬間、コードは「Ambiguous name detected（名前が曖昧です）」という、設計の甘さを露呈するエラーを吐き出し、開発者のリズムを破壊する。
本稿では、単なる「使い分け」の解説ではない。大規模・長期運用されるレガシーシステムにおいて、メモリリークを排し、名前空間の衝突を物理的に不可能にするための「極限の設計規律」を伝授する。
1. 衝突の真実：なぜ「Recordset」は二つ存在するのか
VBAの参照設定において、`Microsoft Office 16.0 Access database engine Object Library` (DAO) と `Microsoft ActiveX Data Objects x.x Library` (ADO) を共に有効にした場合、コンパイラは混乱に陥る。
なぜなら、両ライブラリは共に `Recordset`、`Connection`、`Database` といった、データ操作における核心的なオブジェクト名を定義しているからだ。
初心者はここで、`Dim rs As Recordset` と記述し、コンパイラがどちらを優先するかという「運」に身を委ねる。これはアーキテクチャの放棄である。シニアエンジニアは、コンパイラに推測させるなどという不確定要素を、コードの生命線であるトランザクション処理に持ち込まない。
2. 命名規律（Naming Convention）：プレフィックスによる階層化
衝突を回避する唯一の確実な方法は、「完全修飾名（Fully Qualified Names）」の使用と、それに準じた「変数プレフィックス」の徹底である。
私は、以下の命名規則をプロジェクトの標準として規定することを推奨する。これは、コードの可読性を高めるだけでなく、デバッグ時に「今、どのレイヤーのオブジェクトを操作しているのか」を直感的に理解させるための防波堤となる。
DAO オブジェクトのプレフィックス
ローカルのACEエンジンを操作する際に使用する。
- `dbs` : `DAO.Database`
- `drs` : `DAO.Recordset`
- `dtf` : `DAO.TableDef`
- `dq` : `DAO.QueryDef`
ADO オブジェクトのプレフィックス
外部サーバー（SQL Server等）への通信に使用する。
- `acs` : `ADODB.Connection`
- `ars` : `ADODB.Recordset`
- `acmd` : `ADODB.Command`
3. 実装の極致：完全修飾と明示的解放のコード例
以下に、ローカルのDAOテーブルからマスター情報を読み込み、ADOを用いて外部SQL Serverのトランザクションデータと照合する、実戦的なモジュール構成を示す。
ここでは、「オブジェクトのライフサイクル管理」に焦点を当てる。VBAにおけるオブジェクトの解放漏れは、ファイルロックの継続や、メモリ領域の断片化を招き、最終的にAccessの強制終了を引き起こす。
Option Compare Database
Option Explicit
' ===============================================================================
' Module: modDataIntegrator
' Description: DAO(Local)とADO(Remote)を高度に制御するデータ統合モジュール
' Author: Chief Architect
' ===============================================================================
Public Sub SyncLocalAndRemoteData()
' --- 宣言部：完全修飾名による名前空間の完全分離 ---
Dim dbsLocal As DAO.Database
Dim drsLocal As DAO.Recordset
Dim acsRemote As ADODB.Connection
Dim arsRemote As ADODB.Recordset
Dim strConn As String
Dim strSQL As String
' エラーハンドリングの初期化
On Error GoTo Err_Handler
' 1. DAOによるローカル操作の開始
Set dbsLocal = CurrentDb
Set drsLocal = dbsLocal.OpenRecordset("tbl_LocalMaster", dbOpenSnapshot)
' 2. ADOによるリモート接続の確立
' ※接続文字列は環境変数や暗号化された設定テーブルから取得するのが定石
strConn = "Provider=SQLNCLI11;Data Source=SERVER_NAME;Initial Catalog=DB_NAME;Integrated Security=SSPI;"
Set acsRemote = New ADODB.Connection
acsRemote.ConnectionString = strConn
acsRemote.Open
' 3. データの照合プロセス（極限のロジック）
Do Until drsLocal.EOF
strSQL = "SELECT Status FROM RemoteTransactionTable WHERE MasterID = " & drsLocal!MasterID
' ADO Recordsetの生成（使い捨ての設計）
Set arsRemote = acsRemote.Execute(strSQL)
If Not arsRemote.EOF Then
' ここにビジネスロジックを記述
' 例: ローカルとリモートの状態が異なる場合に更新処理を行う
Debug.Print "Syncing ID: " & drsLocal!MasterID
End If
' --- 重要：ADO Recordsetはループ内で即座に解放する ---
' これを行わないと、ループごとにメモリとカーソルが蓄積される
Set arsRemote = Nothing
drsLocal.MoveNext
Loop
Exit_Handler:
' --- クリーンアップ・フェーズ：オブジェクトのライフサイクルを完結させる ---
' 順序が重要である。子オブジェクトから先に破棄せよ。
On Error Resume Next
If Not arsRemote Is Nothing Then Set arsRemote = Nothing
If Not acsRemote Is Nothing Then
If acsRemote.State = adStateOpen Then acsRemote.Close
Set acsRemote = Nothing
End If
If Not drsLocal Is Nothing Then Set drsLocal = Nothing
If Not dbsLocal Is Nothing Then Set dbsLocal = Nothing
Exit Sub
Err_Handler:
' Windows API等を用いた高度なエラーログ記録をここに実装
MsgBox "Critical Error in SyncProcess: " & Err.Description, vbCritical, "System Failure"
Resume Exit_Handler
End Sub4. アーキテクトの視点：トランザクションの境界線
DAOとADOを共存させる際、もっとも技術的難易度が高いのは「トランザクションの整合性」である。
DAOの `BeginTrans` は、ACEエンジン内のローカルなトランザクションを制御する。一方で、ADOの `BeginTrans` は、接続先のサーバー（SQL Server等）に対してトランザクションを開始する。
これらは決して同期しない。
もし、ローカルの更新（DAO）とリモートの更新（ADO）を一つの論理的な単位として扱いたい場合、以下の設計指針に従うこと。
1. 「Two-Phase Commit (2PC)」を安易に求めない: Access VBA単体で分散トランザクションを完璧に制御するのは、極めてリスクが高い。
2. 「事後補償（Compensating Transaction）」パターンの採用:
まずリモート（ADO）の更新を完了させ、それが成功したことを確認してから、ローカル（DAO）の更新を行う。もしローカルの更新に失敗した場合は、逆方向に「取り消し用のSQL」を発行する設計にする。
3. ステータス管理の徹底:
「処理中」「完了」「失敗」といった状態をローカルテーブルに刻み、システムがクラッシュしても再開（リカバリ）可能な「冪等性（Idempotency）」を持たせた設計を行う。
結論
DAOとADOの共存は、単なるライブラリの併用ではない。それは、「ローカルの迅速な操作」と「リモートの堅牢な通信」という、異なるパラダイムの衝突を管理する行為である。
完全修飾名による名前空間の隔離、プレフィックスによる命名の規律、そしてオブジェクトの確実な破棄。これら一つひとつの規律を疎かにする者は、いずれ巨大なレガシーシステムの荒波に飲み込まれ、デバッグ不能なメモリリークとデータ不整合の泥沼に沈むことになる。
技術の真髄は、コードの華やかさではなく、その裏側に潜む「不確実性の排除」にこそ宿るのだ。
