In general terms, the usual approach to locking problems is to use buffering. You could choose to adopt buffering with pessimistic locking, in which case locking conflicts shouldn't cause a problem. Read up on buffering in the Help.
Having set the buffering, you could SET REPROCESS to, say, two seconds.That way, if two people hit the table at almost exactly the same time, VFP will simply wait until the first one finishes before letting the second one proceed.
You should also write an error handler that traps for errors 108 and 109. These errors will arise if, despite the delay initiated by SET REPROCESS, one user tries to edit the record or table while another user has it locked. Your error routine should advise the second user of the situation, and suggest that they try again later (obviously your user interface will have to handle this).
The other approach is to use buffering with optimistic locking. That means that you will never lock anyone out just because someone else is editing the record, and you should never get errors 108 or 109. But you run the risk of the second user overwriting the first user's edits, so your code will have to test for this and take some appropriate action.
All this is explained in the Help, under the heading "programming for multi-user access" (or something similar).
My Visual Foxpro web site: www.ml-consult.demon.co.uk
My Crystal Reports web site: www.ml-crystal.com