Access VBAの深淵：DoCmd.RunCommandによる「強制保存」の真実と、その先にある設計思想
Access開発において、「データ整合性」という言葉を安易に使ってはならない。
多くの開発者は`DoCmd.RunCommand acCmdSaveRecord`を、単なる「保存ボタン」として捉えている。だが、私から見ればそれは、Accessのトランザクション制御における「ゲートキーパー」に他ならない。
今回は、このコマンドを単なる機能としてではなく、システム全体の堅牢性を担保するアーキテクチャの一部として再定義しよう。
—
なぜ「強制保存」が必要なのか：エンジニアが見落とすイベントの断絶
Accessのフォームには、独自の「ダーティ（Dirty）」状態が存在する。ユーザーがテキストボックスに値を入力した瞬間、Accessはバッファメモリ上でその値を保持するが、まだテーブルには反映されていない。
この状態でバリデーション（入力チェック）を行おうとすると、しばしば以下の罠に陥る。
1. 未コミットデータの参照: VBA側で`Me.Value`を参照しても、直前の入力が反映されていない（フォーカスが移っていないため）。
2. イベントの競合: `BeforeUpdate`イベントでバリデーションを行っても、Accessの内部的な保存プロセスが完了する前であれば、不正なデータがスルーされる可能性がある。
これらを解決するための唯一の解法が、`DoCmd.RunCommand acCmdSaveRecord`による強制コミットのトリガーである。
—
実践的実装：防御的プログラミングの極致
単にコマンドを叩くだけでは不十分だ。エラーハンドリングを包含し、メモリ消費を最適化した実装例を示す。
”’
”’
Private Sub Form_BeforeUpdate(Cancel As Integer)
On Error GoTo ErrorHandler
‘ 1. 現在のダーティ状態を確認
‘ 不要な書き込みを抑制し、メモリIOを最小化する
If Me.Dirty Then
‘ 2. 強制保存の実行
‘ この呼び出しにより、BeforeUpdateが再帰的に走らないよう注意が必要
DoCmd.RunCommand acCmdSaveRecord
End If
‘ ここでバリデーションロジックを実行
If Not ValidateBusinessLogic() Then
Cancel = True ‘ 更新を拒否し、フォーカスを保持
MsgBox “入力内容に不備があります。”, vbCritical
End If
Exit Sub
ErrorHandler:
‘ 予期せぬエラー発生時、トランザクションを確実にロールバックさせる
If Err.Number <> 0 Then
MsgBox “システムエラー: ” & Err.Description, vbCritical
Cancel = True
End If
End Sub
このコードの「極限」のポイント
- Dirtyの判定: `Me.Dirty`を確認することで、変更がない場合の不要なディスクIOを完全に排除している。
- ビジネスロジックの分離: バリデーションは関数化し、`Form_BeforeUpdate`自体を軽量に保つ。これは後の保守性において決定的な差となる。
- トランザクション管理: `Cancel = True`による更新拒否は、Accessの内部エンジンに対して「このレコードの状態は無効である」というシグナルを送る。これにより、半端なデータがテーブルに混入するのを防ぐ。
—
現場で遭遇する「レガシーの闇」とメモリ最適化
大規模なAccessシステムでは、`Application.CurrentDb`を安易に何度も呼び出してはならない。これは毎回新しいオブジェクトインスタンスを生成するコストを伴う。
特にAPI連携や大量データ処理を行う際は、CurrentDbのキャッシュ化が必須だ。
‘ モジュールレベルで保持し、インスタンスの生成コストを抑える
Private m_db As DAO.Database
Private Property Get CurrentDB_Optimized() As DAO.Database
If m_db Is Nothing Then
Set m_db = CurrentDb
End If
Set CurrentDB_Optimized = m_db
End Property
‘ オブジェクトのライフサイクルを明確に管理する
Private Sub Class_Terminate()
If Not m_db Is Nothing Then
Set m_db = Nothing
End If
End Sub
—
結論：コードは「状態」を制御するためにある
`DoCmd.RunCommand acCmdSaveRecord`は、単なる命令ではない。それは、「UI層の曖昧な入力」を「DB層の厳格なデータ」へ昇華させるための通過儀礼だ。
シニアエンジニアに求められるのは、機能の実装ではなく「状態の管理」である。ユーザーがいつ、どのような順序でデータを入力しようとも、システムが常に整合性を保てる状態（Consistent State）を強制すること。それこそが、Access開発における究極の責務である。
この記事を読んだ諸君には、明日から自分のコードにある「脆さ」を一つずつ排除していってもらいたい。アーキテクチャとは、積み上げた知見の集合体そのものなのだから。
