フォームの「死」を回避せよ：DAO Recordsetのライフサイクルを掌握する極限のメモリ管理術
Access VBAで業務アプリケーションを構築していると、必ず直面する壁がある。
「最初は軽快に動いていたツールが、数時間の連続稼働、あるいはデータの切り替えを繰り返すうちに、目に見えて動作が重くなる。最悪の場合、Accessが『応答なし』となり、強制終了する。」
この現象の正体を知っているか？ 多くの開発者は「PCのスペック不足」や「データの肥大化」を疑う。だが、真犯人はそれらではない。オブジェクトのライフサイクル管理の放棄、すなわち「Recordsetの不適切な解放」によるメモリリークだ。
本稿では、フォームのデータソースを動的に切り替える際、プロフェッショナルが守るべき「DAO Recordsetの鉄則」を、アーキテクチャの観点から徹底的に解説する。
1. なぜ「動的な切り替え」でメモリが枯渇するのか
Accessのフォームにおいて、`Me.Recordset = rs` というコードは一見、非常にシンプルでエレガントに見える。しかし、この一行の裏側では、メモリ上の「リファレンスカウント（参照カウント）」という極めて重要なメカニズムが動いている。
参照の連鎖が引き起こす悲劇
DAOのRecordsetオブジェクトをフォームのプロパティに代入したとき、そのオブジェクトへの参照は以下の2箇所に存在する。
1. ローカル変数（VBAコード内の `rs`）
2. フォームオブジェクト（`Me.Recordset` プロパティ）
問題は、新しいRecordsetを代入する際に、「以前のRecordsetを明示的にCloseし、Nothingで解放していない」場合に発生する。
新しいオブジェクトを代入しても、古いオブジェクトへの参照がメモリ内に「幽霊」のように残り続ける。これが蓄積されると、メモリ領域を圧迫するだけでなく、データベースエンジン（ACE/Jet）が保持する「レコードロック」が解除されず、他のユーザーやプロセスからのアクセスを阻害する致命的なバグへと発展する。
2. DAO vs ADO：アーキテクチャの選択
動的なデータソース切り替えを実装する際、ADO（ActiveX Data Objects）を選択肢に入れる者がいる。しかし、Access内部のテーブルやリンクテーブルを扱う場合、私は迷わずDAOを推奨する。
| 特徴 | DAO (Data Access Objects) | ADO (ActiveX Data Objects) |
|---|---|---|
| 親和性 | Accessエンジン（ACE/Jet）にネイティブ設計 | COMベースの汎用ラッパー |
| パフォーマンス | ローカル操作において極めて高速 | オーバーヘッドが比較的大きい |
| 制御力 | インデックスやエディット操作の制御が緻密 | 汎用的だがAccess特有の機能に弱い |
Accessアプリケーションの心臓部はDAOである。メモリ管理の厳密さを求めるなら、DAOのライフサイクルを完全に掌握することこそが、堅牢な設計への近道だ。
3. 【実践】堅牢な動的切り替えの実装パターン
では、実際にどのようなコードを書くべきか。
単に `Set Me.Recordset = rs` と書くのは素人の仕事だ。プロフェッショナルは、「既存リソースの完全な破壊」と「エラー発生時のクリーンアップ」をセットで設計する。
以下に、プロダクション環境でそのまま利用可能な、極めて堅牢な実装例を示す。
Option Compare Database
Option Explicit
' ======================================================================================
' プロシージャ名: RefreshFormDataSource
' 概要: フォームのRecordsetを動的に切り替える。メモリリークを防止する設計。
' 引数: strSQL - 取得したいデータのSQL文
' ======================================================================================
Public Sub RefreshFormDataSource(ByVal strSQL As String)
Dim db As DAO.Database
Dim rs As DAO.Recordset
' エラーハンドリングの開始
On Error GoTo ErrorHandler
' --- STEP 1: 既存のRecordsetの完全な破棄 ---
' フォームに既にRecordsetがセットされている場合、
' 単に上書きするのではなく、明示的にCloseして参照を断つ必要がある。
If Not Me.Recordset Is Nothing Then
Me.Recordset.Close
Set Me.Recordset = Nothing
End If
' --- STEP 2: 新しいデータソースの構築 ---
Set db = CurrentDb
' dbOpenDynasetを使用することで、編集可能なRecordsetを生成
Set rs = db.OpenRecordset(strSQL, dbOpenDynaset)
' Recordsetが空（レコードなし）の場合のハンドリング
If rs.EOF And rs.BOF Then
MsgBox "指定された条件に一致するデータは見つかりませんでした。", vbInformation, "通知"
' データがない場合でも、空のRecordsetをセットするか、
' あるいは何もしないかを設計思想に基づいて決定する。
' ここでは、UIの整合性を保つため、空のオブジェクトをセットする。
End If
' --- STEP 3: フォームへのバインディング ---
' ここで、フォームのRecordsetプロパティが新しいrsへの参照を持つ。
Set Me.Recordset = rs
' --- STEP 4: ローカル変数のクリーンアップ ---
' 注意：rsをNothingにする前に、Me.Recordsetへの代入が完了している必要がある。
' 代入後は、Me.Recordsetがオブジェクトを保持しているため、
' ローカル変数のrsを解放してもオブジェクト自体は消えない。
Set rs = Nothing
Set db = Nothing
ExitProcedure:
Exit Sub
ErrorHandler:
' エラー発生時は、開いているリソースを確実に閉じる
MsgBox "データ切り替え中にエラーが発生しました。" & vbCrLf & _
"Error No: " & Err.Number & vbCrLf & _
"Description: " & Err.Description, vbCritical, "致命的エラー"
' クリーンアップ処理
On Error Resume Next ' エラーハンドラ内でのエラーを無視
If Not rs Is Nothing Then
rs.Close
Set rs = Nothing
End If
Set db = Nothing
Resume ExitProcedure
End Subこのコードの「設計の要諦」
1. 先行的な破棄 (`If Not Me.Recordset Is Nothing`):
新しいRecordsetを割り当てる前に、現在の`Me.Recordset`を`Close`している。これが欠落すると、前のデータセットがメモリ上に「浮遊」し続ける。
2. エラーハンドリングの二段構え:
エラーが発生した際、`rs`が中途半端な状態で残らないよう、`ErrorHandler`内で必ず`Close`と`Nothing`を執行している。
3. 参照の分離:
`Set Me.Recordset = rs` の直後に `Set rs = Nothing` を行うことで、VBAのローカルスコープにおける管理を明確にしている。これにより、オブジェクトの所有権が「ローカル変数」から「フォームオブジェクト」へと完全に移行したことを保証する。
4. 結論：エンジニアとしての規律
Access VBAにおけるメモリ管理は、決して「おまけ」ではない。それはアプリケーションの「寿命」そのものを決定づける設計思想だ。
「動けばいい」という考えで、Recordsetの代入を繰り返すコードを書くことは、時限爆弾を仕掛けているのと同義である。
- オブジェクトには必ず寿命（Lifecycle）がある。
- 参照（Reference）を渡したら、元の参照を適切に管理せよ。
- エラーは「例外」ではなく「日常」として設計に組み込め。
この規律を守る者だけが、大規模な業務システムにおいても、数年間にわたって安定稼働し続ける「真に価値のあるツール」を構築することができる。
