It is simply a preference of mine and the users for that specific app. In that app, I set reprocess to 0 and issue RLOCK() for a specified period of time (the user can set that time to wait to access a record in the setup) and if the record and any child records (pessimistic) cannot be locked before the time has expired than a customized message is displayed to the user and they can wait and try again. In that app, the users view the records all they want but must click on 'edit' and lock the records to modify data (pessimistic) so only one user can modify a customer's record at a time completely due to government specifications for the app. Once the parent and child records have been saved then I immediately issue an unlock all so the records are available to other users and the current user on that workstation is returned to view only mode.


Ah, ok. That makes sense. In this app, the data is loaded into a BO and the controls are bound to that. So anyone can edit the same record at the same time and whoever saves last wins. This works for this company because it's rare that they'd have people overwriting each others' edits.

I like the idea of providing a message that allows them to try again. The problem is that the record locking is done in the BO, so no UI. That's actualy what started the thread that spun off into this thread, so we've come full circle. LOL!

I've just been talking to my boss about why exactly we bother locking the record before doing the GATHER since VFP will lock it for you. We had just decided to take that out and let the error handler handle it if it can't get a lock when it occured to me that, while the user will get told it couldn't get a lock, my code won't know about it. Sigh. We talked some more and decided to use the new TRY...CATCH instead of RLOCK. This way, my app will know if the lock failed, but it doesn't require an extra call accross the network. Should be the best of both worlds. We'll see how well it works. :)

Thanks,

Michelle