[firebird-support] violation of PRIMARY or UNIQUE KEY constraint

[m_brahi...@yahoo.fr [firebird-support]]

Hi all,
 

 I get the  following message  when create and compiling a view under IBEXPERT :


  violation of PRIMARY or UNIQUE KEY constraint "RDB$INDEX_15" on table 
"RDB$RELATION_FIELDS".

 Problematic key value is ("RDB$FIELD_NAME" = 'COMMUNE_ID', "RDB$RELATION_NAME" 
= 'VW_EMPLOYE_FULL_LISTE').
 

 I am using FB3
 Can you please tell me from where it comes ?
 


 

  

Re: [firebird-support] violation of PRIMARY or UNIQUE KEY constraint

[Ann Harrison aharri...@ibphoenix.com [firebird-support]]

On Tue, Mar 15, 2016 at 8:04 AM, Tim Ward t...@telensa.com
[firebird-support]  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

> 
>

[firebird-support] violation of PRIMARY or UNIQUE KEY constraint

[Tim Ward t...@telensa.com [firebird-support]]

So I've got this transaction which tries to create records in a table 
and gets


"violation of PRIMARY or UNIQUE KEY constrain"

There are, I believe, no records in the table /visible to the same 
transaction/ with the same primary key, as the insertion code checks 
first, and doesn't attempt to insert a record that's already there.


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?


--
Tim Ward