The issue I see with your timestamp method is that I don't want to allow the 2nd user to be able to edit it at the same time. In this case they would be able to do a view on it.
Again, maybe I'm being anal here, but I don't like the idea of the field by field comparison and then write as this violates my rule of only one user performing an edit at a time. Correct me if I'm wrong, but unless I'm misunderstanding, it also seems like you could end up causing major confusion for your users with that method. If I edit text in one field based upon the value of another, but someone else is changing that field value, you could be making things worse... --Jeff On 5/9/2005 12:15 PM, Trey Rouse wrote: > I take a different approach. > > I record in the users session the id & timestamp of the record when they > open it to edit. I then check this timestamp when I go to update the > record. > > If the timestamps are the same, then I allow the update. If they are not > the same, I generally don't let the user save, but make them re-open the > record. On some apps I let them chose to save or not. > > This is maybe an 'ass-backwards' way of handling row locking, but I find it > works well enough for web apps. The case doesn't come up all that often, I > don't like the method of locking out other users when the record is opened, > as 1. the user may only be looking at it. 2. the user editing might afk and > come back after your timeout before saving. > > The method I'm using only throws a warning/condition if record edit > contention is actually encountered. > > Sometimes people take this much further, and write the entire record to the > session scope, then when the timestamps don't match do a field by field > comparison, and if the fields being edited by user1 don't overwrite changes > from user2, then commit just those changes. I generally find this is more > work than is necessary, but if you've got users that run into contention > frequently, I suppose I might consider it. > > > Trey Rouse > Web Systems Manager - Rice University > [EMAIL PROTECTED] - 713.348.4799 > > > -----Original Message----- > From: Jeff Langevin [mailto:[EMAIL PROTECTED] > Sent: Monday, May 09, 2005 11:01 AM > To: CF-Talk > Subject: "Locking" a DB record while editing > > I am curious to know how you folks have handled locking a database > record in a shared application. Basically user 1 selects from a list of > records to edit. Normally, I would then immediately go in an write a > timestamp that "locks" the record. When user 2 comes I don't allow > him/her to edit that record as long as that timestamp is, say... no > older then 15 minutes. If it is older, then the "timeout" has been > reached and I clear the lock. This is pretty down and dirty way to > handle it. How else do folks handle these situations? > > --Jeff > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:206067 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
