Subject | Re: [firebird-support] lock conflict exception |
---|---|
Author | Helen Borrie |
Post date | 2006-01-10T23:17:42Z |
At 10:18 PM 10/01/2006 +0000, you wrote:
reinterpretation of the exception message is too long to fit into the error
message buffer you are assigning it to. As to which object is causing the
problem, it will be a statement involving either the parent or the child
table of that FK relationship.
The actual exception is occurring because the user application is
attempting to perform an operation that would violate the
"PAYCHECKINFO_FK2" constraint. Because you are also getting a lock
conflict exception, you can tell that the exception is occurring because
another transaction has an operation pending on the corresponding parent
row of the REFERENCES table in that relationship (or vice versa, i.e. one
transaction tries to do an operation on the parent row while the other has
an operation pending on a corresponding child row).
You should be able to reproduce it easily enough. Start two instances of
the application and try to perform one of those conflicting operation pairs
on the two.
./heLen
>A user of the the software I write is getting the following exception:You're using IBO and the truncation is happening because IBO's contextual
>
>ISC ERROR CODE:335544345ISC ERROR MESSAGE:lock conflict on no wait
>transactionviolation of FOREIGN KEY constraint "PAYCHECKINFO_FK2" on
>table "PAYCHECKINFO"STATEMENT:TIB_Statement:
>"<TApplication>.frmTRAKMaster.frmChildPaycheck.dmPaycheck.qr.
>
>The message I get from them trucates with the "qr."--so I am not quite
>sure what object is causing the problem. But I don't understand why it
>is happening nor have I been able to reproduce it.
>
>What should I be looking at?
reinterpretation of the exception message is too long to fit into the error
message buffer you are assigning it to. As to which object is causing the
problem, it will be a statement involving either the parent or the child
table of that FK relationship.
The actual exception is occurring because the user application is
attempting to perform an operation that would violate the
"PAYCHECKINFO_FK2" constraint. Because you are also getting a lock
conflict exception, you can tell that the exception is occurring because
another transaction has an operation pending on the corresponding parent
row of the REFERENCES table in that relationship (or vice versa, i.e. one
transaction tries to do an operation on the parent row while the other has
an operation pending on a corresponding child row).
You should be able to reproduce it easily enough. Start two instances of
the application and try to perform one of those conflicting operation pairs
on the two.
./heLen