【極限の知見】DAOトランザクションの深淵：不測の事態からデータ整合性を死守するアーキテクチャ
現場において、コードが「正しく動くこと」など、エンジニアにとっては最低条件に過ぎない。真のプロフェッショナルがその腕を試されるのは、システムが「予期せぬ事態」に直面したとき、すなわちデータが壊れようとする境界線においてである。
Access VBAを用いた業務システム開発において、最も致命的な失敗は、不完全なデータがデータベースに書き込まれることだ。複数のテーブルを跨ぐ更新処理の最中に、ネットワークの瞬断、あるいはユーザーによる強制終了が発生したとする。このとき、あなたのコードは「原子性（Atomicity）」を担保できているか？
本稿では、DAO（Data Access Objects）を用いたトランザクション処理における、極限まで堅牢なエラーハンドリングの設計思想と、メモリ・リソース管理の真髄を解説する。
1. DAOとADO：アーキテクチャの決定的な差異
まず、我々がなぜここでDAOを選択すべきかを理解せねばならない。
ADO（ActiveX Data Objects）は、汎用的なデータアクセスを目的とした抽象化レイヤーである。SQL ServerやOracleといった外部リレーショナルデータベースとの連携には極めて強力だが、Access（ACE/Jetエンジン）の内部構造に対しては、過剰なオーバーヘッドを伴う場合がある。
対してDAOは、Accessエンジンと密結合したネイティブなインターフェースである。
DAOのトランザクションは、`Workspace`オブジェクトを通じて制御される。これはエンジンレベルでのロック制御に直結しており、Access特有のマルチユーザー環境における整合性を維持するためには、DAOを用いた制御が最も低レイヤーで確実な手段となる。
2. 「ゾンビ・トランザクション」という悪夢
トランザクション処理における最大の敵は、「エラーが発生したにもかかわらず、Rollbackが実行されずに処理が中断されること」である。
もし、`BeginTrans`を実行した後にエラーが発生し、適切な`Rollback`が行われないまま、オブジェクトがメモリ上に残存、あるいは不完全な状態で終了した場合、どうなるか。
1. ロックの残留: データベースファイル（.laccdb）にロックが残り続け、他のユーザーがテーブルにアクセスできなくなる。
2. データの不整合: 一部のテーブルは更新され、一部は更新されていないという、ビジネスロジック上、修復不可能な状態が生まれる。
3. メモリリーク: 参照が残ったままのRecordsetオブジェクトが、VBAのメモリ空間を汚染し、アプリケーション全体の不安定化を招く。
これらは、単なる「バグ」ではなく、システムの「死」を意味する。
3. 実装：堅牢なるエラーハンドリング・テンプレート
シニアエンジニアが書くべきコードは、常に「最悪のシナリオ」を想定して構造化されている。以下に、私が長年の経験から導き出した、実戦投入可能なトランザクション・テンプレートを示す。
''
' @description: 複数のテーブルを更新する、原子性を担保したトランザクション処理
' @returns: 成功時はTrue、失敗時はFalse
''
Public Function ExecuteCriticalTransaction() As Boolean
On Error GoTo Err_Handler
' --- 1. オブジェクトの宣言（スコープを最小限にする） ---
Dim ws As DAO.Workspace
Dim db As DAO.Database
Dim rs As DAO.Recordset
Dim isTransactionActive As Boolean
' 初期化
isTransactionActive = False
ExecuteCriticalTransaction = False
' --- 2. 環境のセットアップ ---
' Workspaceは、エンジンレベルのトランザクション管理を司る
Set ws = DBEngine(0)
Set db = CurrentDb
' --- 3. トランザクションの開始 ---
' ここでBeginTransを呼び出す。以降、Commitされるまで変更は確定されない
ws.BeginTrans
isTransactionActive = True
Debug.Print "Transaction Started..."
' --- 4. メインロジック（業務処理） ---
' 例：受注テーブルと在庫テーブルの同時更新
Set rs = db.OpenRecordset("T_Orders", dbOpenDynaset)
With rs
.AddNew
!OrderDate = Now()
!CustomerID = 101
!Amount = 5000
.Update
End With
' 別のテーブルへの操作（ここでエラーが発生する可能性を想定）
Set rs = db.OpenRecordset("T_Inventory", dbOpenDynaset)
With rs
.AddNew
!ItemID = 50
!StockQty = !StockQty - 1
.Update
End With
' --- 5. コミット（すべての処理が成功した場合のみ到達） ---
ws.CommitTrans
isTransactionActive = False
Debug.Print "Transaction Committed Successfully."
ExecuteCriticalTransaction = True
Clean_Up:
' --- 6. リソースの明示的解放（メモリ最適化） ---
' オブジェクトのライフサイクルを管理することは、レガシー環境の安定稼働に不可欠である
On Error Resume Next ' 解放時のエラーを無視
If Not rs Is Nothing Then
rs.Close
Set rs = Nothing
End If
If Not db Is Nothing Then
Set db = Nothing
End If
If Not ws Is Nothing Then
Set ws = Nothing
End If
Exit Function
Err_Handler:
' --- 7. エラーハンドリングとロールバック ---
Debug.Print "Error Detected: " & Err.Number & " - " & Err.Description
' トランザクションがアクティブな場合のみロールバックを実行
If isTransactionActive Then
Debug.Print "Rolling back transaction..."
ws.Rollback
isTransactionActive = False
End If
' エラー情報を記録し、後続の処理へ（必要に応じてRaise）
' Err.Raise Err.Number, "ExecuteCriticalTransaction", Err.Description
Resume Clean_Up
End Function4. アーキテクトの視点：メモリ管理とオブジェクトのライフサイクル
このコードにおいて、単なる「エラー処理」以上の意味を持つのが、`Clean_Up`セクションにおけるオブジェクトの明示的な解放である。
なぜ `Set obj = Nothing` が必要なのか？
VBAのガベージコレクション（自動メモリ管理）は、決して信頼に足るものではない。特に、ループ内や複雑な分岐を持つ関数内で、`Recordset`や`Database`オブジェクトを放置すれば、メモリリークが発生する。
また、DAOのオブジェクトは、解放の順序が重要である。
1. `Recordset` を閉じる
2. `Database` を閉じる
3. `Workspace` を解放する
この順序を逆にしたり、途中でプロセスが強制終了したりすると、エンジン側でロックが保持され続けるリスクが高まる。`On Error Resume Next` を用いた `Clean_Up` パターンは、エラー発生時であっても確実にリソースを回収するための「防波堤」である。
Windows APIとの境界線
高度なシステムでは、ファイルシステムのロック状態を監視するために Windows API (`GetFileInformationByHandle` 等) を呼び出すこともあるが、VBAの範囲内では、「オブジェクトのライフサイクルをコードで完全に支配すること」こそが、APIに頼らずともシステムの堅牢性を高める唯一の道である。
結論
トランザクション処理とは、単にデータを書き込む作業ではない。それは、「失敗したときに、いかにして『何も起きなかったこと』にできるか」という、引き算の設計思想である。
`BeginTrans`、`CommitTrans`、そして何より厳格な`Rollback`。これらを正しく組み合わせ、オブジェクトの解放を徹底すること。この規律こそが、長年稼働し続ける堅牢な業務システムを支える、エンジニアの魂である。
