访问：ConcatRelated适用于表，但不适用于查询

Question

我一直在使用Allen Browne's ConcatRelated函数，虽然它可以在数据来自表时正常工作，但是当数据来自查询时它不起作用。

绿色“运行查询”栏会出现几秒钟，但是当它尝试显示数据时，它只显示第一行中的一个字段，运行速度非常慢，可能需要几分钟才能显示第一个屏幕记录。我没有设置足够长的时间来完成结果集，必须使用任务管理器关闭Access。

每次调用函数时查询是否都会运行？这可以解释为什么需要这么长时间，但似乎不太可能。

这是函数的问题，调用函数的查询，还是源数据来自的查询？

Answer 1

以下是在立即窗口中使用该功能的示例。

CompanyID = 7
? ConcatRelated("OrderDate", "tblOrders", "CompanyID = " & CompanyID)
12/11/2012, 12/12/2012, 12/13/2012

功能......

1. 创建此SQL语句

   SELECT OrderDate FROM tblOrders WHERE CompanyID = 7

2. 根据该声明

打开Recordset
3. 遍历Recordset将每个OrderDate值添加到其输出字符串

IOW，ConcatRelated()每次调用它时都会执行相当多的工作。当您在查询中将其称为字段表达式时，它必须再次为查询结果集的每一行执行所有工作。

除了“固定开销”之外，ConcatRelated()可能会导致额外的性能成本：如果没有CompanyID上的索引，则数据库引擎必须使用{{1的全表扫描找到满足tblOrders子句的行。

您的问题询问使用查询而不是使用WHERE的表格的影响。然后函数的内部SQL语句将是：

ConcatRelated()

除了SELECT OrderDate FROM YourQuery WHERE CompanyID = 7 对表格施加的性能挑战之外，还有2个风险，这可能会大大增加工作量。

1. 如果ConCatRelated()需要db引擎付出很多努力，那么它必须努力创建父查询结果集的每一行。
2. 您增加了db引擎无法在函数的内部SQL语句中使用YourQuery子句的索引的可能性。即使WHERE的基础表源中存在CompanyID的索引，db引擎也可能看不到使用它的足够好处。

因此虽然YourQuery很有用，但使用它会很昂贵。这不是因为函数中的任何设计错误。相反，无论您使用什么方法来完成任务，任务的性质都是如此昂贵。并且要求该函数使用查询而不是表可能会增加成本。