【Access VBA極限の知見】ファイルサーバー移動に屈しない！起動時リンクテーブル自動修復アーキテクチャ
開発現場でシステムを納品した後、決まって耳にする悪夢のようなセリフがある。
「すいません、総務部のファイルサーバーの共有フォルダ名が変わったので、Accessが動きません」
この一言で、あなたは全クライアント端末のリンクマネージャを叩き直す作業に追われることになる。バックエンドのデータ実体（SQL Serverや別Accessファイル）のパスが変わるたびに、手動でリンクを貼り直すなどという前時代的な運用は、今この瞬間で終わりにしよう。
今回は、Access VBAのオブジェクトモデルを骨の髄まで理解したアーキテクトだけが知る、「起動時にリンクテーブルの接続先を動的に検知・修復する堅牢な自動修復システム」の全貌を伝授する。
—
1. なぜ従来のリンク切れは「面倒」なのか？
Accessのリンクテーブル機能は強力だが、裏側の仕組みを理解していないと致命的な罠に嵌まる。
Accessは、リンクテーブルの接続情報を内部の `TableDefs` コレクションに保持している。ここにハードコーディングされたパス（例: `\\old-server\data\backend.accdb`）が刻み込まれており、ファイルサーバーの移行やIPアドレスの変更が発生した途端、すべてのクエリやフォームが沈黙する。
ここで初心者がやりがちなのが、エラーハンドラーでメッセージを出し、ユーザーに手動でリンクマネージャを開かせるという悪手だ。実務において、エンドユーザーにインフラの変更を意識させてはならない。「アプリが勝手に気づき、勝手に直す」。これがプロのエンジニアリングである。
—
2. 堅牢な自動修復設計のコア思想
今回構築するアーキテクチャの要件は以下の3点だ。
1. 一瞬での接続判定: 起動時の `AutoExec` マクロまたはスタートアップフォームの最早期（`Open` イベント）でチェック走査を行う。
2. メタデータ駆動: 接続先の「正しいパス」をハードコーディングせず、ローカルテーブル（または外部設定ファイル）から動的に取得する。
3. トランザクショナルな更新: `TableDef.Connect` プロパティの書き換えと `RefreshLink` メソッドを安全に実行し、失敗時のロールバック（エラーハンドリング）を完備する。
—
3. プロダクションコード：起動時自動修復モジュール
以下のコードを、フロントエンド側のアダプターモジュール（例: `modLinkRepair`）として実装せよ。
Option Compare Database
Option Explicit
‘ ==============================================================================
‘ モジュール名: modLinkRepair
‘ 概要: 起動時にリンクテーブルの接続先パスを動的に検証・修復する
‘ ==============================================================================
Public Sub AutoRepairLinkTables()
Dim db As DAO.Database
Dim tdf As DAO.TableDef
Dim strNewPath As String
Dim intErrorCount As Integer
On Error GoTo ErrorHandler
Set db = CurrentDb
‘ 1. マスタデータや設定テーブルから「正しいバックエンドのパス」を取得する
‘ ※今回は例として、ローカルの「T_SystemConfig」から取得するロジックとする
strNewPath = GetTargetBackendPath()
If strNewPath = “” Then
MsgBox “バックエンドデータベースのパスが取得できませんでした。システム管理者に連絡してください。”, vbCritical, “致命的エラー”
Exit Sub
End If
‘ 2. TableDefsコレクションを走査し、リンクテーブル（Connectプロパティを持つ）をチェック
intErrorCount = 0
For Each tdf In db.TableDefs
‘ テーブルの属性に「リンクテーブル」を示すフラグが含まれているか判定
If (tdf.Attributes & dbAttachedTable) = dbAttachedTable Then
‘ 接続文字列を新しいパスに書き換える必要があるか検証
If NeedsUpdate(tdf.Connect, strNewPath) Then
‘ 接続文字列の再構築 (Access (.accdb / .mdb) の場合)
‘ ※SQL Server等のODBC接続の場合はドライバーに応じた文字列構築が必要
tdf.Connect = “;DATABASE=” & strNewPath
On Error Resume Next
‘ リンクの更新を実行（ここで実体ファイルにアクセスするため、ファイルが存在しないとエラーになる）
tdf.RefreshLink
If Err.Number <> 0 Then
intErrorCount = intErrorCount + 1
Debug.Print “【修復失敗】テーブル名: ” & tdf.Name & ” / エラー: ” & Err.Description
Err.Clear
Else
Debug.Print “【修復成功】テーブル名: ” & tdf.Name
End If
On Error GoTo ErrorHandler
End If
End If
Next tdf
Set db = Nothing
If intErrorCount > 0 Then
MsgBox intErrorCount & ” 個のテーブルの接続修復に失敗しました。ネットワーク接続を確認してください。”, vbExclamation, “警告”
End If
Exit Sub
ErrorHandler:
MsgBox “リンクテーブルの修復中に予期せぬエラーが発生しました。” & vbCrLf & _
“Error: ” & Err.Number & ” – ” & Err.Description, vbCritical, “システムエラー”
Set db = Nothing
End Sub
‘ ==============================================================================
‘ 補助関数: 接続文字列の更新が必要か判定する
‘ ==============================================================================
Private Function NeedsUpdate(ByVal currentConnect As String, ByVal targetPath As String) As Boolean
‘ currentConnectの形式は通常 “;DATABASE=C:\path\to\backend.accdb”
Dim expectedConnect As String
expectedConnect = “;DATABASE=” & targetPath
If StrComp(currentConnect, expectedConnect, vbTextCompare) <> 0 Then
NeedsUpdate = True
Else
NeedsUpdate = False
End If
End Function
‘ ==============================================================================
‘ 補助関数: 設定テーブルから最新のバックエンドパスを取得する
‘ ==============================================================================
Private Function GetTargetBackendPath() As String
Dim rs As DAO.Recordset
Dim path As String
On Error GoTo CleanUp
‘ ローカルの非リンクテーブル「T_SystemConfig」から設定値を取得
Set rs = CurrentDb.OpenRecordset(“SELECT ConfigValue FROM T_SystemConfig WHERE ConfigKey = ‘BackendPath'”, dbOpenSnapshot, dbReadOnly)
If Not rs.EOF Then
path = Nz(rs!ConfigValue, “”)
End If
CleanUp:
If Not rs Is Nothing Then rs.Close: Set rs = Nothing
‘ パスの存在チェック（ファイルが存在するか）
If path <> “” And Dir(path) <> “” Then
GetTargetBackendPath = path
Else
GetTargetBackendPath = “”
End If
End Function
—
4. この設計が「プロの仕事」である理由
ただ動くだけのコードであれば誰でも書ける。このアーキテクチャがプロダクションレベルたる所以を解説しよう。
① `dbAttachedTable` ビットマスクによる厳密な判定
`TableDef` には、ローカルテーブルも含まれる。リンクテーブルだけに絞り込むために、`tdf.Attributes & dbAttachedTable` というビット演算を用いている。これにより、システム内部のシステムテーブルやローカルの一時テーブルを誤爆するリスクを完全になくしている。
② メタデータ（設定テーブル）の分離
「新しいパスはどこを見に行けばいいのか？」という疑問に対し、コード内に直接パスを書くのではなく、ローカルの `T_SystemConfig` テーブルから引いている。万が一、さらにサーバーが変わった場合も、設定テーブルの値を1行書き換えるか、あるいはローカルテーブル自体を更新する仕組みにしておけば、VBAのコンパイル（ソースコードの変更）すら不要になる。
③ エラーの局所化（Resilient Error Handling）
複数のリンクテーブルをループ処理する際、1つのテーブルの修復に失敗したからといって、全体の処理をクラッシュさせてはならない。ループ内で `On Error Resume Next` を使い、特定のテーブルの `RefreshLink` が失敗しても、次のテーブルの修復へシームレスに移行する設計にしている。
—
5. 現場で絶対に踏んではいけない地雷（注意点）
- ネットワーク遅延の罠:
起動時の `AutoExec` でこの処理を走らせる場合、VPN接続や低速なWi-Fi環境下では `Dir(path)` のチェックや `RefreshLink` がタイムアウトを起こすことがある。非同期処理が使えないAccess VBAの限界を考慮し、処理の前に簡単な疎通確認を入れるか、あるいは「リンク切れを検知した時だけ（あるいはユーザーがボタンを押した時だけ）修復モードに入る」というフォールバックを用意するのも実務的な知恵である。
- 排他制御とマルチユーザー:
バックエンド側（共有フォルダ上の `backend.accdb`）が他のユーザーによって排他ロックされている状態で `RefreshLink` を行うと、エラーになるか、最悪の場合破損の原因になる。バックエンドは常に「共有モード」で開かれるべきであり、バックエンド側で排他処理が必要なメンテナンスを行っている時間帯は、この自動修復スクリプトが誤動作しないようなガード句（例: メンテナンスフラグの確認）を挟むと完璧だ。
—
総括
Accessは「おもちゃのデータベース」と揶揄されることがある。しかし、それは開発者がオブジェクトモデルのライフサイクルや適切なエラーハンドリングをサボっている言い訳に過ぎない。
今回紹介した `TableDefs` と `RefreshLink` を駆使した動的修復ロジックを組み込めば、インフラの変更に怯える必要はなくなる。あなたの構築するAccessシステムは、企業インフラの変更をしなやかに受け流す、極めて頑健なコアシステムへと生まれ変わるはずだ。
さあ、今すぐコードをあなたのプロジェクトに組み込み、真の自動化エンジニアとしての実力を証明して見せろ。
