Accessの「魂」にメタデータを刻め：DAO.Database.CreatePropertyによる堅牢な設定管理術
Access開発において、バージョン管理や設定値をどこに置くかは永遠の課題だ。外部テキストファイルやレジストリ、あるいは専用の「設定テーブル」を作るのも一つの手だが、DBの肥大化を避け、配布・管理を簡潔にしたいなら、「データベースプロパティ」こそが最適解である。
今回は、DAOを用いてデータベースそのものにカスタムプロパティを埋め込み、堅牢に管理するテクニックを伝授する。これは、大規模な業務システムを長年運用してきたアーキテクトが辿り着く、最もエレガントな設計の一つだ。
—
1. なぜ「設定テーブル」ではなく「データベースプロパティ」なのか
初心者は設定を保持するために「T_SystemConfig」のようなテーブルを作る。しかし、これには以下のリスクが伴う。
- 誤削除のリスク: ユーザーや運用担当者が誤ってレコードを消せばシステムは沈黙する。
- クエリ汚染: データベースウィンドウに常に設定用のテーブルが表示され、不要なノイズとなる。
- 配布時の手間: フロントエンドを更新する際、テーブルの同期管理という余計な作業が発生する。
DAOの`Properties`コレクションを使えば、DB本体の「メタデータ」として情報を埋め込める。ユーザーの手が届かない場所で、かつプログラムの実行環境に関わらず常にそこに存在する。これが「プロフェッショナルの隠し場所」だ。
—
2. 実装の要：CreatePropertyの作法
Accessの`CurrentDb`が持つ`Properties`は、実は「ユーザー定義のプロパティ」を動的に追加できる柔軟な構造を持っている。ただし、「存在しなければ作成し、存在すれば書き換える」という例外処理を網羅しなければならない。
堅牢な実装コード（コピペ＆調整用）
以下は、プロパティの書き込み・読み込みをカプセル化したモジュール例だ。
Option Compare Database
Option Explicit
‘ プロパティの書き込み（新規作成または更新）
Public Sub SetDBProperty(strName As String, varValue As Variant, Optional intType As Integer = dbText)
Dim db As DAO.Database
Dim prp As DAO.Property
Set db = CurrentDb
On Error Resume Next
‘ プロパティが存在するか確認
Set prp = db.Properties(strName)
If Err.Number <> 0 Then
‘ 存在しない場合は新規作成
Set prp = db.CreateProperty(strName, intType, varValue)
db.Properties.Append prp
Else
‘ 存在する場合は値を更新
prp.Value = varValue
End If
On Error GoTo 0
Set db = Nothing
End Sub
‘ プロパティの取得（存在しない場合はデフォルト値を返す）
Public Function GetDBProperty(strName As String, Optional varDefault As Variant = “”) As Variant
Dim db As DAO.Database
Set db = CurrentDb
On Error Resume Next
GetDBProperty = db.Properties(strName).Value
‘ プロパティが未定義ならデフォルト値を返し、ついでに作成しておく
If Err.Number <> 0 Then
GetDBProperty = varDefault
End If
On Error GoTo 0
Set db = Nothing
End Function
—
3. 実務での運用における注意点
この手法を本番環境で使う際、いくつか「熟練者なら当然知っておくべき」落とし穴がある。
1. データ型の整合性
`CreateProperty`の第3引数にはデータ型（`dbText`, `dbLong`, `dbDate`など）を指定する。適当に指定すると、取得時に型不整合でエラーになる。バージョン文字列なら`dbText`、更新日時なら`dbDate`と、厳密に管理すること。
2. データベースの排他ロック
`CurrentDb`を使用してプロパティを変更する場合、そのデータベースファイルに対する書き込み権限が必要だ。読み取り専用で開かれている環境ではエラーになるため、起動時に「書き込み可能か」をチェックするルーチンを併用するのが望ましい。
3. パフォーマンスへの影響
`Properties`コレクションへのアクセスは非常に高速だが、ループ内で数千回呼び出すような設計は避けるべきだ。アプリケーションの起動時や設定画面を開く際など、「状態の境界線」で読み書きを行うのがベストプラクティスである。
—
4. アーキテクトからの助言
私がこの手法を導入する最大の理由は、「システムが自己完結すること」だ。
例えば、配布用フロントエンドのバージョン番号をこのプロパティに入れておけば、起動時に以下のことが可能になる。
- サーバー上のマスターDBのバージョンと比較し、強制アップデートを促す。
- 「最後に更新した開発者」のIDを埋め込み、トラブル時の追跡性を高める。
「設定データ」すらもデータベースの一部としてコードで制御する。この感覚を身につけたとき、あなたのAccess開発は「行き当たりばったりのツール作り」から「堅牢なソフトウェアエンジニアリング」へと進化するはずだ。
次は、このプロパティと、起動時の環境チェックを組み合わせた「自動アップデーター」の設計について話すとしよう。準備はいいか？
