At 07:12 AM 17/01/2008, you wrote:

>The data is generally deleted after two days, so orphaned records will
>be cleaned up eventually; there is no need to reset the MAC to NULL.

You won't get "orphaned records" unless you use the SET NULL action. Contrary to what you seem to assume, NO ACTION does not mean "ignore the constraint". It means impose the constraint without performing any *other* action.

>Cascading them (for the short term) would be better, but the MAC is
>never changed; if the sensor goes bad we scrap it and get another, so
>we can either NO ACTION or CASCADE the UPDATE, and it would have the
>same affect.

I don't understand what you're thinking here. NO ACTION and CASCADE are quite different. In the NO ACTION case, you won't be able to update the PK of the parent if dependent children exist - you will get a FK violation exception. In the CASCADE case, the FK column of the children will be updated if the parent key is updated - provided, that is, that the "family" is not in use by any other transactions.

>Which leads me to another question...
>Does the DB check that constraint on EVERY update to that table, or
>just the updates that affect the constraint.

Every update. Updates in Firebird are at row level, not column level.

> If EVERY update triggers a check, then NO ACTION would take less clock cycles.

I doubt it. Each "action" option has its jobs to do, all requiring visits to the same data and metadata tables, in-use checks, etc. Again I emphasise, NO ACTION does not mean "don't check". It means exactly what you understand by RESTRICT. (I have no idea what Nando had in mind by "subtle differences". Even Oracle and DB2 seem to have no implementation difference between RESTRICT and NO ACTION.)

./heLen