Thus why in general, I don't let them save if another user updated the record since user1 began working with it. Force them to go back and open it again and see the changes.
It all depends on the type of data and the level of concern involved, but this approach has worked well for me. 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:31 AM To: CF-Talk Subject: Re: "Locking" a DB record while editing 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:206125 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=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
