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

Access VBA

2026.11.15

指針：UI同期の虚構を排し、ポインタを掌握せよ —— DAO RecordsetCloneとBookmarkによる極限の同期制御

指針：UI同期の虚構を排し、ポインタを掌握せよ —— DAO RecordsetCloneとBookmarkによる極限の同期制御

Access開発における「メインフォームとサブフォームの同期」という課題に対し、多くの開発者は「連結フィールド（Link Child/Master Fields）」というAccessのブラックボックスな機能に身を委ねる。しかし、システムが大規模化し、複雑なビジネスロジックが絡み合い、数万件のレコードを扱うプロフェッショナルな現場において、そのブラックボックスはしばしば「予期せぬ再クエリ」や「フォーカス喪失によるパフォーマンス低下」という牙を剥く。

真に堅牢なシステムを構築するアーキテクトは、UIの動きに翻弄されるのではない。データのポインタ（Bookmark）を直接制御し、メモリ上のレコードセットの状態を意図的に操作することで、UIを支配するのだ。

本稿では、DAOの`RecordsetClone`と`Bookmark`を用いた、低レイテンシかつメモリ効率に優れた同期制御の極意を伝授する。

1. アーキテクチャの解剖：なぜ「連結フィールド」では不十分なのか

Accessの標準機能である連結フィールドは、内部的に「値の照合」を行っている。これは、親レコードのIDと子レコードの外部キーを常に比較し、条件に合致するものをフィルタリングする挙動だ。

しかし、この挙動には以下のコストが伴う。
1. 再クエリのオーバーヘッド: 親レコードの移動に伴い、サブフォームに対して非明示的な再フィルタリングが走る。
2. 状態の不一致: トランザクション処理中や、レコードの追加・削除が頻繁に発生する環境下では、UIの表示と内部的なインデックスが乖離するリスクがある。

これに対し、`RecordsetClone`を用いた同期は、値の照合ではなく「メモリ上の位置（Bookmark）の転送」である。これは、物理的な検索をスキップし、エンジンに対して「次はこのメモリ番地を見ろ」と直接命令を下す行為に等しい。

2. 実装の核心：Bookmarkによるポインタ同期パターン

サブフォームをメインフォームの選択行に完全に追従させるためには、メインフォームの`RecordsetClone`から取得した`Bookmark`を、サブフォームの制御用レコードセットに流し込む手法が最も効率的である。

以下に、シニアエンジニアが実装すべき、メモリ解放までを考慮した堅牢な同期モジュールを示す。

Option Compare Database
Option Explicit

' Windows APIの宣言: UIのちらつきを抑え、描画更新を制御する
' 描画の最適化は、大規模データ操作時のユーザー体験を決定づける
Private Declare PtrSafe Function LockWindowUpdate Lib "user32" (ByVal hwndLock As LongPtr) As Long

