...Yup, I think they call this shadowing the DB. But along those lines, it seems like the ideal situation so far to simply store it elsewhere temp while you play.
This might be too simplistic. But when you select a record to edit, could you not update a column to note that it is locked, by whom, and when? Or possibly have another table that holds this information and update the actual data row with a foreign key that corresponds to the information in the lock table? This way, others can read the data but no one else can update it.
The major problem with these is that you are trying to impose state on a stateless interaction. Even "maintaining state" through cookies and form fields isn't stateful, since in between requests the server has no means to check on the state of the client. If that client had died, or simply mis-clicked and then clicked the back-button after you lock it up, your system fails.
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.
--
Ben Curtis
WebSciences International
http://www.websciences.org/
v: (310) 478-6648
f: (310) 235-2067----------------------------------------------------------
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]
