首先，如果 pass-through query 与ODBC驱动程序一起使用，则Access本身不会尝试解析查询，而只是将其发送到数据库 via the ODBC driver . 通过这种方式，可以使用服务器理解的本机SQL方言提交查询 . 这允许提交Access无法自行执行的专门和/或高度优化的查询 . 此外，此类查询还可以引用未链接到Access的服务器表（和其他对象） .
对于"normal" Access查询（不是传递），Access数据库引擎将尝试根据自己的功能解析，解释和优化查询 . 这样做，Access将构造一个或多个查询，它将发送到服务器 also via the ODBC driver . 从服务器接收数据后，它将对数据应用所有剩余连接和条件，以满足整体SQL语句 - 这由Access本地完成，独立于远程服务器 .
1 回答
首先，如果 pass-through query 与ODBC驱动程序一起使用，则Access本身不会尝试解析查询，而只是将其发送到数据库 via the ODBC driver . 通过这种方式，可以使用服务器理解的本机SQL方言提交查询 . 这允许提交Access无法自行执行的专门和/或高度优化的查询 . 此外，此类查询还可以引用未链接到Access的服务器表（和其他对象） .
对于"normal" Access查询（不是传递），Access数据库引擎将尝试根据自己的功能解析，解释和优化查询 . 这样做，Access将构造一个或多个查询，它将发送到服务器 also via the ODBC driver . 从服务器接收数据后，它将对数据应用所有剩余连接和条件，以满足整体SQL语句 - 这由Access本地完成，独立于远程服务器 .
正如其他人评论的那样，有时Access可能足够聪明，可以指示远程服务器执行某些连接或应用某些条件（例如WHERE条件），但Access引擎不够智能，无法始终选择最佳优化 . 当查询包含来自Access表和远程表的源表时尤其如此 . 这些限制正是传递查询作为选项存在的原因，因此程序员可以干预向服务器发送优化查询，然后使用其他Access查询执行其他联接和条件 .
因此，发送到服务器的任何查询都必须通过ODBC驱动程序 . ODBC驱动程序将对语句进行一些初始解析是正确的，这样它就可以处理参数等，但 statement parsing is only the beginning of an efficient database operation . 数据库引擎存储有关索引，约束，关系等的详细信息 . 它使用这样的元数据来有效地检索，组合和排序数据，但它通过将元数据与表一起存储来实现 . 因此，远程服务器将拥有Access无法使用的远程服务器上的所有元数据 . Access和SQL Server（以及任何其他RDBMS）具有不同的数据库引擎，并且不用于交换底层元数据（例如索引，约束 - 如前所述） . 值得注意的是，有时可以指定最小的信息（如主键）来帮助Access更有效地使用远程表，但这实际上是最小的，并且不能提供有保证的有效数据操作 .
回应关于查询效率的评论“毕竟这些年”......
事实上，Access主要是一种较旧的技术，具有主要为本地数据库构建的非常基本的关系数据库功能 . 它从未被设计为针对远程数据操作进行优化 . 此外，Access和SQL Server（或任何其他RDBMS）的底层数据库引擎不兼容 . 它们各自都有自己的方式来存储数据和元数据 . 唯一的互操作性来自您熟悉的SQL语句，并在前面的段落中讨论过 . 没有标准的SQL术语来交换必要的复杂元数据，以完全优化Access和远程服务器之间的查询，至少不超出标准的JOINS和WHERE条件 .
但是，多年来期待取得进展是完全合理的 . 高级数据库服务器 - 包括SQL Server - 确实支持跨远程服务器复制数据表和其他对象的方法 . 在这种情况下，可以制作高效的查询，从分布在多个服务器上的表中请求数据 . 因此，对进步的期望的最终答案将是取代像Access这样的旧技术，并实现更新，更复杂和更强大的数据服务器 . 这并不意味着对Access的轻微影响，只是意识到即使在多年后Access也不会发生太大变化 . 正在更新新的数据存储和检索技术，而不是Access .