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