>>Logically, it's enough to use initial buffer, because you still have opportunity to give a user opportutnity to resolve field value conflicts when saving. BTW, I am curious, how often your users requests for elaborated mechanism involving GETFLDSTATE,etc.
>
>Yes, going optimistic and resolving conflicts at save time would be the way to go. However, the client's requirements required a lock applied as soon as someone want to update a record. It was like that on the mainframe. They're used to that. For the locking mechanisms, we will use semaphore similar technique. But, since they want that kind of locking before the user change a record, I was concerned about the fact we need to make sure the data he sees if the current data.
>
>As for your question, this was never a concern because they were on the mainframe before and the application will be converted using ODBC from a Visual C++ environment. Visual FoxPro is not certified here. I can just use it for prototyping and testing.


Exactly how does your semaphore technique work? How does it
handle a person that opens a record and just leaves? How do
you handle the user that opens a record and instead of exiting
the program in the proper sequence just turns off his machine
leaving that record open?

Dan