>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 tables are local, I don't see any reason to be influenced by the network.

>>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
>...

So, you try to lock every 0.1 seconds for 2.5 seconds (probably a little longer). Seems ok. What happens if it cannot lock the record? Did it ever happend?