On Tue, Mar 15, 2016 at 8:04 AM, Tim Ward t...@telensa.com [firebird-support] <firebird-support@yahoogroups.com> wrote:
> > > Now, I seem to recall seeing somewhere that actually a primary key (and > any other unique index?) is independent of transactions, so the following: > > (1) Transaction A inserts record X > (2) Transaction B attempts to insert record X (having first checked that > it doesn't exist, which it doesn't as far as transaction B is concerned, > because transaction A hasn't committed yet) > > results in the error. > > Have I remembered this behaviour of primary keys correctly? Please could > someone remind me where the documentation is if so? > On the documentation front, no, though it's probably in Helen's book, but your memory is correct. When Firebird attempts to put a new entry in the unique/primary key index on behalf of Transaction B, it notices that there's an entry for A and that A's transaction is not committed. Firebird causes B to wait for A to complete (unless it's no wait), then gets an error if A commits and succeeds if A failed. Good luck, Ann > >