【上級】DAO.Recordsetの「BatchUpdate」を模倣する：トランザクション管理による一括更新の高速化
レガシーシステムの現場において、Access VBAは今なお企業の心臓部で稼働し続けている。数百万件に及ぶトランザクションデータ、複雑なマスター突合、そして非力なローカル環境。この過酷な条件下で、素朴な`CurrentDb.Execute`のループや、非効率なレコードセットの走査がいかにシステムを殺しているか。シニアエンジニアであれば身をもって知っているはずだ。
ADOのコンポーネントが持つような洗練されたバッチ更新メカニズムが、デフォルトのDAO Recordsetには備わっていない。しかし、Accessの底流にあるJET/ACEデータベースエンジンの挙動を完全に掌握し、トランザクションの境界を適切に制御すれば、DAOのポテンシャルを極限まで引き出し、疑似的な「BatchUpdate」を実装することは完全に可能だ。
今回は、数万件規模のレコード更新をミリ秒単位で完遂するための、トランザクション管理による一括更新の極意を解説する。
—
1. なぜ「1件ずつの更新」はシステムを死に至らしめるのか
Access VBAでのデータ操作において、初心者が陥る最大の罠が「レコードセットをループさせながらの1件ずつの`Update`」である。
‘ 【アンチパターン】絶対にやってはならない実装
Dim rs As DAO.Recordset
Set rs = CurrentDb.OpenRecordset(“T_HeavyData”, dbOpenDynaset)
Do Until rs.EOF
rs.Edit
rs!Status = “Processed”
rs.Update ‘ ← ここで毎回ディスクへのI/Oとトランザクションログの書き込みが発生する
rs.MoveNext
Loop
rs.Close
このコードの何が問題か。Access（ACEエンジン）は、`.Update`メソッドが実行されるたびに、暗黙的にトランザクションの開始とコミット、そしてインデックスの再構築やダーティページのディスクフラッシュを試みる。1万件のレコードがあれば、ディスクとの往復が1万回発生する。これではネットワークやストレージの帯域がどれだけ広くても、OSのI/O待ちでCPUが完全に遊んでしまう。
真のエンジニアが目指すべきは、「トランザクションのスコープを最小限のオーバーヘッドで引き伸ばし、書き込みのトランザクションログへのフラッシュを極限までバッチ化する」ことだ。
—
2. DAOトランザクションとワークスペースの極意
Accessでトランザクションを制御する場合、`CurrentDb.Execute`に`dbFailOnError`を付与する方法もあるが、複雑な条件分岐やインメモリでのデータ加工を伴う場合、`DAO.Recordset`の機動力が不可欠となる。
ここで重要になるのが、`Workspace`オブジェクトの明示的な利用である。デフォルトの`DBEngine.Workspaces(0)`に対してトランザクションを張ることで、そのセッション内のすべてのデータ操作を単一の不可分な（Atomicity）操作に束ねることができる。
トランザクション制御の基本原則
1. トランザクションのスコープは最短に、しかし処理の塊は最大に：メモリ上で処理できる限界（通常数千〜数万件単位）までデータを抱え、一気にコミットする。
2. エラーハンドリングの徹底：途中で予期せぬエラー（ロック競合や型不一致）が発生した場合は、必ず`Rollback`を行い、データベースの整合性を担保する。
3. オブジェクトの即時解放：メモリリークを防ぐため、参照したRecordsetやWorkspaceは確実に破棄する。
—
3. 実装コード：DAOによる疑似バッチ更新エンジン
以下に、実業務の現場でそのまま耐えうる、堅牢かつ圧倒的な高速性を誇る一括更新プロシージャの全貌を示す。
Option Compare Database
Option Explicit
‘ ==============================================================================
‘ 担当：チーフアーキテクト
‘ 概要：大量データに対するDAOトランザクションを活用した高速一括更新処理
‘ 特徴：暗黙のI/Oを排除し、トランザクション境界を制御することで劇的な速度向上を実現
‘ ==============================================================================
Public Sub ExecuteBatchUpdateSimulation()
Dim ws As DAO.Workspace
Dim db As DAO.Database
Dim rs As DAO.Recordset
Dim lngCounter As Long
Dim dblStartTime As Double
dblStartTime = Timer
‘ 1. ワークスペースとデータベースの参照を取得
‘ ※デフォルトワークスペースを使用
Set ws = DBEngine.Workspaces(0)
Set db = CurrentDb()
On Error GoTo ErrorHandler
‘ 2. トランザクションの明示的開始
ws.BeginTrans
‘ 3. レコードセットのオープン（パフォーマンス重視のためダイナセット型を使用）
‘ 該当するレコードのみを抽出し、ロック競合を最小化
Set rs = db.OpenRecordset(“SELECT ID, Status, ProcessDate FROM T_TargetData WHERE Status = ‘Pending'”, dbOpenDynaset, dbDenyWrite)
lngCounter = 0
Do Until rs.EOF
‘ 編集モードへ移行
rs.Edit
‘ データの加工（メモリ上の操作）
rs!Status = “Completed”
rs!ProcessDate = Now()
‘ 更新の確定（この時点ではトランザクション内であり、物理ディスクへの確定はコミット時に一括で行われる）
rs.Update
lngCounter = lngCounter + 1
‘ メモリ肥大化とロックの長期間保持を防ぐため、一定件数ごとにコミット＆トランザクション再開する設計も有効
‘ （今回は数万件程度であれば一括コミットで最速を狙う）
rs.MoveNext
Loop
‘ 4. トランザクションのコミット（ここで初めて一括書き込みが実行される）
ws.CommitTrans
MsgBox “一括更新が完了しました。” & vbCrLf & _
“処理件数: ” & lngCounter & ” 件” & vbCrLf & _
“処理時間: ” & Format(Timer – dblStartTime, “0.00”) & ” 秒”, _
vbInformation, “パフォーマンスレポート”
CleanUp:
‘ 5. オブジェクトの厳密な解放
If Not rs Is Nothing Then
rs.Close
Set rs = Nothing
End If
Set db = Nothing
Set ws = Nothing
Exit Sub
ErrorHandler:
‘ 異常系：ロールバックによるデータの整合性維持
ws.Rollback
MsgBox “致命的なエラーが発生しました。変更はロールバックされました。” & vbCrLf & _
“Error ” & Err.Number & “: ” & Err.Description, _
vbCritical, “トランザクションエラー”
Resume CleanUp
End Sub
—
4. チーフアーキテクトが教える「さらなる極限チューニング」
上記のコードだけでも、素朴なループ処理と比較して数倍から数十倍の速度差が出はずだ。しかし、真の極限を追求するならば、以下のアーキテクチャ的配慮も忘れてはならない。
① `dbDenyWrite` やロックモードの最適化
多重起動や他ユーザーによる干渉が想定される環境では、`OpenRecordset`の引数に適切なロックオプション（`dbOptimistic` や `dbPessimistic`）を指定する。特にバッチ処理の性格上、排他制御が必要な場合は、他のプロシージャからの介入をシャットアウトする設計が求められる。
② 大規模データにおける「チャンク（分割）コミット」の採用
数百万件規模のデータを1つのトランザクションで処理しようとすると、Accessの内部バッファ（ロック情報等）が枯渇し、エラー（「リソースが不足しています」など）を引き起こす。
このようなケースでは、「5,000件ごとに `CommitTrans` と `BeginTrans` を挟む」というチャンク処理を実装すべきである。トランザクションの堅牢性を一部妥協する代わりに、メモリ破綻を防ぐというシニアならではのトレードオフの判断だ。
③ 画面描画とイベントの完全凍結
もしこの処理をフォーム上のボタンからキックする場合、処理の最初と最後に以下のコードを挟むことを忘れるな。
Application.Echo False ‘ 画面描画の停止
DoCmd.SetWarnings False ‘ 警告メッセージの停止
‘ — 処理本体 —
DoCmd.SetWarnings True
Application.Echo True
UIの再描画コストは、バックグラウンドのデータ処理において想像以上の悪影響を及ぼす。これを排除するだけで、数秒単位の短縮がもたらされる。
—
総括
Access VBAは「おもちゃの言語」ではない。その背後にあるJET/ACEエンジンの仕様を理解し、メモリとトランザクションのライフサイクルを完全に支配下に置いたとき、このレガシー環境はモンスター級のデータ処理マシンへと変貌する。
「動けばいい」というコードから脱却し、リソースの限界を見据えたアーキテクチャを構築すること。それこそが、現場を支えるシニアエンジニアの矜持である。
