I'm seeing a few values in tables that are twice what they should be.
At the moment I'm assuming that two programs are trying to set the value
at the same time, with the end result that one inserts and the other
updates & increments the first one.

The stored procedure that wraps/guards inserts and updates for the table
updates a field (in another table) with the current timestamp. If two
transactions try to update this field before the other commits, there
should be an update conflict and one would fail.

There is an after-update trigger on the table that confirms that the
data is correct.

I'm at a loss to explain how my assumption of a race condition can be
possible. The two transactions can't see each others data (unless one
starts after the other commits), any updates to the same field (the lock
field in the other table) should cause an update conflict (would an
update conflict occur if both updates are setting the field to the same
value?), and the trigger should fail the second transaction if they
execute serially.

If my reasoning isn't flawed, I'll have to drop the race condition
theory and look at the algorithms again.

Disclaimer: This message (including attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and delete this message from your system. Any unauthorized use or dissemination of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change. RxStrategies, Inc. shall not be liable for the improper or incomplete transmission of the information contained in this communication or for any delay in its receipt or damage to your system. RxStrategies, Inc. does not guarantee that the integrity of this communication has been maintained nor that this communication is free from viruses, interceptions or interference.