I don't see the at all the deadly embrace here...

Vlad

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