>>However, I can't find any reason that justify the 6 to 8 seconds time before the 2nd application end with an error. Does this mean that Visual FoxPro will only retry 3 or 4 times before returning the error? Having SET REPROCESS TO 2 SECONDS, when doing INSERT INTO SQL, if collision occurs, Visual FoxPro is suppose to retry at each 2 seconds until it succeed.
>
>No, VFP will try continously to lock for 2 seconds. If it cannot lock in 2 seconds, the operation fails. Although, I don't understand why you get a time longer than 2 seconds. Probably because of the network or multitasking. You may also try to see the statistics for your network retries. What kind of network do you have? Are these tables locally?

Ok, so if the INSERT INTO SQL is affected by the SET REPROCESS, I may extend this value a little bit.

Yes, probably the network stuff is making it to be longer than 2 seconds.

Network is Windows NT 3.51 Service Pack 5. Tables are local.

>If you can be sure that ANY transaction will end in a finite time, you can use SET REPROCESS AUTOMATIC. But you said yesterday something about 2 minutes, which seems to be "for ever".

I really want to avoid AUTOMATIC. The reason is that I don't want to take the chance to lock the application in case the server timeout does not fire.

>How do you generate the unique keys for THREAD? This can be another place where a shared table is locked. (You must lock the entire table/file if you use the technique of "last used key + 1".)

I use a TABLE.DBF that holds the current ID. I then use it to lock this record in order to get the next one and unlock the record after. Here's the main code. I never had any problem with this one.

...
DO WHILE (NOT RLOCK()) AND (INKEY(0.1)=0) AND lnCompteur<=25
lnCompteur=lnCompteur+1
ENDDO
...