Access VBAを掌握する極限の知見：起動時フォームの動的制御による「ゼロ・ダウンタイム運用管理基盤」の構築
レガシーシステムの最前線において、Microsoft Accessは今なお強力なラピッドアプリケーション開発プラットフォームとして君臨している。しかし、その手軽さゆえに、運用フェーズにおける「メンテナンス性」の欠如がアーキテクトの頭を悩ませてきた。
特に、全社展開されたマルチユーザー環境において、データベースのスキーマ改修やマスタデータのメンテ中、ユーザーが勝手にフロントエンドからアクセスしてデータを破壊する事象は、現場のエンジニアにとって悪夢そのものである。
今回は、`CurrentDb.Properties`を低レイヤーから意のままに操り、メンテナンスモードと通常モードをVBAの実行コンテキストから動的に切り替える「起動時フォーム動的制御アーキテクチャ」を解説する。
—
1. アーキテクチャの核心：なぜ `CurrentDb.Properties` なのか
Accessの「起動時のフォーム（StartupForm）」設定は、GUIから指定する限り静的なメタデータに過ぎない。これを開発者がハードコードし、リリースごとにACCDEを作り直すようなアプローチは、CI/CDが浸透した現代において技術的負債の極みである。
`CurrentDb` オブジェクトが保持する `Properties` コレクションは、データベースの起動動作を規定するシステムプロセスの根幹に位置する。ここをVBAから直接書き換えることで、「アプリケーションの自己書き換え（Self-Modifying Application State）」が可能となる。
注意すべきプロセスの罠
`CurrentDb` は呼び出すたびにメモリ上に新しい DAO.Database オブジェクトのインスタンスを生成する。このオブジェクトのライフサイクルとスコープを誤ると、メモリリークだけでなく、Accessエンジン（ACE）の内部キャッシュと同期ズレを起こし、最悪の場合はプロパティの書き込みが沈黙する（エラーすら吐かずに無視される）。
プロパティ操作の鉄則は、「明示的な変数保持、存在確認、そして即座の参照破棄」である。
—
2. 実装：動的起動スイッチング・モジュール
以下のコードは、バックエンド（または外部設定ファイル）のフラグを読み取り、次回の起動時に表示されるフォームを「通常用メニュー (`frm_Main`)」から「メンテナンス画面 (`frm_Maintenance`)」へと動的にスイッチングするコアエンジンである。
標準モジュールに配置し、システムのメンテナンス管理権限を持つ管理者のみが実行できるように設計せよ。
Option Explicit
Option Private Module
‘ ==============================================================================
‘ 起動時フォーム動的制御モジュール
‘ アーキテクチャ観点：DAOプロパティの直接操作によるランタイム環境制御
‘ ==============================================================================
Private Const PROP_STARTUP_FORM As String “StartupForm”
Public Sub SwitchStartupForm(ByVal Mode As EnumSystemMode)
Dim db As DAO.Database
Dim propName As String
Dim targetForm As String
Dim isPropExists As Boolean
‘ 1. モードに応じたターゲットフォームの決定
Select Case Mode
Case Mode_Normal
targetForm = “frm_Main”
Case Mode_Maintenance
targetForm = “frm_Maintenance”
Case Else
Err.Raise vbObjectError + 1000, “SwitchStartupForm”, “無効なシステムモードが指定されました。”
End Select
‘ 2. CurrentDbの明示的な取得とスコープ限定
Set db = CurrentDb
On Error GoTo ErrorHandler
‘ 3. プロパティの存在確認と動的設定
isPropExists = CheckPropertyExists(db, PROP_STARTUP_FORM)
If isPropExists Then
‘ 既存プロパティの値を更新
db.Properties(PROP_STARTUP_FORM).Value = targetForm
Else
‘ プロパティが存在しない場合（極めて稀だが新規DB等で発生）は動的生成
Dim prp As DAO.Property
Set prp = db.CreateProperty(PROP_STARTUP_FORM, dbText, targetForm)
db.Properties.Append prp
Set prp = Nothing
End If
‘ 4. 変更を永続化するためのキャッシュフラッシュ
db.Containers(“Databases”).Documents(“UserDefined”).Properties.Refresh
MsgBox “システム起動モードを切り替えました。” & vbCrLf & _
“次回の起動から [” & targetForm & “] がロードされます。”, _
vbInformation, “アーキテクチャ制御マネージャー”
CleanUp:
‘ 5. 厳格なオブジェクト解放（ACEエンジンのメモリ最適化）
If Not db Is Nothing Then
db.Close
Set db = Nothing
End If
Exit Sub
ErrorHandler:
MsgBox “致命的なエラーが発生しました: ” & Err.Description, vbCritical, “Critical Error”
Resume CleanUp
End Sub
‘ — ヘルパー関数: プロパティ存在確認（DAOコレクションの安全な走査） —
Private Function CheckPropertyExists(ByRef db As DAO.Database, ByVal propName As String) As Boolean
Dim prp As DAO.Property
Dim exists As Boolean
exists = False
On Error Resume Next
For Each prp In db.Properties
If prp.Name = propName Then
exists = True
Exit For
End If
Next prp
On Error GoTo 0
CheckPropertyExists = exists
End Function
Public Enum EnumSystemMode
Mode_Normal = 1
Mode_Maintenance = 2
End Enum
—
3. 運用管理の極み：セッション排他制御と組み合わせる
単に起動フォームを変えるだけでは不十分だ。すでに常駐しているユーザーがいる状態で突然メンテナンスモードに切り替えても、彼らの作業を強制終了しない限り意味がない。
真に堅牢なエンタープライズ・アクセスシステムでは、この動的フォーム切り替えロジックと、「LDBファイル（.laccdb）の監視」あるいは「共有バックエンドのフラグテーブル」のポーリングを組み合わせる。
自動ロックダウン・シーケンスの設計思想
1. 管理者によるトリガー: 管理者がメンテナンス用フォームから「全社ロックダウン」を実行。
2. フラグ書き込み: 共有バックエンドの `T_SystemConfig` テーブルの `MaintenanceMode` フィールドを `True` に更新。
3. 自己防衛機能: 各クライアントがバックグラウンドでタイマー実行しているイベント（またはフォーム初期化時）でフラグを検知。
4. 強制退避: ユーザーに警告を発し、作業中のデータを強制保存の上、`Application.Quit` を実行。
5. 次回の静寂: 次回起動時、冒頭の `SwitchStartupForm` がすでにメンテナンスモードを指しているため、一般ユーザーは侵入できず「システムはメンテナンス中です」という専用フォームの要塞に迎えられる。
—
4. シニアエンジニアが知るべきトラブルシューティング
この手法を導入する際、現場で必ず直面する壁が2つある。
① 「コンパイルエラー：ユーザー定義型は定義されていません」
`DAO.Database` や `DAO.Property` を使用する際、VBEの参照設定から 「Microsoft DAO 3.6 Object Library」（またはACCDB環境であれば `Microsoft Office 16.0 Access database engine Object Library`）のチェックが外れていると発生する。
レガシー環境や異なるPC間でソースをインポートする際は、コード内で動的に型解決を行う（Late Binding）か、プロジェクトファイル側で参照設定を完全に統一化するビルドスクリプトを導入すべきである。
② ACCDE環境におけるプロパティ書き込みの制限
ACCDE（実行形式）ファイルは、VBAコードのコンパイル済みバイナリであり、原則としてコード内からの自己スキーマ変更（`CreateProperty` など）が制限される場合がある。
しかし、`CurrentDb.Properties` の既存値の書き換え（Update）は、ACCDE環境下であっても実行権限が許容されていれば正常に機能する。新規プロパティの追加は必ず開発環境（ACCDB）で行い、運用環境（ACCDE）では「値の書き換えのみ」に絞る設計が、デプロイ時のトラブルを防ぐ定石である。
—
総括
Access VBAを「おもちゃのスクリプト言語」と侮る者は、そのオブジェクトモデルの深淵を見たことがない者だ。
`CurrentDb.Properties` を手中に収めることは、Accessというブラックボックスの心臓部を直接チューニングすることを意味する。メンテナンスモードの動的制御は、その氷山の一角にすぎない。この知見を応用し、現場の運用コストを限界まで削ぎ落とした「止まらないレガシーシステム」を構築し続けてほしい。
