Footer Calculation Anomaly

rbuser

- I have a simple report that consists of two groups: Major, Minor
- The Detail band is not used.
- The Footer for the Minor Group contains a TppDBcalc ("Count") that counts
items.
- A ppVariable in the Footer for the Minor Group calculates the percentage
of the Minor Group that the "Count" represents. This is accomplished by
using a TppDBCalc ("Total") in the header for the Major Group that counts
items and using ("Count".Value / "Total".Value) * 100 in the OnCalc event.
"Total" is reset by the Major Group and LooksAhead.
- All calculations are correct except for the first firing of the Minor
Footer within the Major Group; it always shows a percentage of 100.


Example
----------
Major Group Header (hidden)
"Total" = 20
Minor Group Footer
Key "Count" "Percent" = 1 10 100%
Key "Count" "Percent" = 2 5 25%
Key "Count" "Percent" = 2 5 25%
Major Group Footer
"Group Count" = 20

The error would seem to be a timing issue but I can't see what is causing
the problem. "Total", "Count", and "Group Count" always show the correct
values. Any help would be appreciated.

nicocizik

Hi Tom,

Take a look at the following rbWiki article on making calculations with a
lookahead value. Perhaps this will help you get the correct value.

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

--
Regards,

Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com

rbuser

Nico,

I still get the same values. The problem is only related to the first Minor
Group Footer which always is the same value. All other Minor Group Footer
calculations are correct.

nicocizik

Hi Tom,

Which version of ReportBuilder and Delphi are you using? Try tracing into
the OnCalc event and see what values are being used for the first firing.
My guess is that the total lookahead value is incorrect for some reason.

If possible, please send a simple example that demonstrates the issue that I
can run on my machine in .zip format to support@digital-metaphors.com and
I'll take a look at it for you.

--
Regards,

Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com

rbuser

Hi Nico,


I am using Delphi 7 / ReportBuilder 7.04


Your guess is correct (and all calculation are incorrect except for the last
Minor Footer entry). What is happening is that the lookahead value only
includes the portion of the dataset that has been processed when the Minor
Footer fires (rather than the total for the entire Major Group. I think this
is easier to follow with an example (eliminating everything except the
values used in the calculation):

Major Group Header (hidden)
"Total" = 20 <=== After report completion
Minor Group Footer
A "Count"= 5 <=== "Total" used in OnCalc = 5, yielding 100.00%
B "Count"= 6 <=== "Total" used in OnCalc = 11, yielding 54.54%
C "Count"= 5 <=== "Total" used in OnCalc = 16, yielding 31.25%
D "Count"= 4 <=== "Total" used in OnCalc = 20, yielding 20.00%
Major Group Footer
"Group Count" = 20

All the Minor Footer lines are incorrect except that for D. What would make
the "Total" grow incrementally rather than provide the entire count as the
final report shows?

nicocizik

Hi Tom,

When using lookahead values, the value is calculated during the first pass
of the report, and then used during the second pass. It seems for some
reason, for the first group, the total calculation is not accumulating the
total amount but rather the group total.

If you can put together a simple example demonstrating this issue, I can try
running it with the latest version of ReportBuilder here and see if the
problem still exists. Send the example in .zip format to
support@digital-metaphors.com in .zip format.

--
Regards,

Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com

rbuser

Nico,

Putting togeher a demo will be difficult but I will try. I would correct one
thing in your response - the lookahead total is wrong for all groups except
the last Minor. Note that it grows incrementally with the new group total
being added to the last group total.

I have used lookahead values in other instances without a problem so there
must be some quirk in this particular usage.