Access VBAの深淵へ：TableDefを掌握し、データベース構造を「可視化」する技術
現場で「このデータベース、誰が作ったのか分からないが、特定のデータ型を使っているフィールドがどこにあるか知りたい」という状況に陥ったことはないだろうか。
AccessのGUI操作だけで構造を解析するのは、愚の骨頂だ。DAO（Data Access Objects）を使えば、データベースの心臓部であるメタデータをVBAで直接操作できる。今回は、単に動くだけのコードではなく、プロの現場で通用する「堅牢なメタデータ解析ツール」の設計思想を伝授する。
—
なぜ「DAO」を使うのか？
初心者はしばしば「クエリ」や「DoCmd」に頼るが、データ構造（スキーマ）を扱うならDAO一択だ。DAOはAccessエンジンの最深部に直接アクセスするため、オーバーヘッドが極めて少なく、かつテーブルの隠しプロパティまで自在に叩けるからだ。
守るべき設計の鉄則
本ツールを作る上で、以下の3点を意識してほしい。
1. システムテーブルの除外: `MSys`で始まるテーブルを不用意に触ると、データベースの整合性を壊すリスクがある。必ず無視するロジックを組み込むこと。
2. DAOの参照設定: `Microsoft Office 16.0 Access database engine Object Library` を必ず参照設定に追加せよ。遅延バインディングはデバッグ効率を著しく下げるため、プロの現場では推奨しない。
3. プロパティの列挙: `Field` オブジェクトの `.Type` プロパティは列挙型で返る。これを「数値」のまま放置せず、人間が読める「型名」に変換するラッパー関数を挟むのが保守の秘訣だ。
—
実装：フィールド解析エンジンのプロダクションコード
以下のコードを標準モジュールに貼り付ければ、即座に全テーブルの特定の型を持つフィールドがリストアップされる。
Option Explicit
‘ 目的: 指定したデータ型のフィールドを全テーブルから抽出する
‘ 注意: 事前に参照設定で DAO ライブラリを追加してください
Public Sub ListSpecificFields(ByVal targetDataType As DataTypeEnum)
Dim db As DAO.Database
Dim td As DAO.TableDef
Dim fld As DAO.Field
Set db = CurrentDb
Debug.Print “— 解析開始: ” & Now & ” —”
‘ 全テーブルを走査
For Each td In db.TableDefs
‘ システムテーブルは解析対象外（堅牢性の担保）
If Left(td.Name, 4) <> “MSys” Then
‘ テーブル内の全フィールドを走査
For Each fld In td.Fields
‘ 指定した型と一致するか判定
If fld.Type = targetDataType Then
Debug.Print “Table: ” & td.Name & _
” | Field: ” & fld.Name & _
” | Type: ” & GetTypeName(fld.Type) & _
” | Size: ” & fld.Size
End If
Next fld
End If
Next td
Debug.Print “— 解析終了 —”
‘ メモリ解放の徹底（VBAにおけるリーク防止）
Set fld = Nothing
Set td = Nothing
Set db = Nothing
End Sub
‘ データ型定数を文字列に変換するヘルパー関数
Private Function GetTypeName(dataType As DataTypeEnum) As String
Select Case dataType
Case dbDate: GetTypeName = “日付型”
Case dbText: GetTypeName = “テキスト型”
Case dbLong: GetTypeName = “長整数型”
Case dbDouble: GetTypeName = “倍精度浮動小数点型”
Case Else: GetTypeName = “その他(” & dataType & “)”
End Select
End Function
—
このコードを「使いこなす」ために
このツールをイミディエイトウィンドウで実行する際は、次のように呼び出す。
‘ 日付型(dbDate)を持つフィールドを探す場合
Call ListSpecificFields(dbDate)
なぜこの書き方なのか？
- `Set` の明示的解放: Access VBAはガベージコレクションが強力ではない。特に大規模なDBを解析する際、オブジェクト変数を放置するとメモリリークの原因になる。`Set = Nothing` はおまじないではなく、設計者の責任だ。
- 抽象化: `GetTypeName` 関数を分離することで、今後「通貨型（dbCurrency）」や「バイナリ型（dbLongBinary）」を解析対象に加えたくなった際、メインロジックを汚さずに拡張が可能だ。
最後に
開発者諸君。Accessにおいて「テーブル構造を知る」ことは、データベースの健康状態を知ることと同義だ。
今回提示したコードをベースに、必要であれば `fld.Properties(“Description”)` を取得してフィールド説明文まで表示するように改造してみるといい。そうやってツールを育てていく過程こそが、真の自動化エンジニアへの近道となる。
何かあれば、またこの現場に戻ってくるといい。君たちのコードレビューをいつでも待っている。
