Hi Alexander,

Thanks for your help.

>> 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.

> Jerome, fortunately I did'nt read this book :)

Why "fortunately" ? I think it's a very well done book that goes to great
pains to make understable a very tough topic (at least for my simple mind
;-)) : Temporal data (or things that change over time)

But maybe we are speaking of different things. If you were thinking about
MSSQL temporary tables, this is really not what I'm after.

Here is the link on amazon :
http://www.amazon.com/exec/obidos/tg/detail/-/1558604367/ref=sib_rdr_dp/102-
1031277-4041715?%5Fencoding=UTF8&no=283155&me=ATVPDKIKX0DER&st=books

Well, the book or what I want to do is of no importance here, my question
should have focused on non-declarative RI. See below.

>> 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 ?

> Can't answer because don't use select-form checks. Think the same as
> trigger - internally they are implemented as hidden before trigger which

fires

> after user-defined ones.

Yes. Now, I can confirm they work just like triggers.

> Anyway it is easy to check experimentally - <...>

I had and still have a hard time with select-form CHECKs. Somehow I can't
use values of the currently modified row in the WHERE clause of my select.
Well, I don't care now.

>> 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 ?

> No. And no for any other SQL engine.

Don't know why I only had IB/FB's snapshot isolation in mind and forgot
about dirty read.

So, let me rephrase my question.

If my constraints are so that they can't be expressed thru declarative RI
but need triggers. Is there a way to avoid the pb described by Claudio in
his paper ? That's to say, can I ensure that other connections to my db
won't mess up my data integrity by using a different isolation level than
"Read committed".
If not, how comes I often saw non-declarative RI advocated even for
staightforward RI ?

Thanks for your help.

--
Jerome