At 04:15 PM 23/11/2003 +0100, you wrote:

>Yes. Now, I can confirm [check constraints] work just like triggers.

They don't work just like triggers, since you cannot use a CHECK constraint
to change a value or to update or delete rows in other tables. You can
*write* a check constraint that reads a value in another table but it's a
practice I strongly advise against. You create additional inter-table
dependencies in the metadata of your tables that are not protected by decl.
RI. RI triggers are designed for this; if you need more behaviour
attached your update and delete events, or you want to modify it, *add*
manual triggers. If you need to, enforce the FK relationships with RI and
do the specialized cascade behaviour by hand.

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

No, because they are not in context. Triggers provide context variables.

>Well, I don't care now.

Hmmm...

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

There is *no* dirty read in Firebird whatsoever.

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

This sounds like a misinterpretation of what you have read. All of the RI
behaviour (and check constraints too) occur in the context of the current
transaction. Once your transaction has reached the point of checking
constraints and firing triggers, it has your row and its dependent rows
locked. Other transactions can't interfere with your transaction's work if
you set up your transaction to block them (and set up the other
transactions to be blocked).

>If not, how comes I often saw non-declarative RI advocated even for
>staightforward RI ?

You used to see it often preached one Robert Schieck, a lone voice who
didn't trust RI, for no convincing reason. I don't recall anyone else who
practised that particular religion; although I recall myself going through
a phase where I was generating all RI triggers manually from an application
I wrote, thinking it was pretty hot stuff. (RI triggers were a bit flaky
in IB 4). After a few months in IB 5, I woke up one day and thought "why
keep a dog and do the barking yourself?" So, now, I use decl. RI for
everything except lookup relationships - I take care of RI manually for
those because FK indexes, if they had them, would wreck performance.

heLen