Hi!

See notes below.

>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

You think as IT and I agree with you. But I look to future also. In future customer after 2 months of working with you application will call you back and say "Emmm, noo, such way is not good..."

What you will do in such case? IMHO good prediction of such situations is not bad idea, Just ask customer which way they want. Sure, by such way later you will have no headache with complains.

>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
>

And in 90% after such development they request changes than.

>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
>

And here is my point. You need to be aware about this everywhere. In my application I have a single updating routine that does everything and called from all places. This cause much less overhead and bugs in total, specially when large project made by several programmers in team.

>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
>>>>