Forum Discussion
The return of the performance leak - this time with subreports
Understood but as I say when I did link the report /subreport fields there was no degradation at all even after multiple tests.
Anyway, I alerted the Access team to your 2508+ ACCDE issue in your other thread. In my tests, it doesn't need to be loaded as a library database in 2507 to get the error.
Just trying to run the code directly in the ACCDE causes the compile error.
I see. I can reproduce your findings. However, this appears to be due to the low number of rows shown in the subreport (if you link nr to nr, you have only one row in the subreport), not due to the link itself.
I did some more tests:
- If I have only one row in the subreport, I cannot reproduce the problem.
- If I have two rows in the subreport, the problem can be reproduced, but slowly (0.2 -> 0.6 sec after 1000 iterations).
Here are some repro instructions for a linked subreport:
1. Prepare repro example as above.
2. Add a linking field to the number table that maps 10 numbers to one "main nr":
CurrentDb.Execute "ALTER TABLE numbers ADD COLUMN main_nr INTEGER"
CurrentDb.Execute "UPDATE numbers SET main_nr = ((nr - 1) \ 10) + 1"3. Link the subreport control from "nr" (main report) to "main_nr" (sub report) [sic, main_nr acts as the "foreign key"]. This causes each row in the main report to have 10 subreport rows.
4. Execute the repro loop with 200 instead of 40 iterations. The time required increases from 0.2 to 0.7 seconds on my machine.