I have a Quick Report that gets its data from a few TQuerys and although the report is only 19 pages long, it takes me 2 hours to see the preview of all the pages! I have some complicated computations in the report and I use quite a few variables to do achieve this. My report doesnt merely captures the data from the database but requires these computations to be done at runtime. Is this causing my report to be slow? Is there any way I can speed things up?
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 Rhinorhino on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
How to speed up Quick Report processing?
- Thread starter skss
- Start date
skss,
It sounds like that might be a likely culprit.
In my experience, it's best to handle this sort of processing a little differently:
1) Select the matching records and create some spare fields in the answer tables for the calculations. Use typecasting in the SQL query to ensure the proper datatype.
2) Loop through the record matches, perform the calculations, and store the results in the fields you created with your query.
3) Create an instance of your QuickReport.
The idea here is to reduce the amount of time needed to render a page of data. If you move the work to a different place, you can optimize the processing time.
Also, make sure your queries are optimally designed. For example, make sure you're not running a query for each record on your report page. If you are, that's probably what's chewing up your CPU cycles.
Also, it sometimes helps to rework your queries to index-based appropraches. For example, see if you can use SetRange() instead of a select query. If you can, that may dramatically improve performance.
A lot depends on the specific design you've put together and the conditions it's running under. What may be perfectly adequate for a single user application may need far more time to run in a multi-user situation, especially if the data's being modified while you're running your report.
Hope this helps...
-- Lance
It sounds like that might be a likely culprit.
In my experience, it's best to handle this sort of processing a little differently:
1) Select the matching records and create some spare fields in the answer tables for the calculations. Use typecasting in the SQL query to ensure the proper datatype.
2) Loop through the record matches, perform the calculations, and store the results in the fields you created with your query.
3) Create an instance of your QuickReport.
The idea here is to reduce the amount of time needed to render a page of data. If you move the work to a different place, you can optimize the processing time.
Also, make sure your queries are optimally designed. For example, make sure you're not running a query for each record on your report page. If you are, that's probably what's chewing up your CPU cycles.
Also, it sometimes helps to rework your queries to index-based appropraches. For example, see if you can use SetRange() instead of a select query. If you can, that may dramatically improve performance.
A lot depends on the specific design you've put together and the conditions it's running under. What may be perfectly adequate for a single user application may need far more time to run in a multi-user situation, especially if the data's being modified while you're running your report.
Hope this helps...
-- Lance
- Status
Similar threads
- Locked
- Question
- Locked
- Question