Doug,

Storing a calculated field is neither desirable nor necessary.  Doing so
requires code, risks the data being incorrect if the fields upon which it
depends are changed outside the context of your form, or outside the context
of the conditions you considered when writing it.  It is also much faster to
calculate it on the fly than to look it up from disk.

For example, if you had length, width, and height dimension fields for an
entity, you'd never attempt to store its xy-plane area or volume--simply use
a calculated field in a query to return the always correct answer on the fly
for use in reports.

Hope that helps.
Sprinks

Forms don't have "fields" - tables do. Forms have Controls, which
might or might not be bound to a table Field. It's a fine distinction
but an important one, and I believe it might be the cause of your
problem!

Correct. If you're calculating it on the Form, it is on the Form - and
NOT in the Table. But it should not *BE* in the table!

Storing derived data such as this in your table accomplishes
three things: it wastes disk space; it wastes time (almost
any calculation will be MUCH faster than a disk fetch); and
most importantly, it risks data corruption. If one of the
underlying fields is subsequently edited, you will have data
in your table WHICH IS WRONG, and no automatic way to detect
that fact.

Just redo the calculation whenever you need it, either as a
calculated field in a Query or just as you're now doing it -
in the control source of a Form or a Report textbox.

Just put a textbox on the Report with the same control source, and it
will recalculate the difference there. No benefit will come from
storing this value in your Table.

                 John W. Vinson[MVP]