Jim,
Until 2 weeks ago, I agreed with this thinking 100%. I would do everything conceivable to avoid storing calculations or duplicate data in 2 different tables.
But now I have an app that has a 1 to many between invoice and detail_line and a 1 to many between detail_line and payment_line and 1 to many between check and payment_line. The client wants to see, on a pick list, all the invoices and detail_lines along with the balance due on each one. That meant constantly calculating the total invoice amount along with the total payment_lines against the individual detail_lines and them summing them to get the total for the invoice and then subtracting from original invoice amount for balance due. Constantly doing that calculation (which required sequential sql statements) for a pick list that keeps getting added to was just too much.
Once I realized that I could put the calculations into the dbc, I started thinking that it wasn't such a problem after all. I could safely (or acceptably close enough to safe) keep the data updated without having to code the calculation for every form I wanted to use it in. This way I only have to do the calculation whenever there is an update to the data (and only on 1 parent record), instead of everytime I wanted to refresh a pick list.
Once I've gotten used to the idea that there is a "duplication" of data in 2 different tables, it makes designing the app easier. I just have to get used to the idea.
Now I'm looking for the best way to accomplish this, because I like the idea of having these kind of calculations done at the dbc level instead of at the form level.
For anyone thinking about doing this. There is one problem I have discovered. The child needs to be TableUpdate(d) AFTER the parent for new records, but BEFORE the parent for the calculation updates. In fact the update of the calculation in the parent needs to be done during the child's TableUpdate(), otherwise the calculation may get out of sinc with the child's data, which is why I'm doing it from the row level rule in the child.dbf.

>Bill,
>
>Two ideas come to mind, 1 your data is not in thrid normal form if you are storing the result of a calculation. That means it is not unusual to require the extra TableUpdate. 2 By violating third normal form you have created a sequence dependency on the tableupdates, the child must always be done first and the parent must always be done if the child was done.
>
>When we choose to break a normalization rule we often pay with more complex code to handle integrity issues. The real question here is, "Is it better to store the total and have complex integrity code, or not store the total and have simple integrity code."
>
>If you choose to not store the total, then you only have to calc it when it needs to displayed or printed. With SQL syntax that isn't always such a tough thing to do. It depends on the number of details any given parent might have.