リンクテーブルの「死」を看取るな：CurrentDb.TableDefsを掌握するプロの流儀
Access開発の現場において、リンクテーブルの接続切れは「システム死」を意味する。ファイルサーバーの移転、NASのリプレース。インフラの変更は容赦なくアプリケーションの足元をすくう。
多くの初心者は「リンクテーブルマネージャー」というGUIの海に溺れるが、我々アーキテクトにとって、それは甘えだ。システムの起動時に接続先を自動走査し、再構築する。この堅牢性こそが、レガシーを「プロの道具」へと昇華させる唯一の道である。
今日は、`CurrentDb.TableDefs`を深淵まで使いこなし、メモリリークを許さない「真の自動修復」の作法を伝授する。
—
1. なぜ「手動」ではいけないのか
リンクテーブルの接続情報は、Accessのシステムカタログ（MSysObjects）に深く刻まれている。これを闇雲に書き換えるのは危険だ。パスが変わったからといって、適当なDAOコードを書いてオブジェクトを氾濫させれば、Accessはメモリリークを起こし、パフォーマンスは劇的に低下する。
真のエンジニアは、以下の3点を遵守する。
- 接続文字列の正規化: 絶対パスだけでなく、UNCパスを正しく評価する。
- オブジェクトのライフサイクル管理: `TableDef`オブジェクトを使い捨てず、参照を確実に解放する。
- トランザクション的思考: 書き換えは「成功」か「完全な失敗」の二択であるべきだ。
—
2. 実装：リンクテーブル自動修復エンジン
以下のコードは、起動時に呼び出すことを前提とした、堅牢な修復ロジックである。`GetObject`や`DAO`の取り扱いに、プロのこだわりを込めた。
Option Compare Database
Option Explicit
‘ リンクテーブルのパスを一括更新するコアロジック
Public Sub RepairLinkedTables(ByVal newBackendPath As String)
Dim db As DAO.Database
Dim tdf As DAO.TableDef
‘ データベースオブジェクトを明示的に取得
Set db = CurrentDb
On Error GoTo ErrHandler
‘ リンクテーブルのみをフィルタリングして走査
For Each tdf In db.TableDefs
‘ 接続文字列の先頭が “DATABASE=” で始まるものをリンクテーブルと判定
If Left(tdf.Connect, 10) = “;DATABASE=” Then
‘ 接続先が既存のパスと異なる場合のみ更新
If InStr(tdf.Connect, newBackendPath) = 0 Then
tdf.Connect = “;DATABASE=” & newBackendPath
‘ リフレッシュしなければ変更はシステムに反映されない
tdf.RefreshLink
Debug.Print “修復完了: ” & tdf.Name
End If
End If
Next tdf
Cleanup:
‘ オブジェクトの明示的解放（VBAのメモリ管理の鉄則）
If Not tdf Is Nothing Then Set tdf = Nothing
If Not db Is Nothing Then Set db = Nothing
Exit Sub
ErrHandler:
MsgBox “リンク修復中に致命的なエラーが発生しました: ” & Err.Description, vbCritical
Resume Cleanup
End Sub
—
3. シニアエンジニアが意識すべき「深層」
このコードを見て「これだけか？」と思ったなら、まだ甘い。実戦投入するには、以下の観点を付け加える必要がある。
① パスの妥当性検証
`newBackendPath`が本当に存在するか、ネットワークが遮断されていないか。これをチェックせずに`RefreshLink`を呼ぶのは自殺行為だ。`Dir()`関数での存在確認だけでなく、Windows APIである `PathFileExists`（shlwapi.dll）を呼び出すことで、OSレベルで確実なパス評価を行うべきだ。
② 隠しテーブルの罠
`TableDefs`にはシステムテーブルも含まれる。不用意に走査対象を広げると、システムカタログを破壊する可能性がある。`Attributes`プロパティをチェックし、`dbAttachedTable`（リンクテーブル）であるかを厳密に判定することが、大規模システムにおける事故防止の鍵となる。
③ インタフェースの分離
この処理は、メインのフォームがロードされる「前」に実行される必要がある。`AutoExec`マクロ、あるいはスタートアップフォームの `Form_Load` イベントの冒頭に配置し、万が一修復に失敗した場合は、即座にアプリケーションを閉じる（`Application.Quit`）という「フェイルセーフ」を組み込むのがアーキテクトの矜持だ。
—
結論：システムは「生き物」である
Accessは静的なファイルではない。日々変化するインフラ環境に適応し、自己修復する能力を持たせてこそ、保守コストはゼロに近づく。
コードをコピペして満足するな。なぜそのオブジェクトを解放するのか、なぜそのプロパティを評価するのか。その「理由」を解釈できた時、君は初めてAccessという魔窟を攻略する資格を得る。
さあ、レガシーなシステムを、君のコードで蘇らせてみせろ。
