Subject Re: [IBO] "lock conflict on no wait transaction deadlock"
Author tickerboo2002 <support@tickerboo.com>
Helen/Daniel/Alexandre

Thanks for all your comments/hints.

Up until 5 minutes ago I hadn't fixed the problem, it was only by
listing two different sets of IB_Transaction properties in this email
did I see the answer.

Short answer: One of my transactions had RecVersion=false

Long answer:

I have a TlistView containing records. When I click on an entry in
the TlistView to edit the record, it pops up a dialog which runs a
query and populates a load of controls. The Transaction had the
settings:

IB_Connection: dmMain->cnMain
Isolation: tiCommitted
LockWait: false
RecVersion: true
ServerAutoCommit: false

The transaction is only Committed or rolled back when the user OK's
or Cancel's the dialog.

Part of the dialog contains an embedded form containing a TlistView
which lists records from another table (using a join) which are
related to the row the dialog is currently displaying. The embedded
form's cursor's transaction has the following settings:

IB_Connection: dmMain->cnMain
Isolation: tiCommitted
LockWait: false
RecVersion: false
ServerAutoCommit: false

Since the dialog is currently in edit mode editing a row in table1,
the embedded form's cursor tries to get details from the latest
version (because it's Transactions RecVersion is false ) of that row
it fails with a deadlock.

How RecVersion got set to false I don't know, I almost always use the
defaults.

This development lark will send me grey/bald. Time to read the GSG
again.