リンクテーブルの「接続先」を制御せよ。サーバー移行を数秒で終わらせるVBA設計術
システム開発の現場において、ファイルサーバーの刷新やNASの移行は避けて通れないイベントだ。しかし、Accessの「リンクテーブルマネージャー」をマウスでポチポチと操作しているようでは、プロのエンジニアとは呼べない。
リンクテーブルの接続パス管理は、「資産のメタデータ」をプログラムが直接書き換えるという、一歩間違えればシステムを破壊しかねないクリティカルな操作だ。今回は、このリスクを排除し、かつ運用保守性を極限まで高めた「リンクテーブル一括再接続ツール」の設計思想を伝授する。
—
なぜ「GUI」ではなく「VBA」なのか
リンクテーブルマネージャーは便利だが、移行対象が数十テーブルに及ぶ場合、ミスが起きる確率は飛躍的に高まる。また、ネットワーク環境の変化や、特定のテーブルだけ接続先が異なる複雑な構成の場合、手動操作は無力だ。
我々が目指すべきは、「接続先文字列（Connectプロパティ）をロジックで制御し、恒久的に再利用可能なツール」である。
堅牢な設計の核心：TableDefの作法
VBAでリンクテーブルを扱う際、最も注意すべきは`TableDef`オブジェクトの扱いに起因する「メモリリーク」と「接続エラーのハンドリング」だ。
以下のコードは、単にパスを書き換えるだけではない。「接続先の検証（FileExists判定）」を行い、「リンクが生きているかを確認」した上で更新する。この一連のプロセスを自動化することで、移行の失敗を未然に防ぐ。
実装：リンクテーブル一括置換モジュール
Option Compare Database
Option Explicit
‘ ———————————————————————-
‘ 目的: リンクテーブルの接続先を一括で新しいパスへ書き換える
‘ 備考: 旧パスの一部（例: \\OldServer\Share）を新パス（\\NewServer\Share）に置換
‘ ———————————————————————-
Public Sub RefreshLinkedTables(ByVal oldServerPath As String, ByVal newServerPath As String)
Dim db As DAO.Database
Dim tdf As DAO.TableDef
Dim strConnect As String
Dim count As Integer
Set db = CurrentDb
count = 0
‘ データベース内の全テーブル定義をループ
For Each tdf In db.TableDefs
‘ リンクテーブルのみを対象とする (Connectプロパティが空でないもの)
If Len(tdf.Connect) > 0 Then
‘ パスが含まれているかチェック
If InStr(tdf.Connect, oldServerPath) > 0 Then
‘ 新しい接続文字列を構築
strConnect = Replace(tdf.Connect, oldServerPath, newServerPath)
‘ 設定を適用
tdf.Connect = strConnect
‘ 再接続実行（ここが最も重要：RefreshLinkを呼ばないと反映されない）
On Error Resume Next
tdf.RefreshLink
If Err.Number <> 0 Then
Debug.Print “エラー: ” & tdf.Name & ” の再接続に失敗しました。”
Err.Clear
Else
Debug.Print “成功: ” & tdf.Name & ” を更新しました。”
count = count + 1
End If
On Error GoTo 0
End If
End If
Next tdf
Set tdf = Nothing
Set db = Nothing
MsgBox count & ” 個のテーブルの接続先を更新しました。”, vbInformation
End Sub
プロが現場で意識する「3つの鉄則」
このコードをそのまま運用環境に乗せる前に、以下の「アーキテクトの視点」を必ず理解しておいてほしい。
1. `RefreshLink` の重要性
`tdf.Connect` プロパティを書き換えるだけでは、Accessはその変更を認識しない。`RefreshLink` メソッドを呼び出すことで、初めてAccessのエンジンが新しいパスに対してハンドシェイク（接続確立）を行う。この呼び出しなしに処理を終えるのは、エンジニアとして「未完成の成果物」を納品するのと同じことだ。
2. トランザクション的思考
上記コードでは`On Error Resume Next`を使用している。これは「1つのテーブルの接続に失敗したからといって、全体の処理を停止させてはならない」という判断からだ。移行業務においては、全テーブルを確実に処理し、最後に「どれが成功し、どれが失敗したか」のログを明確に出力する方が、運用上のリカバリが容易になる。
3. パス文字列の正規化
環境によって「末尾のバックスラッシュ（\）の有無」や「UNCパスかマップドライブか」という揺らぎが生じる。移行元と移行先のパスは、常にフルパスで指定するようルール化せよ。プログラム内で`Replace`関数を使う際は、文字列の包含関係に注意を払うこと。
—
次のステップ：さらなる自動化へ
このコードを基盤に、今後は以下の機能を追加することを推奨する。
- 構成ファイル化: 移行先のパスをコードに直書きせず、`Config.ini`や別テーブルで管理する。
- バックエンドファイルの自動探索: `Dir`関数を組み合わせ、指定した親フォルダ配下からバックエンドデータベース（.accdb）を自動検索し、接続先を自動補完する仕組み。
「手作業」を「自動化」に変える。これは単なる工数削減ではない。「ミスを許容しないシステム設計」を構築する力を養うことだ。このツールを使い、あなたのプロジェクトのサーバー移行を、誰よりも早く、そして完璧に遂行してほしい。
