Access開発の現場において、プロとアマを分かつ決定的な境界線はどこにあるか知っているか？
それは、「Accessを単なるローカルなオモチャとして扱うか、それとも厳格なライフサイクルを持つシステム基架として制御するか」だ。
多くの開発者は、フォームやレポートをUI上でポチポチと作り、プロパティシートから「起動時のフォーム」を手動で設定して満足する。だが、想像してほしい。大規模なデータ改修、緊急時のメンテナンス、あるいはマルチユーザー環境下での強制アップデート。そんな修羅場が訪れたとき、UIをいちいち手動でクリックして起動画面を切り替えるなどという愚行を犯していないか？
今回は、`CurrentDb.Properties`を極限まで掌握し、VBAのコード一本で「起動時のフォーム」を動的にねじ伏せる、極めて実践的な環境制御のアーキテクチャを伝授する。
—
なぜUI手動設定ではダメなのか？ ── 現場が破綻するメカニズム
開発現場でよくある失敗が、メンテナンスモード用フォームへの切り替えを「設計者の手作業」に依存することだ。
1. ヒューマンエラーの温床: リリース手順書に「起動フォームをMaintenanceFrmに変更してください」と書き、戻し忘れて本番稼働させ、ユーザーがパニックを起こす。
2. 無人運用（バッチ処理・自動起動）への対応不能: 夜間バッチでAccessを自動起動させ、裏でデータ同期だけを走らせたい場合、GUIのプロパティ固定では太刀打ちできない。
3. トランザクションと排他制御の矛盾: メンテナンス中に一般ユーザーが突撃してくるのを防ぐには、アプリケーション層に到達する手前、あるいは起動の瞬間にルーティングを制御しなければ意味がない。
これを解決するのが、「CurrentDb.Propertiesによる起動時プロパティの動的書き換え」である。
—
アーキテクチャの核心：`CurrentDb.Properties`の罠と作法
Accessのシステムプロパティ（`StartupForm`など）は、通常のテーブル定義とは異なり、「最初から存在しているとは限らない」という極めて厄介な仕様を持っている。
ここに素人が書いた浅いコードがある。
‘ 【アンチパターン】これではエラーで即死する
CurrentDb.Properties(“StartupForm”) = “frm_Maintenance”
なぜこれがダメか？
`StartupForm`というプロパティがまだ一度も設定されていないデータベースに対してこのコードを実行すると、「実行時エラー 3270: プロパティが見つかりません。」が発生してプログラムがクラッシュする。
プロフェッショナルなエンジニアは、存在しないなら「創造」し、存在するなら「上書き」する、動的なプロパティ管理関数を必ず用意する。
—
プロダクションコード：堅牢なるモード切替エンジン
以下のモジュールを標準モジュール（例：`modEnvironmentManager`）に配置してほしい。
エラーハンドリングを完璧に網羅し、トランザクションの整合性を担保した、そのまま実務で使えるプロダクションコードだ。
Option Compare Database
Option Explicit
‘ ==============================================================================
‘ モジュール名: modEnvironmentManager
‘ 概要: 起動時フォームおよびアプリケーション環境の動的制御エンジニアリング
‘ 記述者: チーフアーキテクト
‘ ==============================================================================
‘ 操作対象のシステムプロパティ名
Private Const PR_STARTUP_FORM As String = “StartupForm”
Public Sub SwitchApplicationMode(ByVal isMaintenance As Boolean)
On Error GoTo ErrorHandler
Dim db As DAO.Database
Set db = CurrentDb
Dim targetForm As String
‘ モードに応じたルーティング先の決定
If isMaintenance Then
targetForm = “frm_MaintenanceMode” ‘ メンテナンス用フォーム
MsgBox “システムを【メンテナンスモード】に切り替えます。”, vbExclamation, “環境制御”
Else
targetForm = “frm_Dashboard” G ‘ 通常運用用ダッシュボード
MsgBox “システムを【通常モード】に切り替えます。”, vbInformation, “環境制御”
End If
‘ プロパティの動的設定（存在しない場合の生成ロジックを含む）
Call SetDatabaseProperty(db, PR_STARTUP_FORM, dbText, targetForm)
‘ 変更を確実に反映させるためのキャッシュクリア
db.Properties.Refresh
MsgBox “起動時フォームの切替に成功しました。” & vbCrLf & _
“次回起動時から [” & targetForm & “] が展開されます。”, vbInformation, “完了”
Exit Sub
ErrorHandler:
MsgBox “致命的なエラーが発生しました。” & vbCrLf & _
“Error ” & Err.Number & “: ” & Err.Description, vbCritical, “異常終了”
End Sub
Private Sub SetDatabaseProperty(ByRef db As DAO.Database, ByVal propName As String, ByVal propType As DAO.DataTypeEnum, ByVal propValue As Variant)
On Error GoTo SetProp_Error
‘ 既存のプロパティへの代入を試みる
db.Properties(propName) = propValue
Exit Sub
SetProp_Error:
‘ エラー 3270: プロパティが見つからない場合のみ、新規作成を行う
If Err.Number = 3270 Then
Dim prp As DAO.Property
Set prp = db.CreateProperty(propName, propType, propValue)
db.Properties.Append prp
Set prp = Nothing
Else
‘ その他の予期せぬエラーは上位へスロー
Err.Raise Err.Number, “SetDatabaseProperty”, Err.Description
End If
End Sub
—
この設計がもたらす圧倒的な実務メリット
このコードを組み込むことで、あなたのAccess開発プロジェクトは次のステージへ進化する。
1. 外部からの遠隔制御（マスターDBからの指令）
例えば、サーバー上のフラグ用テキストファイルや、バックエンドDBのコントロールテーブルを監視するバッチ用ショートカットを用意しておけば、「管理者が一歩も動くことなく、全拠点のAccess端末を強制的にメンテナンスモードで起動させる」といった高度なフリート管理が可能になる。
2. デプロイプロセスの完全自動化
CI/CDパイプラインやデプロイ用のVBScriptからAccessをオブジェクトとして呼び出し、リリース直前にこのVBA関数をサイレント実行させることで、人手による設定ミスをゼロに収束させられる。
—
チーフアーキテクトからの最終告白
Accessは、しばしば「お絵描きツール崩れ」と揶揄されることがある。だがそれは、開発者がそのオブジェクトモデルの本質を理解せず、IDEのGUI機能に依存しきっているからに他ならない。
`CurrentDb.Properties` を手足のように操り、アプリケーションのライフサイクルそのものをコードで支配できるようになれば、Accessはもはや単なる「ローカルDBのビューア」ではなく、「堅牢で自律的なエンタープライズ・クライアント・アプリケーション」へと姿を変える。
この知見をあなたの現場に持ち帰り、泥臭い手作業を駆逐してほしい。健闘を祈る。
