Well, the thing about unique indexes and PK's is that they'll dirty
read, and see uncommitted conficts. You'll get an exception and know
something went wrong before you get anywhere near a 'commit'.

The constraints don't ensure the committed data is correct! They can
ensure the record is internally consistent, and (thanks to you
showing me how!) they can ensure the new record is valid against
other committed records (as can a trigger for more complex
situations). But they don't address the problem of other
*uncommitted* records. Which will of course (usually) be committed
later.

Take that 'unique integer' check constraint I posted before:

Transaction 1:
insert into T values (1); /* no check violation */

Transaction 2:
insert into T values (1); /* can't see above, no violation */

Trans 1:
commit

Trans 2:
commit

and you've violated your check constraint without an error!!

Obviously if I wanted unique integers I'd use an index, but for the
time period thing that's not easy.

Unique Indexes work because they dirty-read. I just want check
constraints to do the same!

John

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

> 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?
>
> The thing about constraints is that they ensure that the committed
> data is correct.