【Access VBA極限の知見】CurrentDb.Propertiesを掌握せよ：起動時プロパティの動的書き換えとアーキテクチャ設計
シニアエンジニアや社内システム管理者であれば、一度は直面したことがあるはずだ。
「本番環境、ステージング環境、開発環境で、Accessの起動時フォームやリボン、ナビゲーションウィンドウの挙動を切り替えたい」
「配布用のフロントエンドDBに対し、初回起動時に自動で環境依存のプロパティを構成させたい」
AccessのUIから「ファイル」＞「オプション」＞「現在のデータベース」をポチポチと手動で設定しているようでは、プロフェッショナルなシステムインテグレーションとは言えない。環境構築の自動化、そして何より「コードによるメタデータの完全な掌握」こそが、レガシーとモダンが混在する現場を生き抜くエンジニアの必須要件だ。
今回は、`CurrentDb.Properties`を極限まで使い倒し、データベースの起動時プロパティをプログラムから動的に制御する技術的真髄を解説する。
—
1. Accessオブジェクトモデルの深層：`CurrentDb`の重みとライフサイクル
多くの初級・中級プログラマが犯す最大の過ちは、`CurrentDb`というメソッドの正体を理解していないことだ。
`CurrentDb`は、単なるショートカットではない。呼び出されるたびに「現在のデータベースへの新しいDAO.Databaseオブジェクトのインスタンス」をヒープ上に生成する。
つまり、以下のようなコードは最悪のアンチパターンの見本と言える。
‘ 【悪夢のアンチパターン】
Debug.Print CurrentDb.Properties(“AppTitle”)
Debug.Print CurrentDb.Properties(“StartupForm”)
‘ これでは無駄に2つのインスタンスが生成され、メモリリークとパフォーマンス低下を招く
アーキテクトの鉄則：オブジェクト変数の局所化と明示的解放
`Properties`コレクションへアクセスする際は、必ず`Database`オブジェクトをローカル変数に参照させ、処理終了後は即座に明示的（`Nothing`代入）に解放しなければならない。AccessのガベージコレクションやCOMコンポーネントの参照カウンタの挙動を信用してはならないのだ。
—
2. 存在しないプロパティの罠：動的追加（CreateProperty）のイディオム
Accessのデータベースプロパティ（`Properties`コレクション）の最も厄介な性質は、「デフォルトでは存在しないプロパティが多数ある」という点だ。
例えば、`StartupForm`（起動時のフォーム）などは、一度もGUIから設定したことがないデータベースの`Properties`コレクションには存在しない。存在しないキーに対して直接代入を行おうものなら、容赦なく実行時エラー（エラー3270: プロパティが見つかりません）が飛んでくる。
したがって、堅牢なコードを書くためには、「プロパティが存在すれば書き換え、存在しなければ新規作成（Append）する」という堅牢なラッパー関数を構築する必要がある。
以下に、実務でそのまま使える極限まで最適化されたユーティリティコードを示す。
‘ ==============================================================================
‘ データベースプロパティを安全に設定・追加する汎用プロシージャ
‘ ==============================================================================
Public Sub SetDatabaseProperty(ByVal PropName As String, ByVal PropType As DataTypeEnum, ByVal PropValue As Variant)
Dim dbs As DAO.Database
Dim prp As DAO.Property
Dim isFound As Boolean
‘ CurrentDbのインスタンスをローカル変数に捕捉
Set dbs = CurrentDb()
isFound = False
‘ エラーハンドリングの準備（プロパティ未存在エラーをトラップするため）
On Error GoTo ErrorHandler
‘ 既存のプロパティを走査
For Each prp In dbs.Properties
If prp.Name = PropName Then
isFound = True
Exit For
End If
Next prp
If isFound Then
‘ 存在する場合は値を更新
dbs.Properties(PropName).Value = PropValue
Else
‘ 存在しない場合は新規作成してPropertiesコレクションに追加
Set prp = dbs.CreateProperty(PropName, PropType, PropValue)
dbs.Properties.Append prp
> End If
CleanUp:
‘ 【重要】COMオブジェクトの明示的解放
If Not prp Is Nothing Then Set prp = Nothing
If Not dbs Is Nothing Then Set dbs = Nothing
Exit Sub
ErrorHandler:
‘ エラー3270等の予期せぬ例外に対するフォールバック
MsgBox “プロパティの設定中にエラーが発生しました: ” & Err.Description, vbCritical, “System Error”
Resume CleanUp
End Sub
—
3. 実践：環境に応じた起動時プロパティの動的切り替え
このユーティリティを活用すれば、例えば「起動時フォーム（StartupForm）」や「アプリケーションタイトル（AppTitle）」、さらには「ナビゲーションウィンドウの非表示（StartupShowDBWindow）」などを、環境（あるいは外部設定ファイル）に応じて一発で切り替えることが可能になる。
以下のコードは、本番環境用と開発環境用で起動フォームを動的に切り替える実用的なイディオムだ。
‘ ==============================================================================
‘ 環境に応じた起動時設定を適用するメインプロシージャ
‘ ==============================================================================
Public Sub ApplyEnvironmentSettings(ByVal isProduction As Boolean)
On Error GoTo ErrorHandler
If isProduction Then
‘ 本番環境向け設定
‘ 1. 起動フォームをメインメニューに変更
Call SetDatabaseProperty(“StartupForm”, dbText, “frm_MainDashboard_Prod”)
‘ 2. ナビゲーションウィンドウ（データベースウィンドウ）を非表示に
Call SetDatabaseProperty(“StartupShowDBWindow”, dbBoolean, False)
‘ 3. 組み込みメニューバーを非表示（独自リボン強制）
Call SetDatabaseProperty(“StartupShowStatusBar”, dbBoolean, True)
‘ 4. アプリケーションタイトルの変更
Call SetDatabaseProperty(“AppTitle”, dbText, “【本番】社内基幹業務システム v2.4”)
Debug.Print “[INFO] 本番環境向けプロパティの適用が完了しました。”
Else
‘ 開発・ステージング環境向け設定
‘ 1. 起動フォームをデバッグ用コンソールに変更
Call SetDatabaseProperty(“StartupForm”, dbText, “frm_DevConsole”)
‘ 2. デバッグ用にナビゲーションウィンドウを表示
Call SetDatabaseProperty(“StartupShowDBWindow”, dbBoolean, True)
‘ 3. アプリケーションタイトルの変更
Call SetDatabaseProperty(“AppTitle”, dbText, “【開発・検証】社内基幹業務システム v2.4”)
Debug.Print “[INFO] 開発環境向けプロパティの適用が完了しました。”
> End If
‘ キャッシュを強制的に更新するためにRefreshTitleBarを呼び出す
Application.RefreshTitleBar
Exit Sub
ErrorHandler:
MsgBox “環境設定の適用に失敗しました: ” & Err.Err.Description, vbCritical
End Sub
—
4. チーフアーキテクトからの警鐘：この手法を運用する上での罠
`CurrentDb.Properties`の動的書き換えは強力無比な武器だが、運用フェーズにおいて以下の罠に陥ることがある。
1. 排他制御とマルチユーザー環境の衝突
`CurrentDb.Properties`への書き込み（特に`Append`やプロパティの変更）は、データベースに対する排他ロック（Exclusive Lock）を要求する場合がある。多人数が同時にアクセスしている共有サーバー上のACCDBファイルに対して、このコードを実行するとエラーが発生するか、最悪の場合ファイルが破損する。
対策: この種のメタデータ書き換えは、必ずユーザーが誰も接続していないデプロイ時（インストーラー実行時や、フロントエンドのローカルPCへの初回コピー時）にのみ実行されるよう、アーキテクチャを設計せよ。
2. シフトキーバイパス（BypassKey）との組み合わせ
起動時設定を動的に変更するシステムでは、開発者がデバッグのためにコードへアクセスできなくなるリスクが常に伴う。起動時プロパティを制御するのと同時に、必要に応じてシフトキーの有効/無効（`AllowBypassKey`）もプログラムから制御する高度なガードを組み込むのが、真にプロフェッショナルなエンジニアの流儀である。
—
5. 総括
Access VBAは「おもちゃの言語」などではない。その内部構造（JET/Access EngineのCOMオブジェクトモデル）を正しく理解し、メモリ管理とライフサイクルを完全に制御下におくことで、モダンなエンタープライズシステムにも匹敵する堅牢な動的アプリケーション制御が可能となる。
`CurrentDb.Properties`の掌握。それは、Accessの挙動のすべてをあなたのコードの奴隷にするための、最初の、そして不可欠なステップなのだ。
