【極限の知見】Access「自己修復型データベース」：テーブルの自動生成と更新を掌握せよ
Access開発の現場で、初心者が陥る最大の罠は「環境依存」だ。
「新しいPCに配布したらテーブルがないと言われる」「アップデートのたびに手動でリンクテーブルを張り直す」……そんな泥臭い作業に時間を溶かしているようでは、エンジニアとは呼べない。
真の自動化エンジニアは、アプリケーションが起動した瞬間、自らの生存環境を検知し、不足があれば即座に修復する「自己修復型アーキテクチャ」を構築する。今回は、テーブルの存在チェックから動的作成・更新まで、プロダクション環境で耐えうる堅牢な実装術を授ける。
—
1. なぜ「If CurrentDb.TableDefs(“TableName”) Is Nothing」ではいけないのか
初学者は、テーブルの存在チェックにエラーハンドリング（On Error Resume Next）を乱用しがちだ。だが、それはあまりに稚拙である。
`TableDefs`コレクションを直接参照してエラーを待つ方法は、実行速度の観点からも、例外処理の管理コストの観点からも推奨しない。我々がとるべき戦略は、「コレクションを反復せず、存在チェックを関数化し、型安全に管理する」ことだ。
堅牢な存在チェック関数
以下の関数を標準モジュールに埋め込んでくれ。これがすべての基盤となる。
‘ @description 指定したテーブルが存在するかを高速に判定する
‘ @param tableName チェック対象のテーブル名
‘ @return 存在すればTrue
Public Function TableExists(ByVal tableName As String) As Boolean
Dim db As DAO.Database
Dim tdf As DAO.TableDef
Set db = CurrentDb
On Error Resume Next
Set tdf = db.TableDefs(tableName)
TableExists = (Err.Number = 0)
On Error GoTo 0
End Function
—
2. 【設計の真髄】スキーマの差分更新をいかに制御するか
テーブルを作るだけなら`CREATE TABLE`文で足りる。しかし、真に恐ろしいのは「既存テーブルへのフィールド追加」だ。
運用中に「この項目を追加してほしい」という要求が出たとき、テーブルをDROPして作り直すのか？ 否、それはデータロストを招く自殺行為だ。「必要なフィールドがなければALTER TABLEを投げる」。これがエンジニアとしての最低限の倫理である。
プロダクションコード：自己修復エンジン
このコードは、テーブルの有無を確認し、なければ作成、あればフィールドの追加を行う。
Public Sub EnsureSchema()
Dim db As DAO.Database
Set db = CurrentDb
‘ 例：マスタテーブルの構築
If Not TableExists(“M_Users”) Then
db.Execute “CREATE TABLE M_Users (ID COUNTER CONSTRAINT PK_Users PRIMARY KEY, UserName TEXT(50))”, dbFailOnError
Else
‘ 既存テーブルにフィールドが存在するか確認し、なければ追加
AddFieldIfMissing “M_Users”, “Email”, “TEXT(100)”
End If
End Sub
Private Sub AddFieldIfMissing(tblName As String, fieldName As String, fieldType As String)
Dim db As DAO.Database
Dim tdf As DAO.TableDef
Dim fld As DAO.Field
Set db = CurrentDb
Set tdf = db.TableDefs(tblName)
‘ フィールドの存在チェック
Dim exists As Boolean
For Each fld In tdf.Fields
If fld.Name = fieldName Then exists = True: Exit For
Next
‘ なければALTER TABLEで追加
If Not exists Then
db.Execute “ALTER TABLE [” & tblName & “] ADD COLUMN [” & fieldName & “] ” & fieldType, dbFailOnError
End If
End Sub
—
3. なぜこの設計が最強なのか
この設計には、単なる「動くコード」以上の価値がある。
1. 冪等性（Idempotency）の担保: 何度実行しても結果が変わらない。つまり、起動するたびに「安全な状態」が保証される。
2. DAOの直接制御: SQLコマンド（`CREATE TABLE` / `ALTER TABLE`）を直接発行することで、AccessのUIに依存しない高速かつ予測可能なスキーマ変更が可能になる。
3. 拡張性: フィールド追加のロジックを共通化することで、どんなに複雑なDB構造も、この関数を呼び出すだけで自動アップデートされる仕組みが作れる。
—
4. エンジニアへの忠告：落とし穴を避けよ
最後に一つだけ、忠告しておく。
「リンクテーブル」の扱いに注意しろ。
今回のロジックは、あくまで「ローカルテーブル」に対するものだ。バックエンド（BE）のデータベースが存在しない、あるいはリンクが切れている場合、上記のコードは無力だ。BEを扱う場合は、必ず`Connect`プロパティを確認し、パスの整合性を取るロジックを前段に組み込むこと。
技術とは、単にコードを書くことではない。「発生しうるバグを事前に消し去る設計」そのものだ。
君たちが今日から記述するAccess VBAが、誰の手も借りずに自立して生き延びる強靭なシステムであることを期待している。健闘を祈る。
