Your exactly right, it's the requirment of the user with taking useage into the equasion I like locks just because of the lack of code, i forgot to mention I am lazy and have a habbit of making my app to powerfull, thinking that the company is growing and useage will increase, I am your typical code ripper I find ever example I can find, figure out if it can benifit my app and copy/paste till my fingers are sore

But I really like the fact that the code you used is reused code, quicker load, quicker responce, smaller app size and simpler to the veterin programmer

But once again I see no way I could ever put that in my current app

If a single users has to re-type and re-try to save, I would have to pay someone to test my food and start my car

once again it's just my option I have been wrong many times

>I agree, when you have application where 30 users try to update the same record simultaneously, you _must_ use locking. But this is very rare case. I never had such application with such requirement. I have 200-user application though, but nobody complained about my method of updating.
> This is dead question. Wich way to use - depended on application requirement, and that is depended on customer. And that is what I meant from start of our discussion.
>
>
>>No I have had this "product" on PC's for 2 years no one has complaned and I have gotten good service citations from the govenor
>>
>>good programmers complete the package from all ends and work woth the company for at least 6 months watching people use the product and comming up with simplist datacentric with smartlocking only when it is a must if you can get away with only updateing at the time of a save, what if 30 people save diffrent info to the same record at the same split-second
>>
>>and with your code there is a "can't update at all" what the hell is that, no user whats to retype everything all over again and then "try" and save it again, they could end up spending 3 hours trying to get a update through
>>
>>that will have users wanting to choke you out!!! and you know it
>>
>>
>>
>>btw, yes my spelling completly horrible, but I know foxpro
>>
>>>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
>>>>>>>