''' <summary>
''' メインフォームの選択行に基づき、サブフォームの表示位置を同期させる。
''' </summary>
''' <param name="frmMain">メインフォームオブジェクト</param>
''' <param name="subformControl">サブフォームを保持しているコントロール名</param>
Public Sub SynchronizeSubformByBookmark(ByRef frmMain As Form, ByVal subformControl As String)
    Dim rsMain As DAO.Recordset
    Dim rsSub As DAO.Recordset
    Dim targetBookmark As Variant
    
    On Error GoTo ErrorHandler

    ' 1. メインフォームのクローンを取得（UIのカーソルを動かさずに内部ポインタのみを操作するため）
    ' RecordsetCloneは、現在のフォームの読み込み済みキャッシュを指すため、極めて高速である。
    Set rsMain = frmMain.RecordsetClone
    
    ' 2. サブフォーム内のレコードセットを取得
    ' サブフォーム自体がレコードソースを持っている前提
    Set rsSub = frmMain.Controls(subformControl).Form.RecordsetClone

    ' 3. 現在のメインフォームのブックマークを取得
    targetBookmark = frmMain.Bookmark

    ' 4. UIの描画ロック（Windows API）
    ' 大量のレコード移動に伴う描画のちらつき（Flicker）を防止する
    LockWindowUpdate frmMain.hwnd

    ' 5. 同期ロジック
    ' メインフォームの現在の位置（Bookmark）を、サブフォームのレコードセットに適用する
    ' ここでは「メインのID」をキーにサブフォームを検索するロジックを記述する
    ' ※単純な親子関係（1:N）で、サブフォームが親のIDを常に保持している場合を想定
    
    ' 注意：Bookmarkの直接転送は、異なるRecordset間では不可。
    ' したがって、キー値に基づいたポインタの再構築が必要となる。
    
    ' 例: 親ID(ParentID)をキーに、サブフォームのレコードセット内を検索
    Dim searchID As Variant
    searchID = frmMain.Fields("ID").Value ' メインの主キー

    ' サブフォームのレコードセット内を検索（SeekではなくFindFirstを使用）
    ' 検索条件は、インデックスが貼られているフィールドを指定すること
    rsSub.FindFirst "[ParentID] = " & searchID

    If Not rsSub.NoMatch Then
        ' 見つかった場合、サブフォームの表示位置を更新
        ' フォーム自体のレコードセットではなく、Cloneを操作することでUIの整合性を保つ
        frmMain.Controls(subformControl).Form.Bookmark = rsSub.Bookmark
    End If

CleanUp:
    ' 6. Windows APIの解除
    LockWindowUpdate 0
    
    ' 7. オブジェクトの明示的解放（メモリリーク防止の鉄則）
    ' Access VBAにおけるDAOオブジェクトの解放を怠ると、
    ' データベースのロック（.ldb / .laccdb）が解除されない原因となる。
    If Not rsSub Is Nothing Then
        rsSub.Close
        Set rsSub = Nothing
    End If
    If Not rsMain Is Nothing Then
        rsMain.Close
        Set rsMain = Nothing
    End If
    Exit Sub

ErrorHandler:
    MsgBox "Synchronization Error: " & Err.Description, vbCritical, "Architectural Fault"
    Resume CleanUp
End Sub

3. 極限の最適化：メモリ管理とライフサイクル

プロフェッショナルな設計において、`Set obj = Nothing` は単なる作法ではない。それは「リソースの所有権の放棄」を意味する。

DAO vs ADO のメモリ特性

ADO（ActiveX Data Objects）は、CursorLocationの設定次第でクライアントサイド・カーソル（メモリ上に全データを展開）とサーバーサイド・カーソルを使い分けるが、AccessのUIエンジンとの親和性が高いのは依然としてDAOである。DAOはJet/ACEエンジンと密結合しており、`RecordsetClone`によるメモリ参照は、物理的なディスクI/Oを最小限に抑える。

破棄のタイミング

特に、ループ処理の中で`RecordsetClone`を生成する場合、明示的な`.Close`と`Set = Nothing`を欠くと、メモリ上に「幽霊レコードセット」が蓄積され、最終的に `Out of Memory` または `Too many active users` エラーを誘発する。

4. レガシー環境への配慮とシステム間連携

もし君が、20年近く稼働しているレガシーなAccessシステムを保守しているなら、`Bookmark`の挙動には細心の注意を払わなければならない。

Deleted Recordの罠: メインフォームでレコードが削除された直後に同期を試みると、存在しない`Bookmark`を参照し、ランタイムエラーが発生する。必ず `If Not rsMain.EOF Then` による生存確認を行うこと。
ネットワーク遅延: 分散トランザクション（SQL Server等へのリンクテーブル）を使用している場合、`Bookmark`の移動はネットワーク越しのポインタ操作となり、レイテンシが増大する。この場合、`Bookmark`ではなく、一意の主キー（Primary Key）を用いた`FindFirst`による検索に切り替えるのが、アーキテクトとしての賢明な判断だ。

結論：支配者の視点

UIの同期を「Accessがやってくれること」と考えるうちは、ジュニアの域を出ない。
「どのタイミングで、どのメモリ領域のポインタを、どのように安全に転送するか」を設計すること。これこそが、大規模業務システムを支えるエンジニアに求められる真の技術である。

`RecordsetClone`を使いこなし、Windows APIで描画を制御し、オブジェクトのライフサイクルを完全に掌握せよ。その先にのみ、真にストレスのない、極限まで洗練されたユーザーインターフェースが存在する。