Access VBAを掌握する極限の知見：`DoCmd.RunCommand acCmdSaveRecord` による入力値確定とバリデーションの極意
レガシーシステムの骨幹を支え、今なお現場のミッションクリティカルな領域で稼働し続けるMicrosoft Access。その開発現場において、最も頻発し、かつエンジニアを悩ませる問題は何か。それは「ユーザーがコントロールを抜け出した瞬間に発生する、曖昧なレコード保存のタイミング」と「意図しないデータ不整合の野放し」である。
今回は、Access VBAのオブジェクトモデルの深層に踏り込み、`DoCmd.RunCommand acCmdSaveRecord` を用いた強制的なデータ確定と、堅牢なバリデーションアーキテクチャの構築手法について、妥協なき実務的知見を提示する。
—
1. Accessの暗黙の保存メカニズムと、なぜ「今すぐ保存」が必要なのか
Accessフォーム上のコントロール（テキストボックスやコンボボックス）に入力された値は、その瞬間には背後に潜むJet/ACEデータベースエンジンには書き込まれていない。値はフォームのバッファ（あるいはコントロールの保留中バッファ）に留まっており、以下のいずれかのタイミングで初めて「更新前イベント（`BeforeUpdate`）」を経てディスクへとコミットされる。
- ユーザーが別のレコードに移動したとき
- フォームが閉じられるとき
- `DoCmd.RunCommand acCmdSaveRecord` が明示的に呼び出されたとき
ここで発生する最大の問題は、「コードから別の処理（外部API連携や複雑なトランザクション処理など）を実行した際、カレントレコードがまだ未保存の状態であると、古いデータや空のデータを処理してしまう」という致命的なタイムラグである。
特に、保存ボタン等のクリックイベント内に記述されたVBAコードは、ボタンをクリックしただけではカレントレコードの `BeforeUpdate` が完了していないケースがある。この「保存の非同期性・曖昧さ」を断ち切り、プログラムの意図したタイミングで確実にデータをJetエンジンへ送り込むための唯一無二の手段が、`acCmdSaveRecord` の強制実行である。
—
2. アーキテクチャの核心：強制保存とトランザクション制御の融合
実務において、単に `acCmdSaveRecord` を叩くだけでは不十分だ。保存の過程で発生するバリデーションエラーや、ビジネスロジックの破綻をハンドリングし、必要に応じてロールバック（変更の破棄）を行える構造でなければ、プロフェッショナルなコードとは言えない。
以下に、実務の最前線で耐えうる、堅牢なレコード保存・バリデーションパターンの実装コードを示す。
‘ ==============================================================================
‘ モジュール名: 業務ロジック標準モジュール
‘ 概要: レコードの強制保存と厳密なバリデーション制御
‘ ==============================================================================
Public Function CommitCurrentRecord(ByRef frm As Form) As Boolean
On Error GoTo ErrorHandler
CommitCurrentRecord = False
‘ 1. コントロールのフォーカスを一度外すことで、現在編集中のコントロールの
‘ 「更新前イベント(BeforeUpdate)」を確実に発火させる。
‘ ※アクティブコントロールが存在しない場合のエラーを回避するためOn Errorを併用
On Error Resume Next
frm.ActiveControl.SetFocus
On Error GoTo ErrorHandler
‘ 2. AccessのUIコマンド経由で明示的にレコードを保存する。
‘ これによりフォームの BeforeUpdate / AfterUpdate が強制的に呼び出される。
If Me.Dirty Then ‘ フォームに変更がある場合のみ実行
DoCmd.RunCommand acCmdSaveRecord
End If
‘ 3. ここで追加のカスタムバリデーション（複数フィールドにまたがる整合性チェックなど）を実施
If Not ValidateBusinessLogic(frm) Then
‘ バリデーションエラー時は変更を破棄して処理を抜ける
frm.Undo
Exit Function
End If
CommitCurrentRecord = True
Exit Function
ErrorHandler:
‘ エラー番号 2046: 「現在、RunCommand コマンドを使用できません」等への対策
‘ エラー番号 3022: 2重登録（インデックスの重複）などのデータベースエンジンエラー
Select Case Err.Number
Case 2046
‘ 保存すべき変更がない場合は単にスルー
CommitCurrentRecord = True
Case Else
MsgBox “レコードの保存中に致命的なエラーが発生しました。” & vbCrLf & _
“エラー番号: ” & Err.Number & vbCrLf & _
Err.Description, vbCritical, “システムエラー”
‘ 異常系では変更を安全に破棄
If frm.Dirty Then frm.Undo
CommitCurrentRecord = False
End Select
End Function
Private Function ValidateBusinessLogic(ByRef frm As Form) As Boolean
‘ 例：開始日と終了日の整合性チェック
If Not IsNull(frm!txtStartDate) And Not IsNull(frm!txtEndDate) Then
If frm!txtStartDate > frm!txtEndDate Then
MsgBox “開始日は終了日よりも前の日付を指定してください。”, vbExclamation, “入力値不正”
frm!txtEndDate.SetFocus
ValidateBusinessLogic = False
Exit Function
End If
End If
ValidateBusinessLogic = True
End Function
—
3. シニアエンジニアが知るべき「罠」とパフォーマンスの最適化
`CurrentDb` とオブジェクトのライフサイクル
Access VBAにおける最大のパフォーマンス殺しは、不適切なオブジェクトの参照とメモリリークである。
しばしば以下のようなコードを見かけるが、これは悪手である。
‘ 【アンチパターン】毎回 CurrentDb を乱用する
CurrentDb.Execute “UPDATE …”
`CurrentDb` を呼び出すたびに、Accessは内部で新しいデータベースオブジェクト（DAO.Database）をメモリ上に生成し、セッションを確立している。ループ処理や高頻度で実行されるイベント内においてこれをやると、メモリフラグメンテーションを引き起こし、やがて「リソース不足」エラーやアプリケーションの強制終了を招く。
厳格なシステムを構築する場合、データベース参照は適切に変数を介して保持し、明示的に解放する（あるいはモジュールレベルでキャッシュする）べきである。
‘ 【推奨アプローチ】オブジェクトの明示的参照とスコープ管理
Public Sub ExecuteBulkProcess()
Dim db As DAO.Database
Set db = CurrentDb ‘ 一度だけ参照を取得
On Error GoTo ErrorHandler
db.Execute “SET NOCOUNT ON;”, dbFailOnError ‘ ※SQL Serverバックエンドの場合の例
‘ トランザクション処理の開始
db.BeginTrans
‘ レコード保存処理の呼び出し
If Not CommitCurrentRecord(Forms!frmMain) Then
db.Rollback
Exit Sub
End If
db.CommitTrans
Exit Sub
ErrorHandler:
db.Rollback
‘ エラーハンドリング
Finally:
‘ DAO.Databaseオブジェクトは CurrentDb の場合明示的 Set = Nothing が推奨される
Set db = Nothing
End Sub
Windows APIとの連携における注意点
高精度な排他制御や、フォームの描画抑制（画面のちらつき防止）のために `SendMessage` などのWindows APIを呼び出すアーキテクチャを採用している場合、`acCmdSaveRecord` によるイベントの連鎖に細心の注意を払わなければならない。
APIによる強制再描画と、Jetエンジンのデータコミットのタイミングが競合すると、稀に「Microsoft Access は動作を停止しました」という最悪の結末を迎える。APIを併用するレイヤーでは、必ず `DoEvents` や描画ロック（`Echo False`）の解除順序を完璧にコントロールする必要がある。
—
4. レガシー環境の保守とシステム間連携への布石
Accessが単なる「ローカルの小規模データベース」であった時代は終わった。現代のAccessは、バックエンドにSQL ServerやPostgreSQL、あるいはAzure SQL Databaseを抱え、フロントエンド（UI）としての役割に特化して稼働することが多い。
このアーキテクチャ（UPS：Up-Sizing）において、`DoCmd.RunCommand acCmdSaveRecord` は、ODBC経由でのリモートサーバーへのデータ送信トリガーとして極めて重要な役割を持つ。
ローカルのJetエンジンであれば許容されていた曖昧な型制約やNULL許容属性が、リモートのRDBに接続した瞬間、厳格な例外（ODBCエラー）として跳ね返ってくる。
だからこそ、リモートサーバーにデータが飛ぶ「一歩手前」のフォームレイヤーで、`acCmdSaveRecord` をプログラマティックに制御し、カスタムバリデーションで弾くという設計思想が不可欠なのだ。
—
総括
`DoCmd.RunCommand acCmdSaveRecord` は、単なる「保存ボタンの代用品」ではない。それは、Accessのイベント駆動モデルの隙間を埋め、開発者がデータのライフサイクルを完全に掌握するための「強力なコントロールレバー」である。
VBAの挙動、DAOのメモリ管理、そしてデータベースエンジンのコミットメントの仕組みを深く理解した者だけが、何年経過しようともビクともしない、極限まで堅牢なAccessシステムを構築できる。
この知見を実装に落とし込み、あなたのシステムの信頼性を次の次元へと引き上げてほしい。
