I am having problems with 'deadlock conficts with concurrent update'
errors.

What happens is i open a (browse list) thread (A) update a particular
record, open another (browse list) thread(B) and update the same
record. Now if i go back to thread A, and do a get (select) on the
database, I will get the data that it saved back and not B. If I then
try and update the record I get the 'deadlock conficts with
concurrent update' error. I can keep opening new threads and they are
all fine, but if they update a record any previous threads will have
the same problem.

However, if I open A then open B and update the record on B then i can
switch between A and B, updating as i please without problem (and
getting the data they update).

Closing the thread does not fix the lock that appears to be held on
the record ie. If I open A and update, open b than update and close
than try and update from a I still get an error.

I assume this is becuase the server appears to have what i'm calling
'thread memory' where even if i do the above and then also shut down
thread A and then restart it, it 'remembers' the data giving it the
data it say before it shut down and it will still get the deadlock
error. (Is this some kind of snapshot 'functionality')

Using gstat I have noticed that I have had older snapshots than OIT
and older OITs than OATs as shown below

Oldest transaction 118430
Oldest active 118431
Oldest snapshot 118419
Next transaction 118435

Any ideas on how this behaviour occurs and how I can fix it?

Other details

I am writing the app in Clarion 5.5, it runs with a stadard isolation
level of read committed and when it explicitly starts a transaction it
says it is serializable, however due to the nature of the language and
API I can not modify this.

I am using the standard firebird odbc driver v1.2 (with no wait set)

I am running V1.5.1 on gentoo Linux (superserver)
I have tested on V1.5 on Windows with classic with the same problems.
I have set the sweep period to 1 in gfix.