Hi Martijn !

> Hi John,
>
> > Didn't know you could do that! But it doesn't help. I tested it with
> > a simple integer field, that I wanted to be unique (without using a
> > unique index!).
> >
> > ALTER TABLE T ADD CONSTRAINT CHK_T check (not exists (select * from
> > T where intfield = new.intfield));
> >
> > But it only looks in the current transaction, doesn't dirty-read
> > like an index does.
> >
> > So it's no better than using a trigger :(
>
> What's the bother with ditry reads?
>
> Really, I've been reading your posts but I don't get it - why do
> you want to do that?

For at least one of the reasons I often see you advocating declarative RI
instead of custom RI even when an FK would introduce a low selectivity
index, I guess. It's all in Claudio's article about potential danger with RI
in triggers.

The question is, yes or no, is it possible, with FB, to write custom
contraints that may read data outside the very record/table being modified,
and that will be enforced, just like declarative constraints, in all
situations whatever the number and options of transactions currently
accessing the db ?

If yes, How ?

If not, is this something we have to accept as inherent to FB ?
Or could it be improved ?
If yes, any chance this to happen ?

I never had such needs when using other DBMS, so I am not sure for them.
Do they suffer the same issue ? (*if* there is one of course)

If yes, does this mean triggers are only good for audit trails, *record*
level checks, default values, ... everything bug complex constraints like
John's one (well, this one isn't THAT complex), unlike marketing preach
would tell ?

Back with table level CONSTRAINTS, what's there purpose if they execute in
the transaction context ?

Sorry, that's a lot of questions. There's no irony behind. I just want to
learn.

With regards.

--
Jerome