データベースの深淵を制御する：CurrentDb.Propertiesの極致
Accessというプラットフォームは、単なるRADツールではない。適切に調律すれば、それは堅牢な業務基幹システムへと化ける。多くの開発者が `DoCmd` の海で溺れる中、真のアーキテクトは `CurrentDb` の深淵、すなわちデータベースのメタデータ層を直接操作することで、アプリケーションの挙動を根本から制御する。
今回は、`CurrentDb.Properties` を用いてアプリケーションの境界を拡張し、動的な環境構築と最適化を行うための「禁断の知見」を共有する。
—
1. CurrentDb.Properties の本質：DAOの生存戦略
`CurrentDb` を呼び出すたびに、Accessは内部的にデータベースエンジンを再評価し、メモリ上にオブジェクトを生成する。多用すればパフォーマンスは劣化し、オブジェクトの解放漏れはメモリリークの温床となる。
まず、大原則を叩き込んでおけ。「CurrentDbは変数に格納し、使い終わったら即座にNothingで解放せよ」。
‘ 非推奨：何度もCurrentDbを叩くのはリソースの無駄遣いである
‘ CurrentDb.Properties(“AppTitle”).Value = “System”
‘ CurrentDb.Properties(“StartUpForm”).Value = “Main”
‘ 推奨：オブジェクトを単一インスタンスで管理し、ライフサイクルを制御する
Public Sub UpdateDatabaseProperty(strPropName As String, varValue As Variant)
Dim db As DAO.Database
Dim prp As DAO.Property
Set db = CurrentDb
On Error Resume Next
‘ プロパティが存在しない場合はDAOのコレクションに追加する
Set prp = db.Properties(strPropName)
If Err.Number <> 0 Then
Set prp = db.CreateProperty(strPropName, dbText, varValue)
db.Properties.Append prp
Else
prp.Value = varValue
End If
On Error GoTo 0
‘ 明示的な解放。Accessのガベージコレクションを信じてはならない
Set prp = Nothing
Set db = Nothing
End Sub
—
2. タイトルバーと起動設定の動的ハッキング
社内システムにおいて、開発環境・テスト環境・本番環境を切り替える際、アイコンやタイトルバーを動的に変更することは、オペミスを防ぐ最良の防御策だ。
`AppTitle` や `StartUpForm` などのプロパティをVBAから書き換えることで、ユーザーに「今、どの環境にログインしているか」を視覚的に強制できる。
Public Sub ApplyEnvironmentSettings(envName As String)
‘ 開発環境ならタイトルに警告を表示し、色を変えるなどのメタ操作
Select Case envName
Case “PROD”
Call UpdateDatabaseProperty(“AppTitle”, “基幹業務システム”)
Case “DEV”
Call UpdateDatabaseProperty(“AppTitle”, “【開発環境】基幹業務システム”)
‘ 必要に応じてスタートアップフォームをデバッグ用へ変更
Call UpdateDatabaseProperty(“StartUpForm”, “frm_DebugConsole”)
End Select
‘ ここでApplication.RefreshTitleBarを呼ぶのが作法だが、
‘ より深く制御するならWindows APIのSendMessageを叩くこともある
End Sub
—
3. メモリとパフォーマンスの極限：レガシー保守の知見
レガシーなAccess環境において、`Properties` 操作はしばしば「書き込み遅延」を引き起こす。システムが肥大化している場合、プロパティ変更後に `db.TableDefs.Refresh` や `db.Properties.Refresh` を実行しないと、変更がメモリ上に反映されないケースがある。
特に、マルチユーザー環境で `Properties` を書き換える際は、以下の点に注意せよ。
- 排他制御の罠: プロパティ変更はデータベースの排他ロックを要求する。ユーザーがフォームを開いている最中にバックグラウンドでプロパティを書き換えると、ロックエラーで落ちる。必ず「シングルユーザーモード」で管理者権限で実行するか、起動時（AutoExec）のタイミングを厳守せよ。
- APIによるウィンドウ制御: `AppTitle` を変更しただけでは、タスクバーのアイコン名称は即座に変わらない。その場合、Windows APIの `SetWindowText` を使用して、hWnd（ウィンドウハンドル）を直接叩くのが真のエンジニアの流儀だ。
If VBA7 Then
Private Declare PtrSafe Function SetWindowText Lib “user32” Alias “SetWindowTextA” (ByVal hwnd As LongPtr, ByVal lpString As String) As Long
Else
Private Declare Function SetWindowText Lib “user32” Alias “SetWindowTextA” (ByVal hwnd As Long, ByVal lpString As String) As Long
End If
Public Sub ForceUpdateWindowCaption(newCaption As String)
‘ Application.hWndAccessApp を使用してAccess本体のウィンドウを制御
SetWindowText Application.hWndAccessApp, newCaption
End Sub
—
最後に：アーキテクトからの提言
Accessは、正しく扱えば「巨大なデスクトップ・マイクロサービス」へと昇華する。`CurrentDb.Properties` は、その心臓部の設定を司るレジストリのようなものだ。
安易なコードのコピペで済ませるな。オブジェクトのライフサイクルを理解し、メモリの状態を可視化し、レガシーとモダンなAPIの境界を自在に行き来せよ。それが、終わりのない保守開発に立ち向かう我々技術者の矜持である。
次にコードを書くとき、その `db` 変数がいつ生成され、いつ破棄されるのかを深く意識してみろ。そこには、まだ君が見たことのないAccessの真の姿があるはずだ。
