I have tried something similar (since we discused it last time) in FoxPro 2.6 Unix for an application that must work during the night and SHOULD never fail. The app includes in fact 2 programs that use the same tables (not very smart design, because there's no real need for 2 programs (but I can't change this)). I use now the REPROCESS AUTOMATIC because I had (during tests) cases when a simple REPLACE/INSERT locked the record for tens of seconds, probably because of the high load of the network. This is hard to explain. I think that FP checks the lock flag, if it's not locked it locks it, writes data, unlocks. Probably this process is done by multiple commands to server, thus, it can wait if the network is slow. But I can't prove it.

In the same time, I noticed important behavior differences between FPU and other platform versions, s, I don't know if this is possible in your case. I never had a so slow Novell or Win NT network as I have now with Unix (not all the time, of course).

My luck is that the 2 programs are not very big, so I could verify them to be sure that they will always terminate any command. This way, I know that any command that attempts to lock can wait long, but not for ever (so, I don't need a timeout).

On the other side: I understand how you know which command fails to lock a record. But how do you know which command keeps the lock? (you said that the lock is set and kept by an other INSERT-SQL, how do you know it?)

Vlad

>I've read a past thread about the way the locking is occuring based on APPEND BLANK, INSERT SQL, etc. There was a mention that INSERT SQL is better to use.
>
>I use INSERT SQL a lot, for robot applications - not for desktop applications, and have found that sometimes, collisions occur. So, at the same time, the same INSERT SQL is executed by 2 applications. The 2nd one will have "File is in use by another user". What will be the best way to handle this so we can make sure that each application will process this locking in a queue?