>I wrote:
> > If transaction A attempts to update a row that transaction B has already
> > changed, the WAIT option causes A to wait for B to end before reporting
> > an error to A. If B rolls back, A succeeds. If B commits, A gets a
> > Deadlock - update conflict error.

At 08:44 PM 7/26/2001 -0400, Robert F. Tulloch wrote:

> Don't understand this. Why is it an deadlock if B has committed? If
> deadlock in this
>case is correct then if A closes then reopens A can update, right? So why
>can A update
>1 sec after B commits or .001 sec after B commits???

It's a deadlock because an update was committed by a concurrent transaction.
A can not see B's changes (consistency, that hobgoblin of my mind), so A
can't overwrite them.


Regards,

Ann
www.ibphoenix.com
We have answers.