How does Crystal call subreports and is it configurable?

[olitvinov]

I wonder how Crystal calls subreports and if it’s multithreaded(or makes DB calls simultaneously).
I’m using Crystal XI. There is a main report with 6 subreports in it.
My concern is the speed of processing.
Each subreport would be pulled by Crystal by its own stored procedure based on a parameter.
So the question is if crystal makes multithreaded calls to all subreports or it makes sequential calls?
And if it’s sequential, can I configure it to be multithreaded to perform multiple simultaneous calls to DB?

I would appreciate any input or suggestion or best practices.
Thanks,
Oleg

 

[synapsevampire]

Yeah, subreports suck

Everything is doen sequentially, and it doesn't really matter that much, it still fires each and every query.

You don't state where the subreports are, what they are doing, the database used, so one can't advise you well.

If you have a subreport in a group, then each time that group changes, Crystal will fire another SQL statement.

Try to eliminate any subreports that cannot mroe readily be handles by an intelligently designed database object or an Add Command.

Perhaps creating ONE Stored Procedure, using a UNION or a temp table to generate a single recordset would prove the fastest.

-k

 

[olitvinov]

In my case I have 6 subreports(called by parametrized stored procs on each item change in main report).
They all are linked to main report by proc parameter.

there is no gouping in report(no need for it).
I tested main report on push model and subreports on pull model. Very slow.


So, I'm moving to push model for all(report and subreports). Having modified the sql statemets, I will only deal with 7 DataSets, which I am going to feed to report document using SetDataSource method.
The only concern with this approach is the time Crystal takes to display after all datasets are filled(I'm using crystalreportviewer control in ASP.NET)
I assume it's the time for joining together 7 tables.

Any more insights or comments?

 

[synapsevampire]

That sounds OK, note your first post made no mention of an application development environment being involved.

If the reports were in the details (you still didn't post where they are), then the SPs will have fired for every row in the main report, making it punishingly slow.

I have built relatively complex data sources that encompass everything in ONE query by using a UNION in an SP or a View, as in:

select 1 source, table1.val mainval, 0 sub1val, 0 sub2val, 0 sub3val, 0 sub4val, 0 sub5val, 0 sub6val
from table1
UNION ALL
select 2 source, 0 mainval, table2 sub1val, 0 sub2val, 0 sub3val, 0 sub4val, 0 sub5val, 0 sub6val
from table2
UNION ALL
etc.

Hopefully you get the idea, and now there aren't any subreports required. The source field identifies the origin, and then you just pull the values required for each equivalentr of a subreport section based on the source.

Hopefully this model suits your data and requirements.

Obviously without tehcnical information I can only guess at what you have and what you need, consider postng the requirements and data example in future posts.

-k