Quote:
Originally posted by pixelbend
I'm not sure why you just couldn't add a boolean field to the table called "locked".
|
Or even better, a field called "locked_by", containing the user ID of the user who currently has it locked. That way if you pull up a record you can alert that it's locked by Joe over there, and instruct the user to go whack Joe on the back of the head with a phone book.
Quote:
Originally posted by aoeuhtns
There are two simple approaches to doing this. The first (which is the easiest to code for, but pretty hard to implement because of all of the database changes), is to tack on a TIMESTAMP column (or your local database equivalent) to the table you are worried about. When you pull up the record in the FORM, also pull up the TIMESTAMP and store it in a hidden varible. When it comes to the WORK page, do your update as usual but add an additional WHERE clause to check that the timestamp is the same as the timestamp that was passed from the FORM page. Check how many rows were updated, if there were 0, you just had a mid-air collision, or the user didn't make any changes and the database noticed that fact.
|
That's a really nice approach. The only thing that's missing from it is advance warning that your data is about to go poof. It protects the database from clobber, but doesn't save the user the grief of having to pull up the newly-modified record, reenter their changes (reconciling their data with the other user's new data), and save again--and hope that they got the lock THIS time!
Personally, as a user, I'd rather know up front: hey, here's the record you just queried for, but that guy across the room is already editing it. Go talk to him, wouldja?