Access 2013 ODBC リンク テーブル と SQL Server - 2

作成した ODBC リンク テーブルを開いてみる。その時どのようなことが起きているか。
確認できるログは以下の通り。

SQLExecDirect: SELECT "dbo"."Table_1"."ID" FROM "dbo"."Table_1" 
SQLPrepare: SELECT "ID","F_Num"  FROM "dbo"."Table_1"  WHERE "ID" = ?
SQLExecute: (GOTO BOOKMARK)
SQLPrepare: SELECT "ID","F_Num"  FROM "dbo"."Table_1"  WHERE "ID" = ? OR "ID" = ? OR "ID" = ? OR "ID" = ? OR "ID" = ? OR "ID" = ? OR "ID" = ? OR "ID" = ? OR "ID" = ? OR "ID" = ?
SQLExecute: (MULTI-ROW FETCH)
SQLExecute: (MULTI-ROW FETCH)
SQLExecute: (MULTI-ROW FETCH)
SQLExecute: (MULTI-ROW FETCH)
SQLExecute: (MULTI-ROW FETCH)
SQLExecute: (MULTI-ROW FETCH)
SQLExecute: (MULTI-ROW FETCH)
SQLExecute: (MULTI-ROW FETCH)
SQLExecute: (MULTI-ROW FETCH)
SQLExecute: (MULTI-ROW FETCH)

大事なのは、1行目と4行目以降。

1 行目：SQLExecDirect 主キーのみ取得
4 行目：SQLPrepare 以降繰り返し使うSQLの準備
5 行目以降：10 個のパラメータに主キーを代入し実行
という感じ。
ログにはタイムスタンプがないのでわかりにくいけど、SQL Server Profilerと同時みみていると、
テーブルを開く（レコードソースが設定されたフォームを開くも概ね同意）とき、

（ダイナセット）

• ただちにすべてのレコードを取得するわけではない。
• カーソルが移動したときなど、必要な時にレコードを取得する。
• テーブルを開いて放置していると時間をかけてキャッシュが追加される、ただし、すべてのレコードを取得することはない。100 レコードぐらいまでの取得を実測した。
• カーソルが移動に合わせて先読みの感じで順次レコードを取得する。
• 取得（キャッシュ）したレコード数には限界がある、ただし使用上問題は考えられない。
• キャッシュから削除されたレコードは、カーソルの移動など実際に使用するときに再度取得する。

（スナップショット）

• ただちにすべてのレコードを取得する。

SQLExecDirect: SELECT "ID" ,"F_Num"  FROM "dbo"."Table_1" 

ログを見れば一目瞭然。