リンクテーブルの動的修復：ファイルサーバー移行の悪夢をVBAで完封する極限のアーキテクチャ
社内システムの寿命は、往々にしてインフラの寿命よりも長い。
ファイルサーバーの移行、NASの刷新、あるいは部門統合に伴う共有フォルダーのパス変更。そのたびに、Accessフロントエンドを持つ業務システムの管理者たちは恐怖に震えることになる。
「パスが変わったことで、すべてのリンクテーブルが沈黙した」という絶望を。
GUIから1つずつリンクテーブルマネージャーを開き、パスを再設定する？ 20テーブルならまだいい。100を超えるテーブルが散在し、複数のバックエンド（BE）データベースに分散しているレガシーシステムにおいて、それはエンジニアがやるべき仕事ではない。
今回は、Access VBAの心臓部である `CurrentDb` と `TableDefs` オブジェクトを極限まで使い倒し、起動時にサイレントかつ完璧にリンクテーブルの接続先を検証・自動修復する堅牢な仕組みを構築する。
おまけの機能ではない。これは、数千人のユーザーを抱える現場を無停止で守り抜くための、プロフェッショナル・アーキテクチャである。
—
1. なぜ「素通しのパス再設定」では現場を救えないのか
DAO（Data Access Objects）を用いたリンクテーブルの修復自体は、VBA初級者向けの参考書にも載っている。`TableDef.Connect` プロパティを書き換え、`RefreshLink` メソッドを叩くだけだ。
‘ ありがちな素朴なコード（実運用では地雷原となる）
Dim tdf As DAO.TableDef
Set tdf = CurrentDb.TableDefs(“T_Mst_User”)
tdb.Connect = “;DATABASE=\\new-server\share\db\backend.accdb”
tdb.RefreshLink ‘ ここで例外が飛ぶリスクの塊
このアプローチが実現場で破綻する理由は明確だ。
1. ネットワーク切断や存在しないパスによるフリーズ: 移行先のパスが存在しない、あるいは名前解決に失敗した際、`RefreshLink` は容赦なくAccess全体を数秒〜数十秒ハングアップさせる。
2. オブジェクトの参照リーク: `CurrentDb` を安易に乱用し、変数の解放（`Set = Nothing`）を怠ることで、Accessの内部メモリ空間（Jet/ACEエンジン）にゴミが蓄積し、やがて「メモリ不足」エラーを引き起こす。
3. トランザクションと排他制御の無視: 他のユーザーが接続している最中にリンク情報を書き換えようとして、ODBC/ACEのエラーを踏み抜く。
我々が目指すべきは、「無音で、安全に、そして確実に自己修復する」自律型システムだ。
—
2. 設計思想：セルフヒーリング・リンクマネージャーの要件
今回のアーキテクチャで担保すべき要件は以下の3点である。
- 完全な非破壊・多重チェック: 接続先ファイルが存在するかをWindows API（またはFileSystemObject）で事前に検証してからDAOを叩く。
- メモリ・コンテキストの完全解放: `CurrentDb` はメソッド（関数）レベルでラップし、参照を即座に破棄してACEエンジンのキャッシュ肥大化を防ぐ。
- 集中管理された接続文字列: ハードコーディングを排除し、設定用テーブルまたは環境定義ファイルから「正しいバックエンドのパス」を動的に解決する。
—
3. 実装コード：堅牢な自動修復エンジン
以下のコードを、Accessフロントエンドの標準モジュール（例: `modLinkManager`）に実装する。
AutoExecマクロ、またはスタートアップフォームの `Form_Load` イベントから呼び出すことを想定している。
Option Compare Database
Option Explicit
‘ ==============================================================================
‘ モジュール名: modLinkManager
‘ 概要 : リンクテーブルの接続先を動的に検証・修復する堅牢なエンジン
‘ アーキテクト: 首席自動化エンジニア
‘ ==============================================================================
‘ 定数定義
Private Const TARGET_BE_NAME As String = “backend.accdb”
Public Sub AutoRepairLinks()
Dim db As DAO.Database
Dim tdf As DAO.TableDef
Dim fso As Object
Dim expectedPath As String
Dim repairedCount As Long
Dim errorLog As String
On Error GoTo ErrorHandler
‘ 1. 正しいバックエンドのパスを環境から解決する（例: レジストリ、INI、または特定のローカルテーブル）
expectedPath = ResolveCorrectBackendPath()
If expectedPath = “” Then
MsgBox “バックエンドデータベースのパスが特定できません。システムを終了します。”, vbCritical, “致命的エラー”
Application.Quit
Exit Sub
End If
‘ 2. ファイルシステムレベルで実体の存在を担保（ネットワークの無駄なタイムアウトを防ぐ）
Set fso = CreateObject(“Scripting.FileSystemObject”)
If Not fso.FileExists(expectedPath) Then
MsgBox “指定されたバックエンドにアクセスできません。” & vbCrLf & _
“パス: ” & expectedPath, vbCritical, “ネットワークエラー”
Exit Sub
End If
‘ 3. CurrentDbをローカル変数に閉じ込め、スコープアウト時に確実に解放する
Set db = CurrentDb()
repairedCount = 0
‘ 4. TableDefsコレクションの走査
For Each tdf In db.TableDefs
‘ リンクテーブル（SystemObjectsやローカルテーブルを除外）
If (tdf.Attributes & dbAttachedTable) = dbAttachedTable Then
‘ 現在の接続文字列と期待値が異なる場合、あるいはリンク切れを起こしている場合に修復
If Not IsConnectionValid(tdf, expectedPath) Then
If RepairSingleTable(tdf, expectedPath) Then
repairedCount = repairedCount + 1
Else
errorLog = errorLog & vbCrLf & “- ” & tdf.Name
End If
End If
End If
Next tdf
‘ 5. 結果の通知（必要に応じてログ出力に置き換え可能）
If repairedCount > 0 Then
MsgBox “インフラストラクチャの変更を検知しました。” & vbCrLf & _
repairedCount & ” 個のリンクテーブルの接続先を正常に再構築しました。”, vbInformation, “自動修復完了”
End If
CleanUp:
‘ オブジェクトの明示的解放（メモリリークの完全阻止）
Set tdf = Nothing
If Not db Is Nothing Then
db.Close
Set db = Nothing
End If
Set fso = Nothing
Exit Sub
ErrorHandler:
MsgBox “リンク修復プロセスで予期せぬエラーが発生しました。” & vbCrLf & _
“Error ” & Err.Number & “: ” & Err.Description, vbCritical, “致命的例外”
Resume CleanUp
End Sub
‘ ==============================================================================
‘ 補助関数: 個別テーブルの接続検証
‘ ==============================================================================
Private Function IsConnectionValid(tdf As DAO.TableDef, expectedPath As String) As Boolean
Dim currentConnect As String
currentConnect = tdf.Connect
‘ Connectプロパティの形式は “;DATABASE=パス” となっている
Dim expectedConnect As String
expectedConnect = “;DATABASE=” & expectedPath
If StrComp(currentConnect, expectedConnect, vbTextCompare) = 0 Then
IsConnectionValid = True
Else
IsConnectionValid = False
End If
End Function
‘ ==============================================================================
‘ 補助関数: 単一テーブルの再接続実行
‘ ==============================================================================
Private Function RepairSingleTable(tdf As DAO.TableDef, expectedPath As String) As Boolean
On Error GoTo RepairError
tdf.Connect = “;DATABASE=” & expectedPath
tdf.RefreshLink
RepairSingleTable = True
Exit Function
RepairError:
‘ 個別テーブルの失敗で全体を止めない設計
RepairSingleTable = False
Debug.Print “Failed to refresh table: ” & tdf.Name & ” | Error: ” & Err.Description
End Function
‘ ==============================================================================
‘ 補助関数: 接続先パスの動的解決ロジック
‘ ==============================================================================
Private Function ResolveCorrectBackendPath() As String
‘ 【現場に応じたカスタマイズポイント】
‘ ここでは例として、フロントエンドと同じ階層にある「Config」テーブル、
‘ またはハードコードされた絶対パス（移行先）を返す実装とする。
Dim configPath As String
‘ 例: ネットワーク上の新しい共有フォルダー
configPath = “\\new-enterprise-nas\dept_db\backend\” & TARGET_BE_NAME
‘ もしローカルのINIファイルやレジストリから読み込む場合はここに記述する
ResolveCorrectBackendPath = configPath
End Function
—
4. チーフアーキテクトが解説する「コードの急所」
① `CurrentDb` の正しいライフサイクル管理
多くのVBAプログラマが犯す最大の過ちは、モジュールレベルの変数に `CurrentDb` を代入し続けたり、あちこちで `CurrentDb.TableDefs` を直接呼び出すことだ。
`CurrentDb()` は呼び出されるたびに新しいDatabaseオブジェクトのインスタンスをメモリ上に生成する。これをループ内で回すと、JET/ACEエンジンの内部キャッシュがパンクし、パフォーマンス低下や予期せぬ動作を引き起こす。
上記のコードでは、一度変数 `db` に受けて使い切り、最後に必ず `Close` と `Set = Nothing` を明示している。これがAccessプログラミングにおける鉄則である。
② ファイルシステムの先回り検証 (`FileSystemObject`)
DAOの `RefreshLink` メソッドは、存在しないパスを与えられると、内部でタイムアウトを起こすまでスレッドをブロックする。
VBAから直接ネットワークパスを叩く前に、`Scripting.FileSystemObject` の `FileExists` でOSレベルの存在確認を挟むことで、ネットワーク遅延やルーティング異常によるAccessの「フリーズ（無応答）」を完全に回避している。
③ 部分的障害への耐性（Fault Tolerance）
100個のテーブルのうち、1個だけスキーマが壊れている、あるいは排他ロックがかかっているという理由でシステム全体の起動が失敗してはならない。
`RepairSingleTable` 関数に独自の `On Error GoTo` を閉じ込め、「個別のテーブル更新に失敗しても、他のテーブルの修復を継続し、ログを残す」というエンタープライズグレードの耐障害性を実装している。
—
5. 運用への組み込みと最終提言
このモジュールを組み込んだ後、やるべきことはただ一つ。
Accessフロントエンドの最初に読み込まれるフォーム（あるいはAutoExecマクロ）の最前線に、以下の1行を置くだけだ。
‘ 起動時イベントの最優先実行
Call AutoRepairLinks
ファイルサーバーの移行という、インフラ担当者の勝手な都合にシステムが振り回される時代は終わった。
コードは環境の変化を自ら察知し、静かに、しかし強力に自己を修復する。これこそが、レガシー環境の限界を突破するシニアエンジニアの技術力である。明日からの運用負荷を、コードの力でゼロに叩き落としてほしい。
