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.