Hello Tim,

Firebird constraints are evaluated immediately for the transaction.

So that means that during constraint validation, it doesn't "see" other
transactions, and due to it's "immediate" evaluation, you can't temporarily
ignore validation for your transaction either. (eg: "increase all PK values
by 1")


With regards,

Martijn Tonies
Upscene Productions
http://www.upscene.com

Download Database Workbench for Oracle, MS SQL Server, Sybase SQL
Anywhere, MySQL, InterBase, NexusDB and Firebird!





If there's some code which says "if there isn't an EXXON then create
one", and there's a uniqueness constraint such that there can't be two
Bxs, then "clearly" the above code can go wrong, in that the following
cannot succeed:

(1) Transaction 1 - check for EXXON, find it doesn't exist
(2) Transaction 1 - create EXXON
(3) Transaction 2 - check for EXXON, find it doesn't exist (because it
can't see the one created by transaction 1)
(4) Transaction 2 - create EXXON
(5) Transaction 1 - commit
(6) Transaction 2 - commit

This fails, as one would expect, due to the violation of the uniqueness
constraint. But my question is: does it fail at point (4), because the
uniqueness constraint is somehow active/visible/whatever across
transactions, or does it fail at point (6), because the uniqueness
constraint only takes account of committed stuff?

(Yes I do know that's what generators are for.)