Access VBAを掌握する極限の知見：DSNレス接続による環境依存の完全排除
Access開発の現場で、未だに「ODBCデータソース名（DSN）」の呪縛に囚われているエンジニアは多い。クライアントPC一台ずつにDSNを手動設定し、システム移行のたびに管理の手間と設定ミスというリスクを背負い込む。これは、アーキテクトとしては「敗北」に等しい。
真の業務自動化エンジニアにとって、接続情報は「コード内、あるいは構成ファイル内」で完結すべき動的な資産である。本稿では、DSNレス接続を極め、環境依存を排除するアーキテクチャの真髄を伝授する。
—
1. なぜDSNを捨て去るべきなのか
DSNはレガシーな手法であり、以下の欠点を抱えている。
- 環境依存性: PCごとに設定が必要であり、配布や保守のコストが膨大。
- 権限の壁: レジストリへの書き込み権限が必要であり、セキュリティポリシーが厳しい環境では障壁となる。
- 暗黙の知: 「どの設定を触れば動くのか」がブラックボックス化し、属人化を助長する。
対してDSNレス接続は、接続文字列（Connection String）をプログラム実行時に動的に構築する。これにより、実行環境が変わっても、接続先情報さえあれば即座に稼働する「ポータブルなシステム」が完成する。
—
2. 鋼鉄の接続文字列構築術
SQL Serverへの接続を例に、OSやドライバの差異を吸収しつつ、堅牢な文字列を構築する関数を実装する。
‘ 接続文字列を動的に生成する関数
‘ 認証方式（Windows/SQL Server）を引数で制御し、環境依存を排除する
Public Function GetConnectionString(ByVal ServerName As String, _
ByVal DatabaseName As String, _
Optional ByVal UserID As String = “”, _
Optional ByVal Password As String = “”) As String
Dim sb As String
‘ SQL Server Native Client / ODBC Driver のバージョンは環境に合わせて最適化せよ
‘ 昨今のモダンな環境では ‘ODBC Driver 17 for SQL Server’ を推奨する
sb = “DRIVER={ODBC Driver 17 for SQL Server};” & _
“SERVER=” & ServerName & “;” & _
“DATABASE=” & DatabaseName & “;”
If UserID = “” Then
‘ Windows認証（推奨）
sb = sb & “Trusted_Connection=yes;”
Else
‘ SQL Server認証
sb = sb & “UID=” & UserID & “;PWD=” & Password & “;”
End If
‘ 接続タイムアウトの設定を明示的に含める（デフォルトのままだとネットワーク遅延で即死する）
sb = sb & “Connection Timeout=30;”
GetConnectionString = sb
End Function
—
3. ADOオブジェクトのライフサイクル管理の極意
VBAにおけるADOオブジェクトは、適当に扱えばメモリリークを招き、最悪の場合Accessのプロセスがゾンビ化する。シニアエンジニアならば、`Set Nothing` を行うのは当然として、その「順序」と「スコープ」に神経を尖らせるべきだ。
Public Sub ExecuteQuerySafely(ByVal connStr As String, ByVal sql As String)
Dim conn As ADODB.Connection
Dim rs As ADODB.Recordset
‘ 接続とレコードセットの生成は最小スコープで
Set conn = New ADODB.Connection
Set rs = New ADODB.Recordset
On Error GoTo ErrorHandler
With conn
.ConnectionString = connStr
.CursorLocation = adUseClient ‘ クライアントサイドカーソルでネットワーク負荷を制御
.Open
End With
rs.Open sql, conn, adOpenStatic, adLockReadOnly
‘ ここでデータを処理…
GoTo Cleanup
ErrorHandler:
‘ エラーハンドリングの記述
Debug.Print “Error: ” & Err.Description
Cleanup:
‘ オブジェクトの明示的解放：順序は生成と逆。
‘ 接続を閉じる前にレコードセットを閉じるのが鉄則。
If Not rs Is Nothing Then
If rs.State = adStateOpen Then rs.Close
Set rs = Nothing
End If
If Not conn Is Nothing Then
If conn.State = adStateOpen Then conn.Close
Set conn = Nothing
End If
End Sub
—
4. アーキテクトからの提言：レガシーの先へ
DSNレス接続を導入するだけで、システム連携の柔軟性は劇的に向上する。しかし、真の極みを目指すのであれば、以下の点も考慮に入れるべきだ。
1. 接続情報の暗号化: 接続文字列をベタ書きするのは論外だ。WindowsのCredential Manager（資格情報マネージャー）からAPI経由で取得するか、暗号化されたローカル構成ファイル（.iniや.json）から読み込むのがプロの流儀である。
2. 接続の再試行ロジック: ネットワークの一瞬の瞬断でシステムを落とさない。「再接続」の試行回数とウェイト時間を定数化し、堅牢なレジリエンスを持たせること。
3. DAOとADOの使い分け: Accessのローカルテーブル操作にはDAOを使い、外部SQL ServerやAPI連携にはADO（またはADODB）を使うという「適材適所」の原則を忘れてはならない。
Accessは、使いようによっては企業システムの中核を担う強力なエンジンとなる。DSNの呪縛を解き、コードで環境を制御せよ。それが、システム管理者の顔色を伺う日々から脱却するための唯一の道である。
次回の記事では、Windows APIを活用したAccessプロセスの高度なメモリ制御について深掘りする。準備はいいか。
