Mario Frasca uttered:
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...
If the row is subsequently updated, it doesn't matter, as the original row
I based my record on has vanished due to the first update. My delete will
delete no rows, and my insert will fail if the key clashes with an updated
record.
Basically, I'm using the rowid as a row version number, and assuming it
is monotonically increasing (though not necessarily correctly.) The key
identifies the unique record.
It's a way of detecting conflicts, not preventing them. SQL UPDATE, OTOH,
is atomic and thus prevents conflicts.
just a doubt...
regards,
MF
Christian
--
/"\
\ / ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
X - AGAINST MS ATTACHMENTS
/ \
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
