Published:
11 May 2010
|
Abstract
I hate sub reports and always consider them the last resort in any reporting solution. The negative effect on performance and maintainability is just not worth the easy ride they give the report writer. Nine times out of ten reporting requirements can be met using a little forethought and planning (and a solid understanding of formulas).
With that said, there are a few novel ways of using sub reports which will not affect performance and actually prove a boon to the developer. |
 |
by Jason Dove
Feedback
|
Average Rating:  
Views (Total / Last 10 Days):
22039/
48
|
|
|
Introduction |
I hate sub reports and always consider them
the last resort in any reporting solution. The negative effect on performance
and maintainability is just not worth the easy ride they give the report writer.
Nine times out of ten reporting requirements can be met using a little
forethought and planning (and a solid understanding of formulas).
That said, there are a few novel ways of
using sub reports which will not affect performance and actually prove a boon
to the developer.
|
|
|
User Comments
Title:
RE: But Crystal could do this better
Name:
Ray S.
Date:
2010-11-23 11:39:27 AM
Comment:
To: Bill Geake
I'm sure others will weigh on the capability of passing parms from Main report to subreports based on SQL commands. Here's what I do:
1) In the subreport, when you are setting up the command in the "Modify Command" window, create a parameter, that has the same type as the calling parameter in the Main report.
2) From the Main report, right click on the subreport and select "Change subreport links...". Then link the Main report's parameter to the subreport's parameter.
Is this what you had intended to do? If not, sorry for confusing the issue.
RS
|
Title:
My Thoughts
Name:
PA
Date:
2010-11-23 5:37:51 AM
Comment:
Hi All,
With due regards and respect to the ideas that have been discussed, I failed to understand the "hatred" factor and the "3 New Uses For Sub Reports" concept.
Reasons: 1. Report Header: This is generally achieved with report templates
2. Reconciling Conflicting Groups: A single report cannot contain grouping based on multiple logics and combinations , so this is the obvious use of a sub report. I failed to understand, what's new?
3.Conditional Data Targets: As an alternative, this could be achieved by providing hyperlinks to individual reports by enabling the hyperlink(s) based on condition(s)
Your comments are appreciated.
PA
|
Title:
But Crystal could do this better
Name:
Bill Geake
Date:
2010-11-23 4:38:36 AM
Comment:
If only there could be a way of making it easy to pass values from the main report through to the sub report SQL. Jason hates sub reports; I hate selection formulae, and these hatreds are connected. The performance hit on sub reports isn't just the extra query per sub report instance - it's also the failure to filter data on the server and the increased network traffic that results.
Perhaps it's just my ignorance, but I've never been able to pass parameters to Oracle SQL in sub reports. If SAP could sort this out with an intuitive GUI it would make rich reports so much easier.
|
Title:
Mr
Name:
David WHite
Date:
2010-11-23 3:55:37 AM
Comment:
Amazing! They say the best ideas are really simple. I would never have thought of holding common components in a subreport. What a brilliant idea!
|
Title:
Mrs.
Name:
Preetha Raju
Date:
2010-11-22 9:25:33 PM
Comment:
Really, very useful tips. Specially header concept with the sub report, which I never thought.
Thank you very much, looking forward for more tips from you.
|
|
Product Spotlight
|
|