global total for report+2 subreports

edited December 2014 in Subreports

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:

............................... 50
............................... 50
summaryband ................. 100
...................... 25
...................... 25
summaryband ............. 50
............. 15
............. 15
summaryband ........... 30

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

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


  • edited December 2014
    I'm on Delphi XE7 and RB 12.something (where can I find the the version

  • edited December 2014
    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.

    Best Regards,

    Nico Cizik
    Digital Metaphors
  • edited December 2014
    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,

  • edited January 2015
    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 =

    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.


  • edited January 2015
    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.

    Best Regards,

    Nico Cizik
    Digital Metaphors
  • edited January 2015
    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:


    ... 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).


This discussion has been closed.