Forum Discussion
The return of the performance leak - this time with subreports
Anyone remember the v2405 bug that caused loading and closing forms to become slower over time?
We found something similar in the current release (tested with semi-annual 2508 (19127.20484)), just with sub reports instead of forms. Here are the repro instructions:
Repro instructions
Table
1. Create a "numbers" table with a PK field "nr" (Long Integer).
2. Fill it with the numbers from 1 to 100:
Dim i
For i = 1 To 100
CurrentDb.Execute "INSERT INTO numbers (nr) VALUES (" & i & ")"
Next iSub report
3. Create a new empty report in design view, using the "numbers" table as the record source.
4. In the detail section, add two text boxes "Text1" and "Text2" next to each other, both with the "nr" field as their control source.
5. Reduce the size of the detail section to one "row", containing just the two text boxes. Remove the page header/footer.
6. Add an Format event handler to the detail section with the following content:
Me.Text2.Visible = False7. Save the report as "sub".
Main report
8. Create another report "main", which contains nothing but the "sub" report as a subreport in its detail section. Set the record source of "main" to "SELECT * FROM numbers WHERE nr <= 10"
Reproduce problem
9. Create the following method in a module:
Sub report_loop()
Dim i As Long
Dim start_time As Single
Dim report_name As String
Dim path As String
report_name = "main"
For i = 1 To 40
path = Environ("Temp") & "\testreport.pdf"
start_time = Timer
DoCmd.OpenReport report_name, acViewPreview
DoCmd.OutputTo acOutputReport, report_name, acFormatPDF, path
DoCmd.Close acReport, report_name
Debug.Print Timer - start_time
Next
End Sub10. Run report_loop. Observe that each report export gets slower and slower.
Analysis
Compare the first and last number in the immediate window: on my machine it's 0.4s for the first report and 2.3s for the last.
Note that if you run report_loop again, it will start slow! In other words, each report export causes MS Access to "leak performance" that is only regained after restarting Access.
We were able to reproduce this issue with Microsoft 365 semi-annual channel, Version 2508 (19127.20484). I'll do more tests tomorrow and try different older versions to find out when this bug was introduced.
Workarounds
If you move the visibility code from the Format event to the Print event, the problem still occurs, but slower (0.4s -> 0.72s instead of 0.4s -> 2.3s).
The workaround that worked for us was to use =IIf(...) in the control source instead of modifying the visibility. Obviously, that only works for text boxes, not for lines or other controls.
6 Replies
Heinzi / Tom
Can I check the details of this bug report as I'm unclear why anyone would ever do anything like this in a real life situationIf I create the report / subreport exactly as described I also get a significant performance degradation with both .pdf and .txt output files. (tested in latest Beta v2602 build 19713.20000)
However I'm unclear why you would set both the report and subreport for the Numbers table (albeit with slightly different record source) without linking the main & subreport by the 'nr' field
When I add 'nr' as the linked master/child fields, there is no degradation.
Am I missing the point here?
- HeinziATIron Contributor
That's just a simplification to get "a lot of subreport rows", so that the problem can be reproduced faster. It also happens when the subreport is linked and (thus) has less rows, it just takes longer.
The real-life situation was that one of our customers tried to create hundreds of "start of the year" PDF invoices (based on a fairly complex Access report that displays usage data in a subreport). The process had to be interrupted because, after some time, the application visibly slowed to a crawl.
So, when trying to build a minimal repro example, I looked for ways to make this problem "happen faster", because both (a) creating the minimal example and (b) testing with different versions of Access get very boring very fast, if every test run takes a lot of time.
Apparently, the severity of the problem increases with the number of rows actually rendered on the subreport. Since exporting 40 reports with 1000 subrows is a lot faster then exporting 1000 reports with 40 subrows, I opted for the former.
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.
- Tom_van_StiphoutSteel Contributor
I can repro your issue using A365 MEC v2511.
When I comment out the DoCmd.OutputTo line, performance does not degrade.
If I change OutputTo to acFormatTXT performance DOES degrade even more dramatically.I will report this to MSFT.
- HeinziATIron Contributor
As promised, I tested different MS Access versions and was surprised to discover that this bug has been in the codebase for approximately 1.5 years:
- We can reproduce the bug with Current Channel v2407 17830.20138 and later versions.
- We cannot reproduce the bug with Current Channel v2406 17726.20160 and earlier versions.