Jet 很可能会将整个事情交给 SQL Server,后者将执行索引连接,然后执行更新。换句话说,对于像您的示例这样的简单查询,这一切都在服务器上完成,没有一个字节被拉过网络进行本地处理。
让 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#
Once Jet has received from the server only the rows that match the criteria, it will only then format the date field using the Access Format() function. This also works with JOINs, especially joins on indexed fields (though non-indexed field joins will probably also be handed off to the server).
Now, sometimes Jet does guess wrong and ends up being incredibly inefficient. In those cases, you can set up views and stored procedures on the server and use passthrough queries to make sure that Jet's wrong guesses will be avoided.