>< snip >
>
>>Sergey,
>>It's not really a big deal. < s > We use this semaphore locking scheme in our VFP/Oracle system. In order to clean up leftover crap, we have an SP that is scheduled to run every night. Of course, we can manually run it anytime we want.
>
>Hi Larry,
>
>I'm thinking about implementing something like that for our VFP/MS SQL system. Can you provide more details?
>
>TIA

Sergey,
Instead of a Locks table, we store the locking information in the table where the information is. It works for us because all information is related in one way or the other and the only way to edit it is to load the information from the backend.

The "Parent" row is selected and the user then loads all information associated with that element. During this load process, the userID, machine ID and datetime is captured and the appropriate lock field is updated on the backend. When another user wants to load that particular element, a check is made to make sure the lock field is empty. If not, a message is displayed with the user's name and time of lock along with the question as to whether they want a "read-only" copy of the data. If they want a read-only version, everything works as normal except the functionality to submit the changes back is disabled. If they say No to a read-only version, the load process aborts. They can then contact the user (most likely someone working on the same project) and ask to have the element unlocked.

Locks are cleared in the following ways:
1. User exits the system normally
2. User unloads the element

The normal nightly cleanup process goes through and clears any locks that have datetime stamps from the previous day. We don't work in a 24/7 shopo so this works for us (it may not for you). We can also manually (via an SP) clear any particular user's locks, no matter the datetime stamp.

If you have any other questions, let me know.