Are you opening a query in the window so you display all the rows in both
your vba version and the one with the correlated subquery?
You may be comparing apples and oranges if you're measuring the display
time
and calculating time for the vba function on a small subset of rows, but
measuring the time for the correlated subquery to calculate and display
*all*
rows. If you have a single column calculated by a custom vba function in
a
query you open in a window, Jet will use the vba function only on the rows
that are currently showing. Calculating for a small portion of the rows
is
going to be much faster that calculating for all the rows.
You can tell if that's happening by scrolling up and down rapidly in the
datasheet after the query is finished. If there's a drag while you're
scrolling in the vba version query, Jet is calling your vba function again
for every row showing in that window, but didn't calculate for every row
in
the table like the correlated subquery one did.
Chris
Microsoft MVP
Well I'm using an API timer for VBA. VBA can determine 10K occurrence
numbers in about 6 seconds, while the query takes a 1 minute 20 seconds
(used a stopwatch for that).
To avoid screen refresh issues and make the timing more concrete, I
modified
the query to return the COUNT:
SELECT Count((SELECT COUNT(*)+1 FROM Table1 t2 WHERE t2.KeyValue =
t.KeyValue AND t2.KeyId < t.KeyId)) AS Expr1
FROM Table1 AS t;
16K rows took 15 seconds in VBA to generate occurrence numbers for, and 3
minutes 34 seconds in SQL. I suppose technically some time may be deducted
due to the aggregation of the occurrences and environmental differences
between SQL and VBA but nevertheless VBA is vastly faster for this
purpose.
Again I'm surprised. Prior to this I thought Access would blow away my
procedure.
That is surprising. What code are you using to compare running times?
[quoted text clipped - 7 lines]
takes
way way longer. Surprisingly, VBA is faster in all cases.