Hello,

I am thinking about using "temporal tables" as suggested by R. Snodgrass in
his book "Developing Time-Oriented Database Applications in SQL".
Unfortunately, in such a design, constraints like PK or FK cannot be
achieved thru declarative referential integrity. So I'm left with CHECKs and
Triggers.

After having read Claudio's "Declarative referential integrity v/s triggers"
article, I now worry about the isolation level problem. Hence the following
questions :

I know triggers use the same isolation level as the current transaction but
is it also true for CHECKs contraints ? Or are the latter ran against
committed data just like declarative RI ?

Is there a solution in FB 1.5 to ensure that transactions with isolation
level different from "Read committed" can't modify data in the database ?

Any advice before I go the non-declarative RI road ?

PS : Note that both ends of my FKs are volatible tables. The referenced
tables are not the typical lookup tables for which you can get rid of true
RI.

Many thanks in advance.

--
Jerome