"Scott Marlowe" <smarlowe@g2switchworks.com> wrote in message
news:1117557422.20484.35.camel@state.g2switchworks.com...
> On Fri, 2005-05-27 at 09:57, rubensoda@inwind.it 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
>