>>>Say we were working with a FREE table and wanted to have a calculated field where Field4 = Field1+Field2+Field3. I could do this with a form method triggered by the lost focus event for Fields 1-3, but is that the best way? Is there another way that would be more reliable similar to a stored procedure in a database table?
>>
>>Do you actually need to store the calculated value? There are some circumstances where that's appropriate, such as checksums for accounting or other purposes, or if the table(s) are huge and it's computationally too expensive to recalc the sums on the fly. But in many circumstances, storing a calculated result is considered bad practice because the sum may get out of sync with the contents of the other columns.
>>
>>IOW the most reliable way to keep the sum field updated is to not have one at all :)
>>
>
>I used to say the same type of thing (stored calculated fields bad). That has been modified somewhat to take the type of application into account. If the database is used in a CRUD application with frequent updates, the standard wisdom still applies IMO. But for relatively static databases, especially for OLAP use (often snapshots of the "real" database), stored calculated fields can offer a tremendous performance boost.

IOW we agree completely ;)