Groups
Hi
Please correct me if I'm wrong on the following statement:
(1) The developer has no choice but to use Report Builder's Grouping
function when the reports become complex and you have a great deal of
'foreign key referencing' (one query with lots of joins).
If you use Report Builder, the way to go would most likely be Master-Detail
Relationships in conjuction with Groups (not a huge query with lots of
joins). The problem I have with this is that a lot of sub-queries (because
of the Master-Detail relationships) will be excecuted - thus degrading
performance.
My question then actually is: Is there a way to generate complex reports by
executing one big query (with many joins) and still be able to show the
necessary aggregate information in footer and summary bands for groups of
data, WITHOUT using Report Builder's Group function (thats usually used with
Master-Detail Relationships).
This means that only one big query will be executed, and the report will be
generated (no subqueries will be executed - like when you use a
Master-Detail relationship type structure).
Thank You
Rico Koegelenberg
Please correct me if I'm wrong on the following statement:
(1) The developer has no choice but to use Report Builder's Grouping
function when the reports become complex and you have a great deal of
'foreign key referencing' (one query with lots of joins).
If you use Report Builder, the way to go would most likely be Master-Detail
Relationships in conjuction with Groups (not a huge query with lots of
joins). The problem I have with this is that a lot of sub-queries (because
of the Master-Detail relationships) will be excecuted - thus degrading
performance.
My question then actually is: Is there a way to generate complex reports by
executing one big query (with many joins) and still be able to show the
necessary aggregate information in footer and summary bands for groups of
data, WITHOUT using Report Builder's Group function (thats usually used with
Master-Detail Relationships).
This means that only one big query will be executed, and the report will be
generated (no subqueries will be executed - like when you use a
Master-Detail relationship type structure).
Thank You
Rico Koegelenberg
This discussion has been closed.
Comments
fired for every master record. In ReportBuilder's data access
workspace(DADE) only one query is sent to retrieve all of the detail
records, so it is more efficient. You can also link datapipelines outside
of DADE. Here is an example of this approach:
http://www.digital-metaphors.com/tips/LinkPipelinesNoDADE.zip
In ReportBuilder's master detail report configuration, you'll need to create
subreports (connected to detail data pipelines) to show the detail datasets.
Groups aren't only used in master-detail relationships, they can be used
whenever the data is sorted. You could get away without using groups, but
that may also depend on if you ever needed to control page breaks. There is
a page break component in RBAddOn tools if needed.
http://www.bancoems.com/rbaddon.htm Section style subreports start on a new
page by default and a title band in the subreport has a NewPage property as
well.
You could create a group even if you don't need the group header and group
footer bands. One reason for this would be that you could use dbCalcs and
the report engine will reset their values automatically for each group via
their ResetGroup property. In the page footer band, you can place dbCalcs
which can sum your subreport values.
If you don't use groups then you'll need to use TppVariables in the footer
band and code their OnCalc event handlers. The variable can be reset via
their popup timing dialog.
Cheers,
Jim Bennett
Digital Metaphors
http://www.digital-metaphors.com
info@digital-metaphors.com
Cheers
Rico Koegelenberg