global total for report+2 subreports

rbuser

Hi,

I have a report with 2 subreports. The report and the subreports each
have a total column. Below the last subreport I need a "general" total
which will be the sum of the above 3 totals.

The way I build the report is this. First subreport is created in the
report's summaryband. I also add a summary band to the first subreport.
The second subreport is created in the first subreport's summaryband. I
also added a summary band to the second subrept. On this summary band I
add a variable but it only shows the last subreport's total...

The subreports have BehaviorType set to pbChild and I was trying to use
the summary band veforegenerate or aftergenerate.
How can I do this right?


Sample output of what I want to accomplish:

mainreport
............................... 50
............................... 50
summaryband ................. 100
subreport
...................... 25
...................... 25
summaryband ............. 50
subreport
............. 15
............. 15
summaryband ........... 30


GENERAL TOTAL ................. 180


Lots of thanks in advance and Merry Christmas to all of ya
Lucian

rbuser

I'm on Delphi XE7 and RB 12.something (where can I find the the version
numbers?)

Regards,
Lucian

nicocizik

Hi Lucian,

Take a look at the following example/article on how to show a subreport
total inside the main report. You should be able to use this concept to
get the value you need for your "general" total.

http://www.digital-metaphors.com/rbWiki/Delphi_Code/Calculations/How_To...Display_Subreport_Totals_in_the_Main_Report

rbuser

Hi Nico,

I've seen those and tried some, somehow it didn't work form me. Still
though, I got it using the main report summary band AfterGenerate and
directly add from 3 variables which I keep references to. I'm now
fighting a bit with correctly positioning the "general total"
components, using the Anchors property and other tricks.

Thank you,
Lucian

rbuser

Nico and Lucian,

This article has caused us no end of trouble and headaches, even when we
adopted revised techniques suggested by Nard. The fact is that the
complicated decisions the report engine has to make about where to set
page breaks, how and when to print something on one page or the next and
so on, will inevitably create a scenario where a global variable being
updated by subreport totals will fail, normally with something being
added twice or not added at all. We have burnt hours and hours and hours
trying to solve it and it just isn't 100% reliable.

We now get around it with Calc fields on the Data tab in the main Query
View that are SUB-SELECT "Sums" on the data is also being used for the
subreports. So as well as a "Crewing" subreport and and "Transport"
subreport (for example) we also have in the main report's query Calc
fields like "TotalCrew" that consist of:


(SELECT SUM(c.Total) FROM Crew c WHERE c.Selected = True AND c.Job_no =
JOBS.Jobno)

The performance penalty is negligible and end users benefit by having
the appearance of real data field in the report rather than empty
variable components that are hard to make sense of, given the way their
data is retrieved / coded.

Hope this is useful to anyone.

Paul

nicocizik

Hi Paul,

What you have described is wonderful! This is exactly what we have been
trying to preach from the beginning and follows the Reporting Process
which is described in the first section of the Developer's Guide and is
shown at the top of our web site as an animation.

Data Access -> Data Process -> Report Layout -> Report Generation

Taking care of most/all data manipulation before the report generates,
will always be a more robust solution than trying to do so while the
report generates.

rbuser

Thanks Nico,

The Calc tab on the Data page is very powerful for this kind of thing.
We also write lots of stored procedures that we call from here that get
around all sorts of reporting headaches. So we have calc fields like
CustomerAddress that consists of:

GenerateAddressMemo(Jobs.Address1,Jobs.Address2,Jobs.Address3,Jobs.Town,Jobs.County,Jobs.PostCode,Jobs.Country)

... and hey presto we have a memo field available to the report that not
only displays a multi line address, but it also organizes order and
layout of the data to reflect how an address is displayed in different
locales (U.S. layout for an address is different to a U.K. one).