フォーム更新の聖域：`acCmdSaveRecord` を使いこなすためのアーキテクトの矜持
Access開発において、データ整合性の崩壊は「設計の敗北」を意味する。多くの初学者は `DoCmd.RunCommand acCmdSaveRecord` をただの「保存ボタン」だと考えているが、それはあまりに浅い。これは、Accessという強力な、しかし気難しいデータベースエンジンの「状態遷移」を強制的に叩くためのトリガーだ。
本稿では、レガシーシステムを延命させ、かつ堅牢なデータ整合性を担保するために必要な、真の「保存の作法」を伝授する。
—
1. `acCmdSaveRecord` の本質：イベントの連鎖を理解せよ
`acCmdSaveRecord` を呼び出すことは、単にバッファをディスクに書き出すことではない。それは以下の「イベントの連鎖」を強制的に同期させる行為である。
1. BeforeUpdate: データの妥当性検証の砦（ここで拒絶すれば保存は中止される）。
2. AfterUpdate: 更新後の副作用（計算フィールドの更新やログ出力）。
3. Current: レコードポインタの移動に伴う状態更新。
このコマンドを闇雲に発行すれば、予期せぬ無限ループや、スタックオーバーフローを招く。特に、`Form_BeforeUpdate` 内で自身を保存しようとするような愚行は、Accessのオブジェクトモデルを破壊する。
ベストプラクティス：明示的なバリデーションのトリガー
保存を強制する前に、必ず「Dirty状態」を確認せよ。無駄なトランザクションはメモリとI/Oの浪費である。
Public Sub ForceSaveCurrentRecord(frm As Access.Form)
‘ オブジェクトの存在確認（ヌルチェックは基本）
If frm Is Nothing Then Exit Sub
‘ Dirtyプロパティを確認し、変更がある場合のみ処理を実行する
If frm.Dirty Then
‘ エラーハンドリングを組み込み、バリデーションエラーを捕捉する
On Error GoTo Err_Handler
DoCmd.RunCommand acCmdSaveRecord
End If
Exit Sub
Err_Handler:
‘ 2501はRunCommandのキャンセル（バリデーション失敗時など）
If Err.Number <> 2501 Then
MsgBox “予期せぬエラー: ” & Err.Description, vbCritical
End If
End Sub
—
2. BeforeUpdateこそが「唯一の聖域」
ビジネスロジックにおけるバリデーションは、フォーム上のあらゆるボタンに書くべきではない。`BeforeUpdate` イベントに集約せよ。
`acCmdSaveRecord` を呼び出すと、Accessは自動的に `BeforeUpdate` を発火させる。もしここでバリデーションエラーを検出し `Cancel = True` とすれば、物理的な保存は中断される。これが、データ整合性を守るための唯一の「作法」だ。
Private Sub Form_BeforeUpdate(Cancel As Integer)
‘ データの整合性チェック
If IsNull(Me.txtEntryDate.Value) Or Me.txtEntryDate.Value > Date Then
MsgBox “日付が不正です。”, vbExclamation
Cancel = True ‘ ここで保存を物理的にブロックする
Me.txtEntryDate.SetFocus
End If
End Sub
—
3. レガシー環境でのメモリ・パフォーマンス最適化
長期間稼働するAccessシステムでは、オブジェクトの「残留」がメモリリークを招く。特に `CurrentDb` の扱いには細心の注意が必要だ。
「CurrentDb」のキャッシュを避ける
`CurrentDb` は呼び出すたびに新しいインスタンスを生成する可能性がある。DAO.Databaseオブジェクトを不用意に保持し続けると、メモリを圧迫し、マルチユーザー環境でのロック競合を引き起こす。
- 鉄則: 必要最小限のスコープで宣言し、使用後は明示的に解放せよ。
Sub UpdateRelatedRecord(recordID As Long)
Dim db As DAO.Database
‘ 必要になった瞬間に生成
Set db = CurrentDb
‘ 処理実行
db.Execute “UPDATE T_Log SET Status = ‘Processed’ WHERE ID = ” & recordID, dbFailOnError
‘ 伝説のエンジニアはここで「解放」する
Set db = Nothing
End Sub
—
4. 極限の知見：Windows APIによる「保存の強制」の裏側
もし、特定の入力フィールドだけを強制的に確定させたい場合、`acCmdSaveRecord` では大仰すぎることもある。その場合、フォーカスをコントロール間で移動させるだけで十分なケースがある。
しかし、システム連携において「絶対に失敗が許されない」場合は、`LockWindowUpdate` APIを使用して描画を停止し、更新中のチラつきを抑えつつ、バックグラウンドでトランザクションを完結させるのがプロの仕事だ。
‘ 描画の凍結（重厚な更新処理を行う際に使用）
Private Declare PtrSafe Function LockWindowUpdate Lib “user32” (ByVal hwndLock As LongPtr) As LongPtr
Public Sub SafeUpdateProcess(frm As Access.Form)
LockWindowUpdate frm.hwnd
On Error Resume Next
‘ ここで複雑なロジックを展開
DoCmd.RunCommand acCmdSaveRecord
‘ 必ず解除（これを忘れるとAccessが固まったように見える）
LockWindowUpdate 0
End Sub
—
結びに：技術は「守り」のためにある
Access VBAはレガシーと言われるが、そのオブジェクトモデルは極めて洗練されている。`acCmdSaveRecord` を「何となく使う」のではなく、「Accessが持つ状態遷移のシーケンスを制御する」という意識を持って扱ってほしい。
コードを一行書くごとに、その背後にあるメモリ消費、ロックの状態、そしてユーザーの業務フローを想像せよ。それができる者だけが、十年先もメンテナンス可能な「真のシステム」を構築できる。
あなたの書くコードが、明日の誰かの救いになることを願っている。
