Brad,

The behavior you're seeing is correct under snapshot mode.
In that mode each transaction sees a stable view of the database.
The implementation is that each transaction can read only those
records that were created by transactions that had committed
when the reading transaction started.

It is a standard rule that no transaction is allowed to update
a record that it can't read. Your second process read the record
it was intended to update, recognized that a concurrent transaction
wrote the most recent version and settled down to wait for that
transaction to complete. When the first transaction committed,
the second got an error. If the first had rolled back, then the
second would have run. That's the meaning of WAIT. If you find
a potential conflict, wait for it to become real rather than
giving up immediately. NO_WAIT returns an error sooner, but opens
the possibility (probability?) of live-lock.

You may be able to do what you want in read-committed mode
which relaxes the rules about consistency and should allow your
second program to run once the first has committed, since it can
now read the committed changes.


Regards,

Ann
www.ibphoenix.com
We have answers.