Saving main report - prompted to generate subreport data

[mmwchac]

I am using Crystal 9. I have a report that contains one subreport. After the main report preview is complete, I try to save the report and I get a message that says all the data has not been generated for saving (something to this effect) and do I want to generate the data? I hit yes and it appears that the subreport is reading additional records. And it takes forever! I have never run into this before. Does anyone know what might cause this behavior? When I turn this report over to the user, I don't want them to have to deal with that. Obviously, Crystal needs to do this for whatever reason but I am can't figure out why I haven't seen it before. Or maybe I haven't noticed.

??????

Thanks!

 

[synapsevampire]

Subreports are slow, and since you shared nothing technical about it (where is it in the main report, what is it linked by, etc.), it can't be properly diagnosed, however a laudry list of possibilities can be given.

First, turn off the File->Save Data With Report

Next, check the eport->Section Formulas->Record in the subreport to verify that all filtering is being applied, and then check the Database->Show SQL Query to make sure that all of that criteria is being passed to the database.

These should improve performance significantly, if not, post something about the layout of the report, type of database/connectivity, and why you're using a subreport as they should be avoided whenever possible as they result in additional queries against the database.

For instance if the report is grouped by an entity, and the subreport is in the group header/footer, it will rerun that subreport for every entitiy in the main report.

If a subreport is in the details, it will rerun the subreport for every row in the main report.

-k

 

[mmwchac]

The subreport is in the group footer of the main report. It is linked by account number. I know they are inefficient and I know it will run for every group footer instance but in this case it couldn't be avoided. Subreports are available as a workaround when certain data can not be accessed in the main report and sometimes you have no choice.

The database I am working with does not use SQL so there is really no way to optimize the running of the subreport. Maybe that is the real source of the performance problem.

Thanks, anyway.