おそらく Jet はすべてを SQL Server に引き渡し、SQL Server はインデックス結合を実行してから更新を実行します。言い換えれば、あなたの例のような単純なクエリの場合、すべてサーバー上で行われ、ローカル処理のために 1 バイトも引き出されません。
Jet にテーブル全体を引っ張らせるのは非常に簡単です。最も簡単な方法は、Access 式を WHERE 句に入れることです。これが発生する原因となる例を次に示します。
WHERE Format(MyDate,"YYYY") = 2008
Access がテーブル内のすべての日付に対して Format() 関数を実行できるように、テーブル全体を取得する必要があります。また、インデックスを使用できないため、非常に遅くなります。Jet のバックエンドでも速度が低下しますが、それは単純に効率が悪いからです。この WHERE 句を記述する適切な方法は次のとおりです。
WHERE MyDate Between #1/1/2008# And #12/31/2008#
保存された Access クエリにそれを記述すると、処理のために SQL Server に渡されます (バックエンドのデータベース エンジンが Jet SQL が使用するものとは異なるものを使用している場合、ODBC は適切な区切り文字を送信します)。
しかし、そのようなことをしていなければ、ネットワークを介して大量のデータを取得するという問題に遭遇する可能性はほとんどありません。実際、Jet は非常にスマートであり、可能な限り多くのクエリをネットワーク経由で送信して処理するという非常に優れた仕事をします。たとえば、SELECT ステートメントで Access 関数を呼び出すと、Access 関数を含まない基になる選択がサーバーに送信され、結果セットに対して Access で関数が実行されます。このアクセス クエリの場合:
SELECT Format(MyDate,"MM-DD")
FROM MyTable
WHERE MyDate Between #1/1/2008# And #12/31/2008#
Jet はこれをサーバーに送信します。
SELECT MyDate
FROM MyTable
WHERE MyDate Between #1/1/2008# And #12/31/2008#
Jet がサーバーから条件に一致する行のみを受信すると、Access Format() 関数を使用して日付フィールドをフォーマットします。これは、JOIN、特にインデックス付きフィールドの結合でも機能します (ただし、インデックス付きでないフィールドの結合もおそらくサーバーに渡されます)。
現在、時々、Jet は間違った推測をしてしまい、信じられないほど効率が悪くなってしまいます。そのような場合、サーバー上でビューとストアド プロシージャを設定し、パススルー クエリを使用して、Jet の誤った推測を回避することができます。