summary field not calculating correctly

[tomp]

This has happened a couple of times:

I have a report with body, sub-summary, and trailing grand summary. A calculation field has been defined. The calculation sums the values of another field in a related table.

'calculatedField=sum(relatedTable::otherField)'

The calculation field is summarized in a 'total of' summary field.

The calculation field displays properly in the body .

The summary field is correct in the sub-summary, but

the summary field in the grand summary is wrong.

The grand summary is wrong in both browse and preview mode.

In one case, after setting the parameters for the calculation, the grand summary total self-corrects itself by running the script twice consecutively. The parameters determine which records in the related table are summed. The problem is reproducible.

In another case (different layout/report - same field, relation & calculation), I'm not sure what I did, but by going to other layouts based on the related table and playing with finds, the grand summary now calculates correctly. I've been unable to reproduce that one, but had quite a time of frustration.

I don't have a lot of confidence that my users won't experience the problem (when wrong, the grand summary is so wrong that there is no way they wouldn't notice - I guess that's good).

I'm using 7 Advanced in a Tiger environment.

Anyone else ever experience the problem?

TIA

[Søren Dyhr]

So you're aggregating summaryfields from a relation away, but summaryfields behaves like unstored calc'fields out of sight out of mind, further more does summary fields act on found set's.

Eventhough it seems irritating to let us in on the intimate details of your problem, might we get closer to a way to deploy either aggregate calc's or summaries, not both referencing each other! There is very likely something wrong in the way you structure the solution to your problem, since you seem to force your solution to behave spreadsheet'ish out of it's realm.

The tool is meant to give summaries in previewmode, just before printout and not something to be inspected in browsemode, here should a scripted measure or a recursive CF take care of the generation of i - unfortunatly aren't any of the following solutions working with pre fm8:

http://www.nightwing.com.au/FileMaker/demos8/demo803.html

or...

http://www.kevinfrank.com/download/kf-fast-summary.zip

So you have to study and emplement Edoshins fastsummaries, and deploy a event trigger plugin to accomplish what you're after:

http://www.onegasoft.com/tools/fastsummaries/index.shtml

--sd