At 10:33 AM 13-11-02 +0100, you wrote:

>Hi all,
>
>One of the users of our system gets at update of a record the errormessage
> "lock conflict on no wait transaction deadlock"
>
>What can we do to solve this ?

Have your application respond to the exception "appropriately".
At this point, the user that got the lock conflict can't do her update on
one particular row, because another transaction already has a change posted
for it.

So your user now has a transaction unresolved. It will be resolved by
either committing it after the other transaction has completed, or by
rolling it back. Rolling it back will undo all of the yet uncommitted
changes which this user wants to do (not just the one that encountered the
lock conflict).

Now, you have two choices:

1. Do you want the blocked transaction to succeed, even if this user's
change will overwrite the change made by the "winning" transaction?
or
2. Do you want to undo all of the changes, in the knowledge that any one
of those changes might overwrite another piece of work?

You might prefer to let the user choose whether to cancel (rollback) her
changes or to proceed and try again (perhaps a limited number of timed retries)

I think you are using IBO - is that correct? You will get a lot of help
from IBO's exception handling, if so; and also in its ability to preserve
the parameters of rolled-back DML. There is a TI sheet at
www.ibobjects.com/TechInfo.html
on the topic of exception handling.

Other interfaces also give you access to the status vector of the API,
which carries the exception code and the message associated with it.

heLen