Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
docmd.openreport stdocname,acpreview 1
- Thread starter kingz2000
- Start date
-
1
- #2
- Thread starter
- #3
Here it is:
stDocName = "QComp_Report"
DoCmd.OpenReport stDocName, acPreview
DoCmd.SendObject acSendReport, stDocName, acFormatSNP
DoCmd.Close acReport, "QComp_Report"
I must say, the queries are quite complex on the report, considering several diagrams are included, but still!
Kingsley
It's difficult to say exactly where things are bogging down.
It could be, as you suggest, the complexity of the queries populating the report. It could be subqueries involved. It could be the drawing of the diagrams.
Some things you might try...on a copy of the database...
1. Comment out the 2 lines following the Preview line in your code (to see if the formation of the SNP is slowing things down)
2. Rebuild things, piece by piece, testing as you go, to see what part of the process is creating slowness.
Notes from a book I have...to speed up the production of reports...
1. Create indexes on all query columns used in ad hoc query joins
2. Include as few columns as possible in the result set, avoiding fields not used in the final output of the report.
3. Move expressions to the report
4. Use Count(*) instead of Count([column])
5. Use the Between operator rather than open-ended >, >= and <= restrictions
6. Avoid situations in which one query pulls the data from tables and a second query just filters the data. The more information you can pull together in one query, the better, as one query uses less memory.
7. If using subreports, if the main and subreport's record source are the same, try rethinking your design so you can work without the subreport.
8. Use subreports to replace multiple expressions that call domain functions such as DLookup or DSum. On the other hand, if you need to look up only a single value, using a domain function may be faster.
Don't know if any of this applies, but thought I would include it anyway.
Tom
It's difficult to say exactly where things are bogging down.
It could be, as you suggest, the complexity of the queries populating the report. It could be subqueries involved. It could be the drawing of the diagrams.
Some things you might try...on a copy of the database...
1. Comment out the 2 lines following the Preview line in your code (to see if the formation of the SNP is slowing things down)
2. Rebuild things, piece by piece, testing as you go, to see what part of the process is creating slowness.
Notes from a book I have...to speed up the production of reports...
1. Create indexes on all query columns used in ad hoc query joins
2. Include as few columns as possible in the result set, avoiding fields not used in the final output of the report.
3. Move expressions to the report
4. Use Count(*) instead of Count([column])
5. Use the Between operator rather than open-ended >, >= and <= restrictions
6. Avoid situations in which one query pulls the data from tables and a second query just filters the data. The more information you can pull together in one query, the better, as one query uses less memory.
7. If using subreports, if the main and subreport's record source are the same, try rethinking your design so you can work without the subreport.
8. Use subreports to replace multiple expressions that call domain functions such as DLookup or DSum. On the other hand, if you need to look up only a single value, using a domain function may be faster.
Don't know if any of this applies, but thought I would include it anyway.
Tom
- Thread starter
- #5
- Status
Similar threads
- Locked
- Question