Wow. You're the third person (I've noticed) that has said this. Does that mean a pessimistic lock strategy is often used in the SQL Server world at large? I know this is an individual decision, but I guess I thought that the shift to optimistic locking in VFP was in part fueled by database servers. I didn't think pessimistic locks would be acceptable in that environment.

Pardon my ignorance, but why semaphores? Can you do record locks with SQL Server?

>By larger scale, I mean a system where the chance of collision is greater then it is now. Currently the staff using the system is between 5-10 people. And they split up the work in a way that minimizes the chance of update collisions (not purposefully).
>
>If the company so desires, they might enhance the system to work in more types of offices. The natural extension of the current system would be into offices where rather then 1 large project, there would be multiple smaller ones. So the division of labor wouldn't be so distinct and there would be multiple people doing things like vendor record updates.
>
>To institute a semaphore, it would be similar to what Kevin G. described here earlier. A column in a table somewhere that gets set when a user selects a record for update. And that column is queried whenever any user selects a record for update.
>
>>If this was a larger scale multiuser, we would have instituted semaphore locking during updates.
>>
>>Can you tell us why you'd introduce semaphores with larger scale? When you say "during" updates do you mean at the split second of update, or throughout the period while the user is making their edit?