【テクニカル・上級編】DAOのRecordsetCloneとブックマーク：サブフォームとの同期を完璧に制御する – Access VBA解析バイブル

RecordsetCloneとBookmarkの真髄：フォーム同期における「状態」の完全制御

多くの「Access開発者」は、メインフォームとサブフォームの同期を、単なるプロパティの設定や、あるいは安易な`Requery`（再クエリ）で解決しようとする。

だが、それらはすべて「設計の敗北」である。

`Requery`は、データセット全体をメモリに再ロードし、カーソルを先頭に戻す。これは、大規模なデータセットを扱うエンタープライズ環境においては、UIのフリーズ、ネットワーク帯域の浪費、そして何より「ユーザーが現在作業していたコンテキスト（文脈）の喪失」を招く致命的な行為だ。

真のアーキテクトが追求すべきは、「データセットの物理的な再ロードを避け、論理的なポインタ（Bookmark）のみを操作して、異なるRecordsetオブジェクト間の状態を同期させること」である。

本稿では、DAO（Data Access Objects）の`RecordsetClone`と`Bookmark`を極限まで使いこなし、メインフォームとサブフォームのレコード位置を、メモリ効率を最大化しつつ、完璧に同期させるための技術的深淵を解説する。

1. アーキテクチャの根幹：RecordsetとCloneの物理的差異

まず、我々は「Recordset」というオブジェクトの正体を理解しなければならない。

Accessのフォームにバインドされている`Me.Recordset`は、UIスレッドと密結合した「表示用カーソル」である。これに対して`RecordsetClone`は、同じデータソースを参照しながらも、UIの描画プロセスから切り離された「メモリ上の複製カーソル」だ。

なぜCloneを使うのか？

UIにバインドされたRecordsetを直接操作（`MoveFirst`や`FindFirst`）することは、ユーザーの視界を強制的に動かすことを意味する。これはUX（ユーザーエクスペリエンス）における大罪だ。
一方で、`RecordsetClone`に対して操作を行い、その結果得られた「位置情報」である`Bookmark`だけをUI側に渡す手法をとれば、ユーザーの視界を乱すことなく、バックグラウンドで正確なナビゲーションが可能になる。

2. 完璧な同期を実現する「黄金のパターン」

以下に、メインフォームのレコード移動に追従して、サブフォームのレコード位置を正確に同期させる実装を示す。ここでは、単なる同期だけでなく、レコードの削除時や、不整合が発生した際の例外処理、そしてオブジェクトの明示的な破棄までを網羅している。

Option Compare Database
Option Explicit

' ======================================================================================
' 概要: メインフォームのレコード位置をサブフォームへ同期させる
' 設計思想: Requeryを回避し、Bookmarkによる論理ポインタの転送を行う。
'           メモリリークを防ぐため、DAOオブジェクトのライフサイクルを厳格に管理する。
' ======================================================================================
Public Sub SynchronizeSubformWithMain(ByRef frmMain As Form, ByRef subFrm As Form)
    On Error GoTo ErrorHandler

    Dim rsMain As DAO.Recordset
    Dim rsSub As DAO.Recordset
    Dim targetBookmark As Variant

    ' 1. オブジェクトの取得（Cloneを使用することでUIへの影響を最小化）
    ' 注意: Me.Recordsetを直接触るのではなく、Cloneを介して状態をスキャンする
    Set rsMain = frmMain.RecordsetClone
    Set rsSub = subFrm.RecordsetClone

    ' 2. メインフォームの現在の位置（Bookmark）を取得
    ' レコードが存在しない（EOFかつBOF）場合はNothingを返す
    If rsMain.EOF And rsMain.BOF Then
        Exit Sub
    End If
    
    targetBookmark = rsMain.Bookmark

    ' 3. サブフォーム側で該当するレコードを検索
    ' ここでは、Bookmarkを直接代入するのではなく、
    ' サブフォームのRecordsetがメインのBookmarkを理解できる文脈にあるかを確認する必要がある。
    ' ※通常、親子関係（LinkChildFields/LinkMasterFields）がある場合、
    '    サブフォームのRecordsetはメインの特定のレコードにフィルタリングされている。
    
    ' サブフォームのレコードセットが空でないことを確認
    If Not (rsSub.EOF And rsSub.BOF) Then
        ' 直接Bookmarkを同期させる。
        ' これは、サブフォーム内のRecordsetがメインのレコードに紐付いた
        ' フィルタリング済みの状態であることを前提としている。
        On Error Resume Next
        rsSub.Bookmark = targetBookmark
        
        If Err.Number <> 0 Then
            ' Bookmarkが一致しない（レコードが削除された、あるいはフィルタ条件外）場合の処理
            ' ここでは、サブフォームの先頭へ戻る等のフォールバックを行う
            Debug.Print "Warning: Bookmark sync failed. Record might have been deleted."
            rsSub.MoveFirst
        End If
        On Error GoTo ErrorHandler
    End If

    ' 4. UI（サブフォーム）へ変更を反映
    ' Cloneの操作を実際のフォーム表示に同期させる
    subFrm.Bookmark = rsSub.Bookmark

