First posting to the group - thanks to everyone for all the great
tips!

Is there any advantage either way between having a large number of
summary fields (20 or more) in a table, as opposed to creating a
related table and using sum(related field)?

I wish FM would let me do summary queries on the fly, without defining
a field or table first.

Scott

One nice thing about the summary field is that you can place it in 
different layout parts to get different results.  Place it in the body 
to sum all records in the found set.  Place it in a sub-summary part 
sorted by last name to get a sub-total for only that last name.  Place 
it in a sub-summary part sorted by city to get a sub-total for only that 
city.  So define the field once and it is flexible.  Even if you have 20 
summary fields, it only taxes the system when they appear on the current 
layout.  Summary fields are usually used in reports.

On the other hand, if you are looking for a way to always show a 
pre-defined total on a commonly used screen, then the calc fields would 
be the way to go.  Stored calcs will always tax the system whenever one 
of their target fields has changed -- whether on the current screen or 
not.  Unstored calcs only tax when on the screen or called via a script 
or other calc.

Scott wrote:
> First posting to the group - thanks to everyone for all the great
> tips!
> 
> Is there any advantage either way between having a large number of
> summary fields (20 or more) in a table, as opposed to creating a
> related table and using sum(related field)?
> 
> I wish FM would let me do summary queries on the fly, without defining
> a field or table first.
> 
> Scott

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg              (818) 883-2846
FM Pro Solutions       Los Angeles, California
Associate Member, FileMaker Solutions Alliance