データの整合性を死守せよ：DAO `dbFailOnError` がもたらすトランザクションの真髄
多くの開発者が、Access VBAを単なる「小規模なツールの作成手段」と侮っている。しかし、その認識こそが、大規模なレガシーシステムにおいてデータ破損という致命的な災厄を招く元凶である。
AccessのバックエンドがACE（Access Connectivity Engine）である以上、我々が扱うのは単なるファイル操作ではない。高度に最適化されたリレーショナル・データベース・エンジンとの対話である。その対話において、最も基本的かつ、最も軽視されている武器が、DAOの `Execute` メソッドにおける `dbFailOnError` オプションだ。
本稿では、単なるリファレンスの解説は排する。なぜこのオプションが、トランザクション処理における「最後の砦」となるのか。そのアーキテクチャ的背景と、プロフェッショナルが実践すべき実装パターンを詳解する。
1. DAOとADO：アーキテクチャの境界線を知る
まず、我々が立脚している戦場を整理しておこう。Access開発において、DAO（Data Access Objects）とADO（ActiveX Data Objects）の選択は、単なる好みの問題ではない。
- DAO (Data Access Objects):
ACEエンジンにネイティブに統合された、いわば「エンジン直結」のインターフェースである。Access固有の機能（リレーションシップ、インデックス、複雑なDAO型データ）を最も効率的に、かつ最小限のオーバーヘッドで操作できる。
- ADO (ActiveX Data Objects):
OLE DBを介した、抽象化された汎用的なインターフェースである。SQL Serverなどの外部サーバーへの接続には適しているが、Access内部の操作においては、抽象化レイヤーによるメモリ消費と、エンジンの最適化を阻害するオーバーヘッドが無視できない。
我々がAccessの内部ロジックを構築する場合、「DAOを選択し、エンジンの力を限界まで引き出す」のが定石である。そして、そのDAOにおける更新処理の核となるのが `Execute` メソッドだ。
2. 「沈黙の失敗」という名の致命的なバグ
DAOの `Execute` メソッドを、以下のように記述している者が多すぎる。
' ―― 危険な実装例 ――
Dim strSQL As String
strSQL = "UPDATE T_Inventory SET Stock = Stock - 1 WHERE ItemID = 101"
db.Execute strSQL ' ← ここに致命的な欠陥があるこのコードには、恐ろしい罠が潜んでいる。
`Execute` メソッドは、デフォルトでは「実行時にエラーが発生しても、それを無視して次の行へ進む」という挙動を示す。
例えば、`ItemID = 101` のレコードが既に削除されていたり、制約違反（Check Constraintやリレーションシップによる拒否）が発生したりしても、VBAの実行フローは止まらない。プログラムは「成功した」かのように振る舞い、後続の処理（例えば、売上伝票の作成など）を継続してしまう。
結果として、「在庫は減っていないのに、売上だけが計上される」という、データベースの整合性が崩壊した状態が完成する。これは、システムに対する信頼性を根底から破壊する行為だ。
3. `dbFailOnError`：例外を強制する防波堤
この「沈黙の失敗」を打破するのが、`dbFailOnError` オプションである。
' ―― 正しき実装の第一歩 ――
db.Execute strSQL, dbFailOnErrorこのオプションを指定した瞬間、`Execute` メソッドの挙動は劇的に変わる。更新処理がエンジンの制約に抵触した場合、DAOは即座にランタイムエラーをスローする。
これにより、VBAの標準的なエラーハンドリング（`On Error GoTo`）が作動し、処理を中断させることができる。つまり、「失敗したなら、それ以上進ませない」という、システムとしての誠実な挙動を強制できるのだ。
4. 極限の実装：トランザクションとの完全なる同期
`dbFailOnError` の真価は、単体で使用した時ではなく、`BeginTrans` / `CommitTrans` / `Rollback` によるトランザクション制御と組み合わされた時に発揮される。
複数のテーブルにまたがる更新処理において、一つでも失敗したら全てを無に帰す。この「All or Nothing」の原則を実装するための、プロフェッショナル向けのテンプレートを以下に示す。
''
' @description 複数の在庫更新と売上登録をアトミックに実行する
' @return Boolean 成功時はTrue、失敗時はFalse
''
Public Function ExecuteComplexTransaction(ByVal targetItemID As Long, ByVal qty As Integer) As Boolean
Dim db As DAO.Database
Dim strSQLUpdateStock As String
Dim strSQLInsertSales As String
' 初期化
ExecuteComplexTransaction = False
Set db = CurrentDb
' SQL文の構築
strSQLUpdateStock = "UPDATE T_Inventory SET Stock = Stock - " & qty & _
" WHERE ItemID = " & targetItemID & " AND Stock >= " & qty
strSQLInsertSales = "INSERT INTO T_Sales (ItemID, Qty, SaleDate) " & _
" VALUES (" & targetItemID & ", " & qty & ", #" & Format(Date, "yyyy/mm/dd") & "#)"
On Error GoTo ErrorHandler
' --- トランザクション開始 ---
DBEngine.BeginTrans
Debug.Print "Transaction Started."
' 1. 在庫更新 (dbFailOnError により、条件不一致や制約違反でエラーを強制)
' 注意: Update文のWHERE句で在庫不足を防いでいるが、
' dbFailOnError がなければ、更新件数0でもエラーにならない。
' 厳密には、RecordsAffectedを確認するか、Trigger/Constraintを活用すべきだ。
db.Execute strSQLUpdateStock, dbFailOnError
' 更新件数が0の場合（在庫不足など）は、自らエラーを発生させてロールバックへ導く
If db.RecordsAffected = 0 Then
Err.Raise vbObjectError + 513, "ExecuteComplexTransaction", "在庫不足またはアイテム不在のため更新不能。"
End If
' 2. 売上登録
db.Execute strSQLInsertSales, dbFailOnError
' --- 全ての処理が成功した場合のみコミット ---
DBEngine.CommitTrans
Debug.Print "Transaction Committed Successfully."
ExecuteComplexTransaction = True
ExitProcedure:
' オブジェクトの明示的な解放 (メモリリーク防止)
' 大規模なループや長時間稼働するプロセスでは、これが必須である
Set db = Nothing
Exit Function
ErrorHandler:
' --- エラー発生時は即座にロールバック ---
Debug.Print "Error Occurred: " & Err.Description
DBEngine.Rollback
Debug.Print "Transaction Rolled Back."
' エラー情報をログに記録するなどの処理をここに記述
Resume ExitProcedure
End Functionアーキテクトの視点：なぜ `RecordsAffected` のチェックが必要なのか？
ここで、一歩踏み込んだ知見を共有しよう。
`dbFailOnError` は「SQLの構文エラー」や「制約違反（キー重複など）」には反応するが、「WHERE句の条件に一致するレコードが0件だった」という事態には反応しない。
例えば、在庫が足りずに `WHERE Stock >= qty` が成立しなかった場合、SQLとしては「正常に0件を更新した」とみなされ、エラーは発生しない。これを防ぐには、上記コードのように `db.RecordsAffected` を検証し、必要に応じて `Err.Raise` で自ら例外を生成する。これが、プロの書く堅牢なコードである。
5. メモリ管理とレガシー環境への配慮
長年、レガシーなシステムを保守してきた者として、最後に一つ釘を刺しておきたい。
VBAは、現代的な言語のようにガベージコレクション（GC）が完璧に機能するわけではない。特に、DAOオブジェクトや複雑なレコードセットを扱う場合、`Set obj = Nothing` による明示的な解放を怠ると、メモリリークを引き起こし、最終的には `Out of Memory` エラーを招く。
特に、トランザクション内でエラーが発生した際、`ErrorHandler` 内で適切に `Rollback` を行い、かつ `ExitProcedure` を通じてオブジェクトを解放する構造を徹底すること。これが、システムを数年、あるいは十数年と安定稼働させるための、エンジニアとしての誠実さである。
結論
`dbFailOnError` は、単なるオプションではない。それは、データの整合性を守るための「意思」である。
1. DAOを使用し、エンジンの力を最大限に引き出す。
2. `Execute` には必ず `dbFailOnError` を付与する。
3. トランザクション (`BeginTrans` / `CommitTrans`) と組み合わせる。
4. `RecordsAffected` を監視し、ビジネスロジック上の失敗を例外へ昇華させる。
この原則を遵守することで、君の構築するシステムは、いかなる過酷な環境下でも揺るぎない信頼性を獲得するだろう。
