Christian Smith wrote:
You can use the rowid to track the row version, and a unique
constraint on your key to track conflicts. When updating a record,
read the row, including the rowid. Update any columns.
When writing the row out, delete the existing rowid, then insert the
new updated row, all within a transaction.
If noone has updated the row since you read it, the delete should
delete one row and the insert should succeed. If someone else has
updated the row using this protocol, the delete should delete no rows,
and the insert should fail with a unique constraint violation on your
key.
maybe I'm missing something, but how does this behave if the row is
updated a second time in the meanwhile (something like C acting as B
between A-read and A-write)? I've the impression that the insert will
not fail...
just a doubt...
regards,
MF
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
