(I know you didn't write this Martijn, just quoting from your
message!)

I disagree strongly. inter-row dependances are *not* necessarily a
sign of poor design. PK's / FK's are an example. You *cannot* insert
two rows with a PK of 1, that's inter-row dependancy.

I am only suggesting dirty-read be used for check constraints (and
possibly read-only exception-raising triggers). I don't see how this
breaks atomicity any more that the operation of Unique Indexes
(including PK's) which do this anyway.

A unique index can see values in other transactions that havent been
committed. Period.

According to the quote from Ann (peace be upon her, grin) she also
believes check constraints should operate in the system transaction
(is my jargon right? Basically exhibit consistent behaviour with
indexes, yeah?)

Without that, there is little point in having a select check
constraint. There is so much it could miss!

There seems no logical reason for having this inconsistency between
unique indexes and check constraints.

John

--- In firebird-support@yahoogroups.com, "Martijn Tonies"
<m.tonies@u...> wrote:

> > Well, I've kept out of it on the basis that inter-row

dependencies are IMO

> > a sign of poor design. The argument that somehow dirty read

would save

> the
> > day is entirely specious. It would buy the ability to do this

unsafe

> thing
> > at the cost of atomicity. You can't have atomic transactions

with dirty

> > read, period.