Nick Upson wrote:

> I have 2 processes which may both try to update the same row in a
> table, currently when this happens I get "update conflict ...", so I
> though I would change them both to having a wait transaction, which
> would do what I need.
>

Unfortunately, no. Waiting doesn't change the fact that another
concurrent transaction changed a record that you're planning to
change. In theory, read-committed transactions could refetch
the record, getting the new version and allow you to change it,
but that's not how Firebird works now. And, of course, if the
application has previously read the record and made decisions
about the change based on old values, you wouldn't want to refetch
the record and apply changes based on bad information.

The purpose of 'wait' is to avoid live-lock, a situation in
which two transactions modify the same two records in reverse
order, each fails and immediately retries, fails again, and
so on. It's not intended to allow a transaction to modify
a record when it cannot read the most recent changes.


Regards,

Ann