MS Access对传递查询进行SELECT的速度较慢

问题描述

我的客户正在使用MSAccess读取SQL Server数据。

最初，他们创建了一个链接表到SQLServer基本表， 然后在Access中创建一个汇总和过滤的查询。

Select f1,f2,sum(f3),sum(f4)
From linkedtablename
where fx = 'somevalue'
group by f1,f2

出于安全和性能方面的考虑，我在MSSQL中构建了一个简单的查询来进行过滤和汇总， 并要求用户通过传递查询指向该位置。

所以现在他们有了ODBC'passthroughquery'来执行'从MSSQLview中选择*'

但是，当我们使用此传递进行任何操作时，MSAccess似乎都很挣扎。 例如将直通添加到新的MSAccess查询窗口需要花费很多时间。 似乎Access在每次与之交互时都会对源或元数据进行大量读取。

对直通进行选择也要花些时间...但是通过MSSQL进行聚合，它应该快得多！！

问题是，为什么MSAccess挣扎这么多？ Access是否试图在没有进行显式“选择”的情况下分析源数据？ 还是在我们每次与Passthrough交互时尝试读取元数据？

最终，我希望有一些配置设置可以迫使Access将其视为“标准”表！

解决方法

如果您使用PT查询，请记住，如果将其用作客户端查询的源，则可以使用零附加过滤，或者可以使用。

换句话说？ PT查询是提取数据最快（高性能）的方法之一。但仅当您不尝试添加附加过滤时才可以。客户端无法过滤PT查询（可以，但是只能在提取PT完整查询源之后）。

结果呢？ 使用链接的视图。它们执行JUST以及存储过程和PT查询，但是它们可以并且确实尊重客户端过滤。因此，例如，您可以针对具有条件的链接视图来构建客户端查询，并且仅将与该查询匹配的记录下拉到网络管道中。

这似乎有点违反直觉，但是PT查询速度很快，但是它们不尊重客户端的附加过滤器（具体来说，您可以针对pt查询进行过滤，但是Access仅在提取PT查询中的所有记录后才这样做）。因此，最好说避免使用PT查询来填充组合框，否则客户端将并且确实会尝试应用其他过滤条件和条件的其他任何事情。

要清晰明了： PT查询很棒，但只有在要使用PT查询时，才首先进行过滤。可以进行其他过滤，但前提是原始PT查询一开始并没有提取大量数据。因此，拉取的PT查询行就是您要获取客户端的内容。

在99％的情况下，您最好将查询放在链接的视图中，因此，您可以自由过滤和向该视图添加条件（甚至是客户端），并且仅记录满足条件的记录在网络管道中。这甚至包括在该链接视图上使用客户端查询。并且这还包括基于该链接视图创建报告，并说您有VBA可以为该报告添加/提供“ where”子句。 （在这种情况下，Access将再次仅根据该条件提取记录。如果对报表使用PT查询并尝试进行过滤-仅在提取所有PT记录之后才进行过滤。

因此，PT查询不能有效地将带宽降低到比PT查询返回的值低的任何带宽。但是，链接视图确实允许并且确实尊重应用的其他过滤器-即使在客户端完成时也是如此。因此，除非PT查询具有预先定义的标准并且事先知道，否则PT查询并不是那么有用。

因此，我强烈建议您尝试/测试/使用链接的视图。

换句话说，将总和和分组依据放在服务器侧视图中并链接到该视图。

编辑：您可以针对该视图向该视图客户端添加where子句。

但是，由于Fx不是列，因此您必须将该列添加到视图中，或者创建一个存储过程，并以这种方式使用它：

CREATE PROCEDURE [dbo].[GetMyGroupSum]
   @fx nvarchar(50)
AS
BEGIN
   SET NOCOUNT ON;
   Select f1,f2,sum(f3),sum(f4)
   From dbo.TheTableToQueryOn
   where fx = @fx
   group by f1,f2
END

现在，在Access中创建一个PT查询。您的代码将如下所示：

dim strFX    as string
strFX = "somevalue"

currentdb.querydefs("MyPtQuery").sql = "EXEC GetMyGroupSum '" & strFX & "'"

您现在可以自由使用上述查询来生成报告，代码，甚至可以基于该PT查询启动表单。

在大多数情况下，最好使用视图，但是由于查询未返回您需要过滤的列，因此可以使用PT查询，但在大多数情况下不是这样。