Thanks to you both for responding.

What I was probably incorrectly referring to was something similar to what Bill was describing. In my situation, multiple users are performing several operations each, when completed, record the fact that the operation was performed. I had been using INSERT INTO table (fields) VALUES( values ).

Yesterday was a particularly heavy day and several users complained that the system was not repsonding and I saw that they had the WAIT WINDOW "Attempting to lock record..." showing. Others just had a process hung where that INSERT statement was executing.

So I was trying to determine if my SET REPROCESS or other code was perhaps improper.

I would think that with SET REPROCESS TO AUTOMATIC, once one user left the table, the next would get it and so forth. But it apparently did not happen that way.

Again, thanks for the input.

Dave

>>>Deadly embrace? This is when two processes are waiting for one another two finish before continuing- how could you do this with VFP?
>>>
>>>SET REPROCESS TO AUTOMATIC has always done it for me- I have never had a problem. I use both INSERT INTO and APPEND BLANK depending on the situation, and have not been bitten with either one.
>>
>>I think the kind of scenario he's thinking of here is two users running the same application. User 1 locks record X, User 2 locks record Y, then User 1 tries to lock record Y while User 2 tries to lock record X creating a circular locking dilemma. I don't know if this is his exact situation since he seems to be dealing with INSERTs, but I assume this is what he is referring.
>>
>
>If this is really the problem, I have no solution except for to change this strategy. There is rarely a use for explicit locking in the first place, and VERY rarely a use for locking two records at a time. Seems this is a good candidate for transactions, instead of explicit record locking.