Rather than specifying architecture, why not describe the environment and requirements for the report?
I doubt that Crystal supports what you intend, but one can only guess since you post less than a sentence to describe requirements, not even your software version.
You might use a controlling application to take the output parameter and pass it to Crystal as a data source, again, hard to guess...
Again, you are specifying architecture without understanding how Crystal works, nor describing what you need.
Crystal expects a single data source per report.
And the above would NOT crush bandwidth unless it's improperly designed.
So one common method would be to create a standard subreport which gets inserted into every report (build out a generic template which already has it in there), and just use the SQL in an add command rather than bothering with a sproc, it's not going to be any faster using a sproc for this sort of SQL. But a sproc will work.
You can also include it in your data being returned (which could crush performance), or create a SQL Expression, but either will cause it to be returned multiple times.
It's not database intensive, so just create the subreport, it also will promote reusability.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.