CleanUp:
    ' 5. オブジェクトの明示的な解放（メモリ管理の極致）
    ' VBAのGC（ガベージコレクション）に頼らず、即座に参照を断つ。
    ' 特に大規模なループや頻繁なイベント内でこれを怠ると、メモリリークの原因となる。
    On Error Resume Next
    If Not rsMain Is Nothing Then
        rsMain.Close
        Set rsMain = Nothing
    End If
    If Not rsSub Is Nothing Then
        rsSub.Close
        Set rsSub = Nothing
    End If
    Exit Sub

ErrorHandler:
    MsgBox "Critical Error in Synchronization: " & Err.Description, vbCritical, "Architect's Error"
    Resume CleanUp
End Sub

3. エンジニアが陥る「メモリとライフサイクル」の罠

シニアエンジニアとして、私が常に警鐘を鳴らしているのが「オブジェクトの生存期間」だ。

3.1. `Set rs = Nothing` の真実

VBAにおいて、`Set rs = Nothing` は単にポインタをクリアするだけではない。オブジェクトが参照カウントゼロになった瞬間に、その背後にあるCOM（Component Object Model）リソースが解放される。
しかし、`RecordsetClone`のような派生オブジェクトを生成した場合、親である`Recordset`が生存している間、メモリ上の構造は複雑に絡み合う。
特に、エラーハンドリング内でオブジェクトを解放し忘れると、Accessのプロセス（`msaccess.exe`）のメモリ使用量が右肩上がりに増大し、最終的に「メモリ不足」でクラッシュする。これは、レガシーなシステムを長期間稼働させる現場では、死に至る病である。

3.2. Bookmarkの有効性と例外処理

`Bookmark`は、いわば「データの住所」だ。しかし、その住所が指す家（レコード）が、他のユーザーの操作や、自身のトランザクションによって破壊（削除）された場合、そのBookmarkを適用しようとした瞬間に `Error 3265 (No current record)` が発生する。
私のコード例では、`On Error Resume Next` を用いてBookmarkの代入を試み、失敗した場合にはフォールバック（`MoveFirst`）を行う堅牢な設計を採用している。これは「正常系」だけでなく「異常系」を設計に組み込む、プロフェッショナルの作法である。

4. パフォーマンスを極限まで高めるための知見

もし、あなたが数万件のレコードを扱うシステムのアーキテクトであるなら、以下の点も考慮に入れよ。

1. ADOとの混在を避ける:
AccessのフォームはDAOエンジンに最適化されている。ADO（ActiveX Data Objects）を使用してRecordsetを操作することも可能だが、フォームとの同期においてADO Recordsetを直接扱うことは、変換オーバーヘッドを生み、パフォーマンスを著しく低下させる。同期にはDAOを貫け。
2. Windows APIとの境界線:
VBAの動作を高速化するためにWindows API（`GetTickCount`や`SendMessage`など）を呼び出す場面もあるが、Recordsetの操作に関しては、DAOの内部実装に任せるのが最も安全かつ高速だ。APIで無理にメモリを操作しようとするのは、設計の稚拙さの現れである。

結論

`RecordsetClone`と`Bookmark`の制御は、Access VBAにおける「精密機械の組み立て」に似ている。
各パーツ（オブジェクト）の役割を理解し、そのライフサイクルを厳格に管理し、不測の事態（レコード削除）に対する防壁を築く。

これこそが、単なる「動くコード」を書くプログラマーと、システムの「品質を保証する」エンジニアを分かつ境界線である。