>>When you update TABLE.DBF, do you:
>>1) RLOCK table.dbf, then
>>2) INSERT INTO thread, then
>>3) Update table.dbf
>>
>>***OR*** do you
>>1) RLOCK table.dbf, then
>>2) update table.dbf, then
>>3) INSERT INTO thread
>
>The call to the function to update the unique ID in TABLE.DBF is done prior to the INSERT INTO SQL. The function RLOCK(), update and UNLOCK. Then the program continues with INSERT INTO SQL.
>
>>Your situation would definitely sound like a "dead;y embrace' to me EXCEPT for the fact of you SET REPROCESS *and* the possible length (time-wise) of update to phDBASE table.
>
>There is no deadly embrace here.
>
>As mentioned today, it all seems to be related to PHDBase.

This is very probable. Now, why don't you use a SET REPROCESS TO 60 SECONDS or even more? In this way you are sure that the program will not "die" because you still have a timeout and in the same time you don't need to worry anymore. This seems to me the best solution: if the first INSERT is short, there's no difference than before, if it's long, the second one will just wait more, but no error will occur. Of course, I presume that you cannot have an INSERT longer than 60 seconds.

Vlad