OnCalc timing issue.

rbuser

I am having a problem with the OnCalc event of the TppVariable when the
group goes beyond the page. For example if I have a table with one field
that has a value of 1 for 80 records in the table. The report displays the
Value from this field in the detail band using a TppVariable component and
also sets adds to a second variable component to calculate the total for the
report (Summing up all the values for that field). At the end of the report
the total should show 80. What is happening is that the record that throws
the report onto the second page is getting calculated twice. Once when it
determines that the report needs a second page and once to print the record
on the second page. But this makes the value of the second variable
component (the total) 81 rather than 80. So this record added its value
twice to the total. This makes using the onCalc event for determining
report totals useless. Is there a way to fix this.

Thanks,
Richard Gostin

nicocizik

Hi Richard,

Which version of ReportBuilder are you using? This behavior has been
enhanced for the latest version (10.04). If you haven't already, try
downloading a trial copy of RB 10.04 and test with that. If you are already
using RB 10.04, please send a small example demonstrating the issue 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 have attached a sample program that demonstrates the issues we are having.
The first button displays a report that Just does a simple setting the value
of one variable from another on the same report. For some reason the first
record on each page causes the onCalc event to fire twice. The second
button displays a report where there is a subreport. The Value of the
summary field on the main report is set on its onCalc event where the timing
for the variable is the DataPipelineTraversal of the DataPipe.

Thanks,
Rich

nicocizik

Hi Rich,

For future reference, please send all attachments to
support@digital-metaphors.com.

In this case, you do not want to calculate every time the pipeline
traverses. The pipeline has no concept of when the report engine is going
to run out of space on a page so it will keep traversing even after a page
break.

If you are trying to show a grand total from a subreport in RAP, I would
suggest using the method used in the example below. This involves creating
a global variable that references a variable in the main report. Then,
inside the OnCalc of a variable in the subreport, you update the value of
the global variable, essentially updating the value of the variable in the
main report.

http://www.digital-metaphors.com/tips/RunningTotalInDetailSubreport.zip

--
Regards,

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

rbuser

Hi Nico,

This method makes me a little unconfortable. As shown in the first example
where there is no subreport using the onCalc does not seem reliable either.
In the example the onCalc was fired twice for the first record on each page.
The only method that I have found that seems to be fool proof is to use the
AfterPrint.

The problem is that at this time we have some 40 or 50 reports that use the
onCalc either as you mentioned within a subreport or as in my examples where
it calculates on the pipeline traversal or setting a second variable on the
same report. While these methods seemed reasonable to use at the time they
are obviously causing issues now. It is going to take us a decent amount of
time to identify every report that has this and convert them all. If you
could give us a global fix within Report Builder it would save us a lot of
time.

Thanks,
Rich

nicocizik

Hi Richard,

The OnCalc event is working as designed in this case. When calculating on
DataPipelineTraversal, the pipeline has no idea when the page will end so it
keeps traversing after a page break essentially firing the OnCalc twice for
the first record of the new page. The proper method to keep a grand total
outside a subreport is by using a global variable and calculating on
Traversal as I described in my previous post. This is the only way to
ensure a correct value.

--
Regards,

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

rbuser

Hi Nico,

I can except the DataPipelineTraversal issue but look at the report the is
displayed when the Without Subreport button is clicked. This report does
not use the DataPipelineTraversal and it still has an issue. This is using
the same method you are recommending to use but it still does not work. The
onCalc is setting the value for a variable on the same report as it is on.
But this onCalc is firing twice for the first record of every page. This
makes using the onCalc event unreliable also even when the timing is
Traversal.

Thanks,
Richard

nicocizik

Hi Richard,

I will take a look at this behavior. It is however better to use the OnCalc
of the variable being calculated. For instance, changing your RAP code to
the following gives a correct result in your example without the subreport.

procedure Variable1OnCalc(var Value: Variant);
begin
Value := Value + Detail1['DISPLAY_FIELD'];
end;

procedure Variable2OnCalc(var Value: Variant);
begin
Value := Detail1['DISPLAY_FIELD'];
end;

procedure Variable3OnCalc(var Value: Variant);
begin
Value := Value + Detail1['DISPLAY_FIELD'];
end;

--
Regards,

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

nicocizik

Hi Richard,

After looking at your example a bit more I noticed that the ppVariable2
variable has a datatype of dtString. This is what's causing the calculation
problem. Setting this to Integer solves the calculation problem. It is
currently not recommended that you make calculations on other TppVariables
from the OnCalc event of a variable with type dtString.

--
Regards,

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

rbuser

Hi Nico,

You are right. I would not normally do this anyways it was just because I
was rushing to get the example put together. Thanks for all your help.
Looks like I am good to go.

Thanks,
Rich