移行の墓場を回避せよ：AccessからSQL Serverへ「データ型」を完全攻略するメタプログラミング
AccessからSQL Serverへのアップサイジング。多くのエンジニアがここで「データ型不一致」という名の地雷原に足を踏み入れ、移行後に発生する謎のTruncationエラーやパフォーマンス劣化に絶望する。
なぜ失敗するのか。それは「Access上のデータ型」を「SQL Serverの型」へ、場当たり的に読み替えているからだ。本質は、データベース定義という静的なデータを、VBAによるメタプログラミングで動的に解釈し、検証するアーキテクチャにある。
今日は、DAOの`TableDef`を極限まで使い倒し、移行前にリスクを排除する「完全自動検証ツール」の設計思想を伝授する。
—
1. DAOオブジェクトのライフサイクルとメモリ管理の鉄則
Accessの`TableDef`や`Field`オブジェクトは、COMのラッパーである。安易なループで生成し、`Nothing`を忘れるコードは、数万フィールドある大規模システムでは確実にメモリリークとパフォーマンス低下を招く。
鉄則:
- `CurrentDb`を安易に何度も呼び出さない。必ず変数に格納し、参照を維持せよ。
- `For Each`での走査後は、必ずオブジェクト変数を`Nothing`に倒せ。
- 巨大なデータベースを扱う際、Schema情報は一度構造体配列にキャッシュしてから処理する。
—
2. 移行検証ツールの核心：データ型変換マッピングエンジン
単なるif文の羅列は保守性を殺す。型変換ルールをDictionaryオブジェクトで管理し、動的に検証を行うエンジンを構築する。
‘ SQL Server移行検証エンジン
Option Explicit
Private Type TypeMapping
AccessType As Integer
SQLType As String
MaxLength As Long
End Type
‘ 移行後の型定義と制限を管理するハッシュ
Private Function GetMapping() As Object
Dim dict As Object
Set dict = CreateObject(“Scripting.Dictionary”)
‘ 例: dbText -> NVARCHAR(255)
dict.Add 10, “NVARCHAR(255)”
‘ 例: dbMemo -> NVARCHAR(MAX)
dict.Add 12, “NVARCHAR(MAX)”
Set GetMapping = dict
End Function
—
3. 実践：TableDefを走査し、不整合を炙り出す
以下は、フィールド定義を走査し、SQL Server移行時に「桁数オーバー」や「互換性欠如」を検知するプロシージャの心臓部だ。
Public Sub AnalyzeTableSchema(ByVal targetTable As String)
Dim db As DAO.Database
Dim td As DAO.TableDef
Dim fld As DAO.Field
Dim mapping As Object
Set db = CurrentDb
Set td = db.TableDefs(targetTable)
Set mapping = GetMapping()
Debug.Print “— 移行検証開始: ” & targetTable & ” —”
For Each fld In td.Fields
‘ 隠しフィールドやシステムオブジェクトを除外するフィルタリング
If (fld.Attributes And dbSystemObject) = 0 Then
‘ 型変換ロジック
If mapping.Exists(fld.Type) Then
‘ ここでフィールドサイズや精度をチェック
‘ 必要な場合、Windows APIで詳細なデータバッファを確認する等の高度な処理を挟む
Debug.Print “Field: ” & fld.Name & ” -> Mapping: ” & mapping(fld.Type)
Else
Debug.Print “CRITICAL: 未対応のデータ型 [” & fld.Type & “] を発見しました: ” & fld.Name
End If
End If
Next fld
‘ メモリ解放の徹底
Set fld = Nothing
Set td = Nothing
Set db = Nothing
Set mapping = Nothing
End Sub
—
4. 上級者への問い：Windows APIとパフォーマンスの境界線
もし、数千のテーブルを数秒で解析する必要があるなら、DAOの`TableDef`だけでは力不足だ。その場合、`syscolumns`や`systypes`を直接ADOで叩くか、あるいはWindows APIの`GetPrivateProfileString`等を利用して外部定義ファイルとの整合性を取るアプローチが有効になる。
さらに、システム間連携を考えるなら、SQL Server側の`sp_help`の結果をVBAで受け取り、差分抽出（Diff）を行うのが最も堅牢だ。
成功の秘訣は「メタデータの抽象化」にある
AccessのVBAを単なる「マクロ作成ツール」と見なすな。VBAは、Accessという巨大なデータベース・エンジンを操作するための「強力なメタプログラミング言語」である。
- データ型はハードコーディングせず、外部の設定ファイル（JSON/XML）から読み込め。
- 検証ログはテーブルに出力し、クエリでいつでも再確認できるようにせよ。
- 「動くコード」で満足せず、「検証可能なコード」を残せ。
移行の現場では、情熱よりも「構造への理解」が勝つ。このスクリプトをベースに、貴殿の環境に最適化された検証ツールを構築してほしい。健闘を祈る。
