我使用SQL Server迁移向导将所有表传输到后端MS-SQL Server。其他对象（如表单，报表和查询）仍在我的Access Front-End中。我当时正在考虑将包含多个表和联接语句的复杂查询转换为直通查询，但是我的一些讨论文章建议将查询存储在SQL Server中，而不是使用直通查询或将查询保留在MS Access中。
为什么在SQL Server上进行查询是一个好主意？真的比使用传递查询好吗？
答案 0 :(得分：3)
使用传递查询（PT）或视图意味着在两种情况下，SQL都是服务器端的。因此，使用PT查询，视图和从Access调用存储过程之间在性能上并没有真正的区别。
PT查询的主要缺点是它们是只读的。因此，VBA代码和表单无法基于PT查询更新某些内容。
但是视图是可更新的，性能是相同的。
如果要通过表格链接直接将表格绑定到SQL Server上的表格（例如具有100万行），则这种设置很好，如果启动时始终使用标准VBA where子句打开表格表格。
由于访问表单是基于一个表（和一个要编辑的记录）的，因此在这种情况下，通过使用PT查询，视图，存储过程或仅使用标准的SQL Server链接表，您将获得零性能。没有性能优势。
但是在您的问题中，您提到了带有多个表/联接等的“复杂” SQL。
在这种情况下，PT查询适合于报表，并且可能使用某种“显示”搜索数据的形式等。但是，用于编辑的形式必须是视图或链接表。如上所述的PT查询是只读的。
由于99％的表单都基于一个表，因此将链接表继续使用到SQL Server会很好（只是记住上面的规则，总是将这样的表单打开到一个记录中）。
因此PT查询和视图实际上是同一件事–它们都在服务器端运行。唯一真正的区别是您不能存储PT查询服务器端，但可以存储视图。因此，“视图”实际上非常类似于访问中的本地保存查询-与PT =只读相比，它是读/写的。
因此，对于报表而言，可以省去设置pt查询的麻烦，但是对于参数和过滤，发现视图是更好的选择。 （因为如果您有该报表的现有VBA过滤器代码–可以保持不变，并且仅遵守满足该过滤器的记录（where子句–而不是实际的报表过滤器）。
请注意，如果表单或报表基于一个表（一个链接表），Access会做得很好。在这种情况下，Access只会在您打开报表或表单时下拉满足您提供的“ where”子句的记录。
对于基于Access中复杂查询的报表，这意味着将查询转换为SQL Server侧视图，然后将报表链接到该视图以代替查询。很好，因为如上所述，您的过滤器将像以前一样工作，并且您无需经历设置PT查询的所有麻烦，而创建PT查询通常会更麻烦，然后创建该视图。
因此，PT查询并不比视图好，也不比它快，但是该视图具有多个优点。它倾向于意味着Access客户端中的代码没有任何变化，并且如上所述，视图是读/写的，而不是PT查询是只读的。
因此PT和视图都在服务器端运行，但是为了便于开发和访问端代码中的最少更改，则视图往往是更好的选择，此外，如前所述，PT查询未存储在服务器端，但是当您将PT查询发送到服务器时，肯定会在服务器端运行。