Question

I have been using Allen Browne’s ConcatRelated function, and while it works fine when the data comes from a table, but it doesn’t work when the data comes from a query.

The green ‘running query’ bar appears for a few seconds, but then when it tries to display the data it shows only one field from the first row, runs very slowly and can take a few minutes to display the first screen of records. I’ve not managed to leave it long enough to complete the result set, have to shut down Access using the task manager.

Is the query getting run each time the function is called? That could explain why it takes so long but seems unlikely.

Is this a problem with the function, with the query that is calling the function, or the query that the source data is coming from?

Answer 1

Here is an example using that function in the Immediate window.

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

The function …

1. creates this SQL statement

   SELECT OrderDate FROM tblOrders WHERE CompanyID = 7

2. opens a Recordset based on that statement

3. loops through the Recordset adding each OrderDate value to its output string

IOW, ConcatRelated() performs quite a bit of work each time you call it. And when you call it as a field expression in a query, it has to perform all that work again for each row of the query’s result set.

In addition to that “fixed overhead”, ConcatRelated() may lead to an additional performance cost: Without an index on CompanyID, the db engine would have to use a full table scan of tblOrders to find the rows which satisfy the WHERE clause.

Your question asks about the impact of using a query instead of a table with ConcatRelated(). Then the function’s internal SQL statement will be:

SELECT OrderDate FROM YourQuery WHERE CompanyID  = 7

In addition to the performance challenges imposed by ConCatRelated() with a table, you risk 2 more which may dramatically increase the workload.

1. If YourQuery demands a lot of effort by the db engine, it must put in that effort to create each row of the parent query’s result set.
2. You increase the likelihood that the db engine will not be able to used an index for the WHERE clause in the function’s internal SQL statement. Even if there is an index on CompanyID in the underlying table source of YourQuery, the db engine may not see enough benefit from using it.

So while ConCatRelated() is useful, using it is costly. That’s not because of any design error in the function. Rather the nature of the task is just so expensive regardless of what approach you use to accomplish it. And asking that function to use a query instead of a table likely inflates the cost.