Ok, let me try that again. . .

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

My point is simply this: *IF* you do the INSERT *while* the RLOCK is in place on table.dbf, then you run a risk of a "deadly embrace". This is as in the first example, above.

If, however, your logic follows the second situation shown above, then you have little risk (I cannot say *none* because I am not at all sure of the impact of .CDX updates (and their locks)) of deadly embrace.

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.

Still, good luck,
Jim N

>>Does your logic lock/update/unlock the 'key' table *before* it does the INSERT INTO?, or do you do the INSERT INTO while the 'key table' is still locked?
>
>The key table, which is known here as THREAD, is never locked. The reference to the locked table was to TABLE.DBF, which is used to keep all the actual key.