我的客户正在使用MSAccess读取SQL Server数据。
最初,他们创建了一个到SQLServer基表的链接表,然后在Access中创建了一个聚合和筛选的查询。
Select f1,f2,sum(f3),sum(f4)
From linkedtablename
where fx = 'somevalue'
group by f1,f2
出于安全和性能的原因,我在MSSQL中构建了一个简单的查询来进行过滤和聚合,并要求用户使用直通查询来指向该查询。
所以现在他们让和ODBC 'passthroughquery‘执行'select * from MSSQLview’
然而,当我们对这个直通做任何事情时,MSAccess似乎真的很困难。例如,将直通添加到新的MSAccess查询窗口需要花费很长时间。似乎每次我们与Access交互时,Access都会对源或源元数据进行一些繁重的读取。
对直通运行select也需要一段时间...但是,由于聚合是由MSSQL完成的,它应该快得多!?
所以问题是,为什么MSAccess会如此挣扎?Access是否试图在没有显式“select”执行的情况下分析源数据?或者它试图在我们每次与Passthrough交互时读取元数据?
最终,我希望有一些配置设置,可以强制Access将其视为一个“标准”表!
发布于 2020-10-16 01:40:07
如果您使用PT查询,请记住,如果您将其用作客户端查询的源,则可以使用零额外筛选,否则将起作用。
换句话说?
PT查询是拉取数据的最快(高性能)方法之一。但仅当您不尝试添加其他筛选时。PT查询不能被客户端过滤(好吧,它可以,但只有在拉取PT完整的查询源之后)。
结果?
使用链接视图。它们的性能与存储过程和PT查询一样好,但是它们可以而且确实尊重客户端过滤。因此,例如,您可以针对具有条件的链接视图构建客户端查询,并且只有与该查询匹配的记录才会被拉到网络管道中。
这似乎有点违反直觉,但PT查询速度很快,但它们不考虑客户端的额外过滤器(具体地说,您可以针对pt查询进行过滤,但Access仅在提取PT查询中的所有记录后才执行此操作)。因此,应该说避免使用PT查询来填充组合框,或者任何其他客户端将并确实尝试应用额外的筛选和条件。
说得一清二楚:
PT查询是很好的,但前提是您首先要让PT查询进行过滤。可以进行额外的过滤,但前提是原始PT查询一开始并没有提取大量数据。因此,PT查询的行拉取是您将获得的客户端。
在99%的情况下,最好是将查询放在一个链接视图中,这样您就可以自由地对该视图(甚至是客户端)进行筛选和添加条件,并且只有满足条件的记录才会被拉到网络管道中。这甚至包括在该链接视图上使用客户端查询。这还包括基于该链接视图创建报表,并假设您让VBA向该报表添加/提供"where“子句。(在这种情况下,Access将再次根据该条件提取记录。如果对报告使用PT查询并尝试过滤,则仅在提取所有PT记录后才会进行过滤。
因此,PT查询不能有效地将带宽需求降低到比PT查询最初返回的更低的任何值。然而,链接视图确实允许并尊重应用的额外过滤器-即使客户端完成了。因此,除非PT查询具有预先定义的和预先知道的标准,否则PT查询并不是那么有用。
因此,我强烈建议您尝试/测试/使用链接视图。
换句话说,将sum和group by放在服务器端视图中并链接到该视图。
Edit:您可以针对该视图将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查询是解决方案,但在大多数情况下,它不是。
https://stackoverflow.com/questions/64371958
复制相似问题