Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Crystal 7 upgrade to 10

Status
Not open for further replies.

fancyface

IS-IT--Management
May 17, 2006
104
CA
I know we're behind the times as far as upgrades go! Our typical practise has been in the older version to create reports from tables with about 5 or 6 subreports. We may have subselects in our main report and we may have subselects in our subs. The world of commands in the newer version is very new for us. We have been used to editing the SQL for so long. I realize you can't do that in the newer versions.

I need some valuable advice. Is it better to stick with subreports or go the way of commands? It is not an option for us functionally to have views built for us or for us to build them ourselves. The DBA's do that and it's not an option we have available to us. But we're struggling with which typically is the better practise - subreports or commands? I would appreciate helpful feedback from some of you more seasoned folks out there. Thanks,
 
Subreports mean that anothrer query fires each time they are invoked, so performance can be an issue.

But sometimes subreports are required, especially if you have different datasets.

There is no generic answer here, but if you are unable to create Views, you can do the equivalent, in fact more, using a Command Object, and if the report is all based on the same dataset, then there's no valid reason to use a subreport, except perhaps to expedite development time, as reusing the data will prove faster.

-k
 
Thank you. We are finding performance an issue. What I'm concerned about is the left outer joins when linking our main report up to the commands. For example, we typically would have had a name type subreport. Some customers would have name type A and B. Some would just have A. So if we put our name type in a command, I don't want record to drop off that say don't have name type B. This is my worry in linking up commands that even though I have a left outer joint, I'm going to lose some records. Hope that makes sense. I thank you for your feedback. I completely agree with you that we're have significant performance issues with subreports in 10.
 
RhinoK demonstrated a neat technique at the BO conference last month where you could do SQL expressions to do a sub select. So only one hit at the DB, and a lot faster processing. I'm explaining that in more detail in our next issue of our Crystal Clear newsletter.

And I think you may be able do this in CR 7 as it has SQL expressions.

Create a SQL expression to grab your data, and enclose it in brackets to do the subselect. The SQL must return a single field in one record.

The jump from CR7 to a later version will have reports that will run faster. Some examples I found with the same report, ran 20 x faster with a newer version.

Editor and Publisher of Crystal Clear
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top