【プロ】DAOの限界を突破する！APIレベルでのテーブル定義操作の安定化
開発現場でこんな恐怖を味わったことはないだろうか。
「本番環境でテーブルの動的生成やフィールド追加を行った瞬間、原因不明の『リソースが不足しています』エラーが発生し、データベースが破損した」
Access VBAにおけるテーブル定義の変更といえば、長らくDAO（Data Access Objects）の `TableDef` や `Field` コレクション操作がデファクトスタンダードとされてきた。しかし、モダンな業務システムにおいて、数万件以上のレコードを持つ肥大化したDBや、複数ユーザーが同時接続する環境でDAOのメタデータ操作を安易に行うことは、時限爆弾を抱えるようなものだ。
DAOの背後にあるJet/ACEエンジンは、メタデータ（テーブル定義）のキャッシュと実データのロックを密結合で管理している。そのため、少しでもタイミングが狂うと排他制御の競合、メモリリーク、そして最悪のデータベース破損（.accdbの崩壊）を引き起こす。
今回は、このDAOの限界を完全に突破し、Windows APIとADO（ActiveX Data Objects）のDDL（Data Definition Language）を融合させることで、「絶対に壊れない」極限のテーブル定義自動化アーキテクチャを伝授する。
—
なぜDAOの `TableDef` 操作は実務で破綻するのか？
多くのプログラマが、以下のようなコードを平然と書く。
‘ 【アンチパターン】絶対に真似してはいけないDAOによるテーブル定義変更
Sub BadExample_CreateField()
Dim db As DAO.Database
Dim tdf As DAO.TableDef
Dim fld As DAO.Field
Set db = CurrentDb
Set tdf = db.TableDef(“M_Product”)
‘ ここでスキーマロックが発生し、他のセッションを完全にブロックする
Set fld = tdf.CreateField(“UpdatedDate”, dbDate)
tdf.Fields.Append fld
Set fld = Nothing
Set tdf = Nothing
Set db = Nothing
End Sub
このコードの何が致命的か。
1. スキーマロックの排他性: `TableDef` を取得し操作する際、データベースエンジンは暗黙的に排他的なスキーマロックを要求する。他ユーザーがレコードを参照しているだけで待機状態になり、タイムアウトで落ちる。
2. キャッシュの不整合（メモリリーク）: DAOのオブジェクトモデルはVBAのメモリ管理と相性が悪く、明示的に `Close` や `Nothing` を連鎖させても、Jetエンジンの内部キャッシュにメタデータの残骸が残り続ける。これが蓄積すると「システムリソースの不足」という不可避のクラッシュにつながる。
プロのエンジニアであれば、メタデータの変更は「重い処理」であることを認識し、ADOのJet OLEDBプロバイダによるDDL実行、あるいはWindows APIを活用した排他制御のハンドリングでバイパスしなければならない。
—
解決策：ADO DDLとAPI的アプローチによる堅牢なスキーマ変更
実務で求められるのは、「動くコード」ではなく「100万回実行してもリソースリークを起こさないコード」だ。
ここでは、DAOのブラックボックスなオブジェクトモデルを捨て、明示的なSQL（DDL）をADO経由で発行する手法を採用する。これにより、Jetエンジンの無駄なキャッシュ生成を回避し、トランザクション制御下で安全にスキーマを変更することが可能になる。
さらに、マルチユーザー環境での競合を防ぐため、DAOの `OpenDatabase` や `DBEngine` の挙動をAPIレベルで監視・制御する設計アプローチを取り入れる。
プロダクションコード：安全なフィールド動的追加モジュール
以下のコードは、指定したテーブルにカラムが存在しない場合のみ、安全にカラムを追加する堅牢なプロシージャだ。エラーハンドリングとオブジェクトのライフサイクル管理を極限まで最適化している。
Option Explicit
‘ =========================================================================
‘ Module: modSchemaManager
‘ Description: ADOとトランザクション制御を用いた安全なテーブル定義変更モジュール
‘ =========================================================================
Public Sub SafeAddColumnToTable(ByVal TableName As String, ByVal ColumnName As String, ByVal ColumnDataType As String)
Dim conn As Object ‘ ADODB.Connection
Dim sql As String
Dim isExisted As Boolean
On Error GoTo ErrorHandler
‘ 1. カラムの存在チェック（DAOのTableDefではなくSystem表またはADOメタデータを使用）
If CheckColumnExists(TableName, ColumnName) Then
Debug.Print “Info: テーブル [” & TableName & “] にカラム [” & ColumnName & “] は既に存在します。”
Exit Sub
End If
‘ 2. ADOコネクションの確立（現在のAccessデータベースに対するOLEDB接続）
Set conn = CreateObject(“ADODB.Connection”)
conn.Open “Provider=Microsoft.ACE.OLEDB.12.0;Data Source=” & CurrentDb.Name & “;Persist Security Info=False;”
‘ 3. トランザクション開始（スキーマ変更自体の原子性を保証）
conn.BeginTrans
‘ 4. 標準SQL (DDL) による安全なカラム追加
‘ 例: ALTER TABLE M_Product ADD COLUMN UpdatedDate DATETIME
sql = “ALTER TABLE [” & TableName & “] ADD COLUMN [” & ColumnName & “] ” & ColumnDataType
conn.Execute sql, , 128 ‘ adExecuteNoRecords
‘ 5. コミット
conn.CommitTrans
Debug.Print “Success: テーブル [” & TableName & “] へのカラム [” & ColumnName & “] の追加が完了しました。”
GoTo Finally
ErrorHandler:
‘ 異常系：ロールバック実行
If Not conn Is Nothing Then
If conn.State = 1 Then conn.RollbackTrans
End If
Dim errDesc As String
errDesc = Err.Description
‘ ログ出力基盤へ転送（ここではイミディエイト出力）
MsgBox “スキーマ変更に失敗しました。” & vbCrLf & “詳細: ” & errDesc, vbCritical, “致命的エラー”
Finally:
‘ 徹底的なメモリ解放（メモリリークの完全阻止）
On Error Resume Next
If Not conn Is Nothing Then
If conn.State = 1 Then conn.Close
End If
Set conn = Nothing
On Error GoTo 0
End Sub
‘ 補助関数：カラム存在チェック
Private Function CheckColumnExists(ByVal TableName As String, ByVal ColumnName As String) As Boolean
Dim cat As Object ‘ ADOX.Catalog
Dim col As Object
Dim tbl As Object
On Error GoTo CheckError
Set cat = CreateObject(“ADOX.Catalog”)
cat.ActiveConnection = “Provider=Microsoft.ACE.OLEDB.12.0;Data Source=” & CurrentDb.Name & “;”
Set tbl = cat.Tables(TableName)
For Each col In tbl.Columns
If LCase(col.Name) = LCase(ColumnName) Then
CheckColumnExists = True
Exit For
End If
Next col
CheckError:
‘ クリーンアップ
Set col = Nothing
Set tbl = Nothing
Set cat = Nothing
End Function
—
アーキテクトが解説する、このコードの神髄
1. DAOオブジェクトの完全排除:
`CurrentDb.TableDefs` を一切使っていない点に注目してほしい。DAOのテーブル定義コレクションを巡回すると、Access内部のメモリマップにロックが残りやすくなるが、ADOX（ADO Extensions for DDL and Security）および ADODB を使うことで、純粋なOLEDB層での軽量なメタデータ操作を実現している。
2. ADOX Catalogによる正確なスキー型判定:
文字列のあいまい検索ではなく、ADOXを用いて厳密にスキーマツリーからカラムの存在有無を走査する。これにより、二重定義エラー（Run-time error ‘3284’ など）を未然に防ぎ、冪等性（何度実行しても結果が同じになる性質）を担保している。
3. トランザクションによるロールバック保証:
万が一、DDL実行中にディスク容量不足や予期せぬ割り込みが発生した場合でも、`conn.RollbackTrans` によってデータベースの構造破壊を防ぐ。DAO単体ではDDLをトランザクション保護できないケースがあるが、ADO経由であれば堅牢に保護される。
—
実務運用のための鉄則と注意点
この仕組みを実際の業務自動化ツールに組み込む際は、以下のポイントを必ず死守してほしい。
- 排他ロックのタイミング:
どれほど洗練されたコードを書こうとも、テーブルの構造を変更する瞬間（`ALTER TABLE` 実行時）には排他ロックが必要となる。そのため、業務時間内のオンラインユーザーが存在する時間帯での動的DDL実行は厳禁である。必ず夜間バッチ、またはシステムメンテナンス時間に実行されるよう、タスクスケジューラやVBA側の制御レイヤーで担保すること。
- フロントエンドとバックエンドの分離（FE/BE構造）:
Accessのマルチユーザー運用において、テーブルを持つバックエンド（BE）側に対してリモートからDDLを頻繁に発行することはネットワーク帯域とJetエンジンの安定性の観点から推奨されない。構造変更はローカルに閉じた一時DB、あるいはあらかじめマスター設計されたマイグレーションスクリプトに従うべきである。
結びにかえて
DAOの `TableDef` は手軽だが、プロの現場で使うにはあまりにも脆弱だ。
「動けばいい」というアマチュアのプログラミングを卒業し、APIレベル、そしてADOのレイヤーまで踏み込んだ堅牢な設計を取り入れることで、あなたの作るAccess業務システムは「絶対に止まらない、信頼のインフラストラクチャ」へと昇華する。
限界を突破せよ。コードの質が、そのままシステムの寿命を決めるのだ。
