"Scott Marlowe" <smarlowe@xxxxxxxxxxxxxxxxx> wrote in message news:1117557422.20484.35.camel@xxxxxxxxxxxxxxxxxxxxxxxxxx > On Fri, 2005-05-27 at 09:57, rubensoda@xxxxxxxxx wrote: > >> >> Thanks for answer Tom >> >> "Consider what happens when the user leaves for lunch" >> >> Well, I've already thought about it.But I'm working with >> VS2003 and disconnected dataset.. so when user edit data >> he's modifying an "old" disconnected row, while real updated row >> is in the database.. >> So my strategy would be (as I already written): >> >> 1. refresh data recalling current row from database to the form's fields >> 2. lock the row >> 3. update modified data in the database through stored procedure >> (function) >> 4. commit and unlock the row >> >> Have you another idea that could work better with disconnected objects ? > > While this ensures that the update is atomic, it doesn't ensure that no > one else is trying to edit it at the same time. > > What you might want to do is either optimistically lock it, or use > application level locking. To use optimistic locking, you'll need to do > something like make an md5 of all the fields being edited, then, right > before you write back the data, check to see if the md5 you created at > the beginning still matches by re-reading the data and md5ing it again. > If it doesn't match, then you can throw a "mid air collision" error, so > to speak, and tell them that the record changed underneath them, or do > some kind of merging / or whatnot. The ODBC driver uses the ctid value to check whether a record has changed; an updated row will always have a new ctid. That would probably be the most economical way to check. > > If you want to do application level locking, then create a field and use > that for locks. Just make it a timestamp field and put in the current > time value when the lock is taken. When the predetermined timeout > occurs, the user lock is removed by the next person to access it, or > offer them chance to, or email the original locker, etc... Handle it > the way you want or need to. > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster > ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
