Accessの深淵：DAO TableDefによる「動的一時テーブル」の極致
Accessにおけるデータ処理の限界は、往々にして「クエリの複雑化」によって訪れる。何重にもネストされたサブクエリ、あるいは巨大な中間テーブルの残留。これらが引き起こすパフォーマンスの劣化と断片化は、Accessエンジニアにとって避けては通れない業だ。
真に堅牢なシステムを構築するアーキテクトは、SQLの海に溺れることを良しとしない。必要な時に、必要なメモリと領域を確保し、使命を終えれば跡形もなく消し去る。「動的一時テーブルの完全ライフサイクル管理」こそ、大規模Accessシステムの生命線である。
今回は、DAO `TableDef` を駆使し、実行時に動的にテーブルを生成・破棄する、極めて「クリーン」な設計パターンを伝授する。
—
1. なぜ「一時テーブル」なのか？
`SELECT INTO` や「テーブル作成クエリ」を場当たり的に使うのは素人の所業だ。それらはシステムテーブルにゴミを残し、データベースを肥大化させ、最終的には `MDB/ACCDB` の破損を招く。
我々が求めるのは、以下の要件を満たす実装である。
- アトミックな生成: 同時実行時の衝突を回避する一意な名称管理。
- 確実な破棄: エラー発生時であっても確実に削除されるトランザクション的安全性。
- 低負荷: インデックス構築を動的に制御し、物理的なIOを最小化する。
—
2. 実装パターン：`TemporaryTable` クラスの設計
DAOのオブジェクトは、スコープを抜ければ自動でクリーンアップされると信じてはならない。特に `TableDef` や `Index` の解放は、明示的な `Close` と `Nothing` への代入が鉄則だ。
以下に、再利用可能なテンプレートを示す。
Option Compare Database
Option Explicit
‘ — 一時テーブル管理クラス：TempTableManager —
‘ 実行時に一時的なデータストアを構築し、確実に破棄する
Public Sub ExecuteTempProcessing()
Dim db As DAO.Database
Dim td As DAO.TableDef
Dim tableName As String
Set db = CurrentDb
tableName = “tmp_” & Format(Now, “yyyymmdd_hhnnss”) & “_” & GetTickCount()
‘ 1. テーブル作成
Set td = db.CreateTableDef(tableName)
‘ フィールド定義（IDとインデックスを付与）
td.Fields.Append td.CreateField(“RecordID”, dbLong)
td.Fields.Append td.CreateField(“DataPayload”, dbText, 255)
db.TableDefs.Append td
‘ 2. インデックス付与（パフォーマンスの要）
Dim idx As DAO.Index
Set idx = td.CreateIndex(“PrimaryKey”)
idx.Primary = True
idx.Fields.Append idx.CreateField(“RecordID”)
td.Indexes.Append idx
On Error GoTo Cleanup
‘ — ここに複雑な処理（DAOレコードセット等）を記述 —
‘ 3. 処理完了後、確実にクリーンアップ
Cleanup:
If Not td Is Nothing Then
db.TableDefs.Delete tableName
db.TableDefs.Refresh
End If
Set idx = Nothing
Set td = Nothing
Set db = Nothing
If Err.Number <> 0 Then MsgBox “Error: ” & Err.Description
End Sub
‘ Windows APIでミリ秒単位の一意性を担保
If VBA7 Then
Private Declare PtrSafe Function GetTickCount Lib “kernel32” () As Long
Else
Private Declare Function GetTickCount Lib “kernel32” () As Long
End If
—
3. シニアエンジニアが押さえるべき「極限の知見」
1. `Refresh` メソッドの呪縛
`TableDefs.Append` や `Delete` を実行した後、`db.TableDefs.Refresh` を呼び出さなければ、その変更はデータベースエンジンに即座に反映されない。特にフロントエンドからバックエンドリンクテーブルを制御する場合、このRefreshを怠ると「テーブルが見つかりません」という不可解なエラーに遭遇する。
2. インデックスの動的制御
大規模データを扱う際、一時テーブル作成後にデータを流し込み、最後にインデックスを張るのが定石だ。データを挿入するたびにインデックスが再構築されるコストは無視できない。`TableDef` による動的なインデックス追加は、このコストを劇的に削減する。
3. メモリ解放の作法
`Nothing` を代入するだけではメモリリークは防げない。`TableDef` や `QueryDef` は、親となる `Database` オブジェクトが閉じられるまでメモリに残留しやすい。明示的に `Delete` を呼び出し、DAOのコレクションからオブジェクトを「物理的に抹消」させる意識が重要である。
—
結びに代えて
Accessはレガシーと言われるが、それは使い手の習熟度不足を露呈しているに過ぎない。DAOを自在に操り、データベースのライフサイクルを制御下に置くことができれば、Accessは今なお、最速のプロトタイピング環境であり、堅牢な業務基盤であり続ける。
「とりあえずテーブルを作る」のではなく、「システムの状態を設計する」。この視点こそが、凡百のエンジニアと、伝説のアーキテクトを分かつ境界線である。
次回の稿では、さらに踏み込んで `ADO` を用いた非同期処理と、Access/SQL Serverハイブリッド環境における一時テーブルの最適解を紐解く。期待していてほしい。
