Just wondering, because if the report joins to the table(s) it could be dealing with filtering a lot of data out, but a stored proc would do that, and perhaps more effeciently as you can specify the joins and reduce the number of records for each step, and your SQL software is optimized to perform such operations (use each software to its strength).

 

If the report is already coming from a stored proc, does it significantly longer to just run the stored proc than to create the report (after all if the stored proc takes 5 minutes to run, report is not going to be any faster) in which case, the goal would be to speed up the stored proc (just did this myself after a yr of putting it off...so much faster, was worth the effort).

 

I know I didn't answer the original question, as I really don't know...my concerns are usually about getting the data as fast as possible, CR creation/formatting of the report is something I really haven't bother with (and some of my reports are 1000s of pages, but they don't take too long to retrieve)

 

HTH

My two cents, I like lockwelles approach if you can do it. The more I limit and massage the data in SQl (as long as I don't screw that up) the faster the report runs. If you have run time params if you can pass them into a stored proc you may see huge increases. If you can't do that maybe you can use a view that prelimits the data some for specific reports and returns warnings if the user goes outside your predefined data set (view). I have one table that has several million rows and most of the reports that query it require user params at runtime (usually date ranges). Running against the table when it is joined to other tables in can take several minutes. Passing params through a stored proc can reduce it to under 1 minute easily.

As lockwelle said try to tease out how much time it takes to query the data on your DB side versus crystal to calculate and render. You may have to tweak on both sides of it.

 

Either way do not use "page n of m". It drags that report into a molasses pit with that many pages. Just use page number if needed.

I do not believe the group tree matters either way. Perform Grouping on server should be True, Use indexes on Server for Speed should be true.

Not bad if you have a 10 page report and no subreports but really bad for anything substantial.

It is too bad because a lot of managers like that on the report.

I just ran a test on it (because I realized I have old reports that use this and probably shouldn't)and a 12 page report with several subreports that was using N of M it took about 13 seconds to render and the same report without using it took about 8 seconds.