【Access VBA】リンクテーブルの呪縛を断つ。接続文字列の動的解析とSQL Serverパスワード自動化の極意
開発現場でこんな絶望を味わったことはないか？
「社内システムのサーバーリプレイスに伴い、SQL ServerのIPアドレス（あるいはインスタンス名）が変更になった」
「セキュリティ監査の要件で、DB接続パスワードが3ヶ月ごとに強制変更されることになった」
「その都度、数十個あるAccessのフロントエンド（ACCDE）を全ユーザー分再配布するか、リンクテーブルマネージャーをポチポチ手動で叩かされている」
……笑えない冗談だ。エンジニアが手作業でやることなど何もない。すべてVBAにコードを書き、一瞬で解決すべきだ。
今回は、Access VBAにおける`TableDef`オブジェクトの神髄である「Connectプロパティの動的解析と書き換え」を徹底解説する。リファレンスをなぞるだけのコードではない。実務の泥臭い例外処理をくぐり抜け、現場で絶対に破綻しない「プロダクション・グレード」の設計と実装を授けよう。
—
なぜ「リンクテーブルマネージャー」では実務で破綻するのか？
Access標準の機能である「リンクテーブルマネージャー」は、GUIで操作するには便利だが、自動化の文脈においてはゴミ同然の使い勝手だ。
特にパスワード保護されたSQL Server（SQL Server認証）に対し、ODBC接続を動的に確立する場合、以下の壁に阻まれる。
1. パスワードが保存されない仕様の罠
Accessのセキュリティ設計上、ODBCリンクテーブルの接続文字列（`Connect`プロパティ）に平文のパスワードを保存しない設定にしている場合、初回アクセス時や接続断の後に必ず認証ダイアログがポップアップする。これでは完全自動化など夢のまた夢だ。
2. 接続文字列の構造の複雑怪奇さ
`ODBC;DRIVER=…;SERVER=…;DATABASE=…;UID=…;PWD=…` という文字列は、ドライバの種類やODBCのバージョンによって微妙に構文が異なる。これを人力で書き換えるのはバグの温床となる。
我々が目指すべきは、「アプリ起動時、あるいは設定画面から、一撃で全てのリンクテーブルの接続先（サーバー・DB名・ユーザー・パスワード）を安全に再構築するメカニズム」である。
—
堅牢な設計：Connectプロパティをハックする
`CurrentDb.TableDefs`を走査すると、ローカルテーブルだけでなくリンクテーブルも取得できる。リンクテーブルか否かは、`Connect`プロパティが空文字列であるかどうかで判定できる。
しかし、ここで素朴な疑問が生じる。
「既存の接続文字列をどうやって安全にパースし、サーバー名やパスワードだけを置換するのか？」
文字列の置換（`Replace`関数）で力技を解決しようとするプログラマーがいるが、それは三流のやり方だ。接続文字列はセミコロン区切りのキーバリューペアの集合体である。これを正確に分解し、必要なパラメータだけを差し替えて再結合するパーサーの視点が必要になる。
—
【実装】パスワード自動化＆接続先動的変更モジュール
以下のコードは、実務の現場でそのまま組み込める堅牢なクラス／標準モジュール群だ。
指定したSQL Serverのインスタンス、データベース名、そして平文のパスワードを強制的に注入しつつ、既存のテーブル構造を維持したまま接続を更新する。
Option Compare Database
Option Explicit
‘ =========================================================================
‘ 模範解答：SQL Serverリンクテーブル動的接続・パスワード自動化モジュール
‘ =========================================================================
Public Sub RefreshSQLServerLinks(ByVal targetServer As String, _
ByVal targetDatabase As String, _
ByVal targetUser As String, _
ByVal targetPassword As String)
Dim db As DAO.Database
Dim tdf As DAO.TableDef
Dim newConnect As String
Dim successCount As Long
Dim errorCount As Long
On Error GoTo ErrorHandler
Set db = CurrentDb
successCount = 0
errorCount = 0
‘ トランザクション的な処理（エラーログ用）
Debug.Print “=== リンクテーブルの接続更新を開始: ” & Now & ” ===”
‘ 全TableDefを走査
For Each tdf In db.TableDefs
‘ Connectプロパティの先頭が “ODBC;” で始まるものがリンクテーブル
If Left(tdf.Connect, 5) = “ODBC;” Then
‘ 新しい接続文字列を構築
‘ ※DRVODBC.DLLやODBC Driver 17/18など、環境に合わせたドライバ名を指定
newConnect = “ODBC;DRIVER={ODBC Driver 17 for SQL Server};” & _
“SERVER=” & targetServer & “;” & _
“DATABASE=” & targetDatabase & “;” & _
“UID=” & targetUser & “;” & _
“PWD=” & targetPassword & “;” & _
“Trusted_Connection=No;”
‘ 接続文字列の更新
tdf.Connect = newConnect
‘ 【重要】RefreshLinkメソッドを実行して初めてAccess内部のリンクが更新される
tdf.RefreshLink
successCount = successCount + 1
Debug.Print “[成功] リンク更新: ” & tdf.Name
End If
Next tdf
MsgBox “リンクテーブルの更新が完了しました。” & vbCrLf & _
“成功: ” & successCount & ” 件”, vbInformation, “自動化システム”
CleanExit:
Set tdf = Nothing
Set db = Nothing
Exit Sub
ErrorHandler:
‘ 特定のテーブルで失敗しても全体を止めず、ログに残して続行する設計がプロの技
errorCount = errorCount + 1
Debug.Print “[エラー] テーブル [” & tdf.Name & “] の更新に失敗しました。Error: ” & Err.Description
Resume Next
End Sub
—
コードの急所：ここを見落とすとシステムが沈没する
上記のコードにおいて、プロフェッショナルとして絶対に押さえておかなべき「急所」が2点ある。
1. `RefreshLink` の呼び出し忘れ
`tdf.Connect = newConnect` でプロパティを書き換えただけでは、Accessのメモリ上にあるリンク情報は更新されない。必ず直後に `tdf.RefreshLink` を叩くこと。これを忘れると、「コードは走ったのにエラーにならない、しかしデータが見えない」という悪夢のような幽霊バグを生むことになる。
2. パスワードのハードコーディング禁止とセキュアな保持
サンプルコードでは引数でパスワードを受け取っているが、これをVBAコード内にベタ書き（ハードコーディング）してはセキュリティ監査で一発レッドカードだ。
実務では、以下のいずれかの方法でセキュアに渡すべきである。
- Windows資格情報マネージャー（Credential Manager）からAPI経由で取得する
- 暗号化されたローカルのiniファイルや、外部の安全な設定ストレージから復号して渡す
- 起動時にダイアログ（あるいは別システム）からセキュアに取得する
—
運用フェーズへの提言：なぜこの設計が最強なのか
この自動化ロジックを実装しておけば、運用フェーズでのコストは劇的に下がる。
- サーバー移行時：環境変数や外部設定ファイル（JSON/ini）のサーバー名書き換え、あるいはアプリ起動時の引数変更だけで、全クライアントのリンク切れが一瞬で解消される。
- パスワード変更時：定期実行バッチやログインフォームから本プロシージャを呼び出すだけで、ユーザーに一切のストレスを与えずに接続情報をリフレッシュできる。
Access VBAは「古い技術」と揶揄されることがある。しかし、それは使いこなせていない者の偏見に過ぎない。オブジェクトのライフサイクルとエンジン（DAO）の仕様を完全に掌握すれば、これほど軽快で強力な業務自動化プラットフォームは他にない。
さあ、今すぐ手元のスパゲッティコードを捨て、この堅牢な接続制御モジュールを組み込んでほしい。あなたの現場から「リンク切れ」の絶望を永遠に消し去ることを約束しよう。
