【AccessからSQL Serverへ】移行の地雷をVBAで先制排除する「型変換自動診断エンジン」の設計思想
Access開発の現場で、ある日突然言い渡される「SQL Serverへのアップサイジング」。多くのエンジニアがここで直面するのは、移行後に発生する「謎の書き込みエラー」や「データ切り捨て」という悪夢だ。
Accessの緩やかな型定義と、SQL Serverの厳格なスキーマ。この境界線にある「非互換性」を、移行作業の最後に手動でチェックするなどは愚の骨頂である。真のエンジニアは、コードで「構造の矛盾」を強制的に可視化する。
今回は、DAOを用いてAccessのテーブル定義をスキャンし、SQL Server移行時にクラッシュするリスクを事前検知する「型変換診断エンジン」の設計と実装を伝授する。
—
1. なぜ「移行後のトラブル」は起きるのか？
最大の敗因は、Accessの「オートナンバー型」や「テキスト型（255文字）」を安易に「int」や「varchar(255)」に直結させる思考にある。
- 暗黙の型変換: Accessの「短いテキスト」は、SQL Serverでは`nvarchar`として扱うべきか、`varchar`か。照合順序（Collation）はどうするか。
- サイズ制限: Accessの`Text`型は最大255だが、SQL Serverへ移行すると`nvarchar(255)`となり、インデックスの制限に抵触することがある。
- 精度と丸め: `Currency`型の扱い。これを適切に`money`や`decimal`へ変換しないと、端数計算で致命的な誤差を生む。
これらを「目で見て直す」のはエンジニアの仕事ではない。VBAでメタデータを抽出して検証する、これが唯一の正解だ。
—
2. 【核心】DAOによるテーブル定義スキャン・エンジンの実装
以下のコードは、DAOの`TableDef`オブジェクトを走査し、SQL Serverへ移行する際に「警戒が必要なフィールド」を抽出する診断ツールだ。
Option Compare Database
Option Explicit
‘ SQL Server移行診断クラス
‘ 役割: Accessテーブル定義から潜在的なリスクを抽出する
Public Sub RunSchemaDiagnostic(strTableName As String)
Dim db As DAO.Database
Dim tdf As DAO.TableDef
Dim fld As DAO.Field
Set db = CurrentDb
Set tdf = db.TableDefs(strTableName)
Debug.Print “— 診断開始: ” & strTableName & ” —”
For Each fld In tdf.Fields
‘ 1. テキスト型の長さ制限チェック
If fld.Type = dbText Then
If fld.Size > 255 Then
Debug.Print “[警告] フィールド: ” & fld.Name & ” (サイズ: ” & fld.Size & “) -> SQL Serverではnvarchar(max)または設定見直しが必要”
End If
End If
‘ 2. 数値型の精度チェック
If fld.Type = dbDouble Or fld.Type = dbSingle Then
Debug.Print “[推奨] フィールド: ” & fld.Name & ” -> 浮動小数点型です。SQL Server移行時はdecimal型への変更を検討してください”
End If
‘ 3. オートナンバー型の扱い
If (fld.Attributes And dbAutoIncrField) = dbAutoIncrField Then
Debug.Print “[注意] フィールド: ” & fld.Name & ” -> IDENTITYプロパティへの自動変換を確認すること”
End If
Next fld
Debug.Print “— 診断完了 —”
End Sub
—
3. 設計の勘所：ここを外すと炎上する
このコードを「使えるツール」に昇華させるための、プロの視点を共有する。
A. 参照設定の罠を回避せよ
上記のコードは `Microsoft Office 16.0 Access database engine Object Library` を参照設定している前提だ。しかし、配布環境で参照切れを起こすとツールは沈黙する。可能であれば、バインディング（Late Binding）を使い、Object型で定義して実行時に関数を解決する手法へ切り替えるべきだ。
B. ログを「ファイル」に書き出せ
イミディエイトウィンドウに結果を出すのはデバッグ時のみだ。実務では、診断結果をテキストファイルや別テーブルに出力し、「いつ、誰が、どのテーブルを診断したか」というトレーサビリティを確保すること。
C. SQL Serverのデータ型対応表を保持する
コード内に直接条件を書くのではなく、変換マッピングを保持する「Mappingテーブル」を作成し、そこを参照するように設計せよ。
- 例: `AccessType` | `SqlServerType` | `RequiredAction`
- `dbText` | `nvarchar` | `チェック不要`
- `dbLong` | `int` | `IDENTITY属性付与`
—
4. 最後に：エンジニアとしての矜持
SQL Serverへの移行は単なるデータベースの引っ越しではない。「データに厳格な規律を課す」という、システムの品質向上の好機である。
VBAでこうした診断ツールを作る過程で、あなた自身の「Accessのデータ構造」に対する理解は劇的に深まるはずだ。動くものを作るのは初級者。「壊れない仕組みを自動で生成する」のが、真の業務自動化エンジニアの仕事である。
さあ、今すぐこの診断ツールを走らせ、眠っている「移行の爆弾」をすべて掘り起こしてほしい。健闘を祈る。
