Hi Stephen,

I may be take your words too seriously, but two points:
1)I don't like an attitude: 'User is fool and doesn't know anything about computers'. Let's respect our customers and users.

2) Let's not try to make our programming job easy, but better try to satisfy user needs for 100%. It's your job to create a robust, user-friendly application. And if particular developer task seems to be quite complicated, don't complain, but try to find a solution or ask for help in forums like that.

No offend, please...

>Close but not right
>
>The customers are drones, it matters what the programer does, people work around that, and as programmers we have to determin what is better, what is easier/faster to create, and what is the eaisest for the customer, why did I say the last one
>
>Because the customer has no idea what is best, thats why they hired you
>
>Bottom line you do what is easiest/fastest for you to create with results that make you and the customer happy, 90% of the time they are happy
>
>Also if you lock records "the smart way" i.e. never let the user lock the record for a extended time and have your locks and unlocks without a wait or read between them then the lock is only for a split second
>
>I have a inventory program with inventory, ordering, issuing, receiving, adjustments, requisitioning ect with over 500 users from Ocean City MD. to Oakland (east most MD and west most MD.) and there is only 2 places you the user can lock a record where there is a read or wait for user input and I have timers not letting you lock a record for more then 5 minutes no matter what
>
>and I have never had a user wait more then 30 seconds for a lock, and in 2 years I only had one person call and complane about it and in the process of picking up the phone it was unlocked
>
>after all this the simple answer is
>let foxpro do all the work, you just verify that it is doing the job correctly
>
>>From my experiense RLOCK() will make much more headache for you than proposed method. Customers do not like to wait for data saving. They do like when you note them that something changed on server instead.
>> Its depended on customer.
>>
>>>Personelly I would trash that and start over and use the rlock() function
>>>
>>>for everything edits, deletes the first line of code after hitting edit or after conferming the delete do a
>>>
>>>set reprocess to auto
>>>if rlock()
>>>do your stuff
>>>else
>>>wait 'locking record' window
>>>endif
>>>
>>>No taking advantage of the rlock() function really makes things to complex and way to much code to write
>>>
>>>>Sorry, I post this again to send this as reply to all other members of this thread
>>>>
>>>>>If i use CURVAL or OLDVAL, both return correct value and I can know the changes, but It need to loop through all of the fields.
>>>>>
>>>>>
>>>>>Any ideas?
>>>>
>>>>Whats the problem? This operation is quick because it works with buffered data in memory. Sample of updating session with checking for changes on the server:
>>>>
>>>>

>>>>if !tableupdate(.F.,.F.) && when cannot update, check if reason is changes on server
>>>>  local lnFieldIndex, lcFieldName
>>>>  select MyAlias
>>>>  for m.lnFieldIndex = 1 to FCOUNT()
>>>>    m.lcFieldName = Field(m.lnFieldIndex)
>>>>    if type(m.lcFieldName) == 'G' && skip general fields
>>>>      if !(OldVal(m.lcFieldName) == CURVAL(m.lcFieldName))
>>>>        * Oops - something changed on the server by another user - prompt to overwrite
>>>>        ...
>>>>        if !llOverWrite && if user answered to do not overwrite
>>>>          && update current value by changed value from server
>>>>          replace (m.lcFieldName) with CURVAL(m.lcFieldName)
>>>>        endif
>>>>      endif
>>>>    endif
>>>>  ENDFOR
>>>>  * WARNING - special checking for deleted records
>>>>  if CURVAL('Deleted()')
>>>>    * Oops - record already deleted by another user
>>>>    * ask to recover it or keep deleted
>>>>    ...
>>>>    if llRecover && if user answered to recover record
>>>>      && following 2 commands needed to assure correct update on server
>>>>      delete
>>>>      recall
>>>>    else
>>>>      && delete record in local buffer as well
>>>>      delete
>>>>    endif
>>>>  endif
>>>>
>>>>  if !tableupdate(.T.,.F.)
>>>>    && error - cannot update at all
>>>>  endif
>>>>endif
>>>>