Instead of timestamp, consider a checksum/hash of the relevant values in the row which is easy to calculate in most dbs using builtin functions (eg MS-SQL has CHECKSUM() and BINARY_CHECKSUM() while MySQL has CRC32()). Store the hash in your web app and check the new hash for the row before an insert/update. Timestamps can be reset on purpose or accidentally -- a checksum is a lot cleaner (it's part of what MS-SQL uses under the hood for replication)
As I understand it, the proper way to prevent overwrites outside of a stateful environment is *not* to lock the data and prevent updates while you are updating, but to instead check for updates before you potentially overwrite them. Here's something I'm coming up with off the top of my head:
1) select data from tbl_A
2) in tbl_Versions, add a reference to "tbl_A," the rows selected, and the last modified date timestamp of each selected row
3) deliver the data and the tbl_Versions reference ID to the client; alternatively, store the tbl_Versions reference in the session.
4) when/if the client returns the data, check the reference and compare the current tbl_A rows' timestamps to the timestamps stored in tbl_Versions
5) if there are no differences, update tbl_A with the incoming data (ideally, you only update that which has changed, though, right?)
6) if there are differences, then choose whether the whole block should abort the update, or just those rows. Select the newer tbl_A data (updating the tbl_Versions timestamp data), and deliver these and the submitted data back to the client to be reconciled
7) periodically clear out old tbl_Versions references, if you wish.
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com).
An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
