Summary fields have to be defined in the table that contains the data that they summarize. You can't move a summary field to another table unless you also move the field that it summarizes into the same table.
I see no advantage to moving the calculation fields into a related table and two possible disadvantages:
Calculation fields that reference data in a related table are unstored. Thus searches and sorts on them perform more slowly, sometimes much more slowly than a stored calculation field. Auto entered calculations do not automatically update when the data changed is in a field outside the current record so you can get update problems if you move the field to a related table.
Other than the number of fields in your table, is there any other reason why you are trying to make this change.
As always Thanks Phil!!! :)
Number of fields within the table was my only concern.
I was about to create a new report that looks at several fields over a 12 month period and I was concerned with creating ( each field x 12) for the calculation count and then summary of the calculation.
Certain approaches to that problem might not require a different set of calculation fields for each month.
Could it be that you want these totals arranged in columns with one 12 columns--one for each month?
Such is called a "cross tab" report and while not as easy to set up in FileMaker as it is in some other systems, it can be done.
Typically relationships and filtered portals can be used to pull that data into the needed columns. And in FileMaker 12, a set of 12 calculation fields with ExecuteSQL might be used to get the same columns of data.
Yes, one column for each month.
Cross tab is exactly what's needed.
A set of 12 calculation fields with ExecuteSQL would definitely help.
My SQL is rusty. Is this an easy procedure?
With the current version of FileMaker, ExecuteSQL is a major pain in the neck to work with. The slightest error in the syntax produces a ? result with no clue as to what error produced it. So you may need to research that option carefully before trying it out. The SELECT query examples in the ODBC JDBC Guide you can open from FileMaker Help are valid query examples you can use with ExecuteSQL. and the SQL Explorer utility provided by SeedCode can be very helpful.
On the other hand, a set of filtered portals and a summary field or two can probably get the job done in a fashion much more familiar to you.