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.
> 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