Calc to replace Summary field

[lsmall]

I have multiple summary fields that I would like to function as "On Demand" calculations instead of updating constantly. So basically script a calc that will have the same functionality as a Summary field. I have tried the sum calc to calculate the total of all field values across all records in a found set, but it isn't working-not sure why.

Any suggestions?

[Søren Dyhr]

You can investigate how I use GetSummary( on a related set of data, in this template:

http://fmforums.com/forum/showpost.php?post/345273/

To produce a multiline relational key for the found set, could either a tail-recursion CF such as JMO's or Debi and Agnès approaches be used:

http://www.briandunning.com/cf/892

To get the summary on demand is simply to use an evaluate statment.

Another way is to use this approach by Michail Edoshin and Kevin Franks:

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

--sd

[IdealData]

I have multiple summary fields that I would like to function as "On Demand" calculations instead of updating constantly.

How about some "parallel" number fields that can be updated using a simple script to assign the value of the current summary field to the plain number field.

SetField will do the trick.

[lsmall]

Thanks for all the replies. The issue is I don't want the summary field at all, as its constant unnecessary updating is slowing down the other stuff. So even if I script it to a parallel field, it will still be updating itself all the time.

I'll look into some of the links provided.

Thanks

[Søren Dyhr]

The issue is I don't want the summary field at all, as its constant unnecessary updating is slowing down the other stuff. So even if I script it to a parallel field, it will still be updating itself all the time.

Well - not quite, summary fields are the fastest way to deal with found set, it's the layouts rendering which are to blame here, or rather the pulling expectations and virtues from other realms makes a tendency to put them on layouts not intended for subsummary reports, in ignorance - it the very core to the problem. Summary fields should be avoided being put on layout's where users have any other access than viewing - say clicking on the rolodex...

However is it a somewhat a problem of the past, since fm10 is it based on new and way faster algorithms...

But it will not hurt, to keep input and summaries to separate layouts.

--sd