>>>No difference
>>>
>>>It runs slow if all 3 of these conditions are present:
>>>1. It involves nested SELECT
>>>2. The files are open in at least one more VFP session
>>>3. No FLOCK is issued on the file being updated (or deleted from)
>>>
>>>Why?
>
>>This is a interesting issue.
>You bet!
>
>>On my last post, the nested SELECT is a exclusive cursor,
>>then the nested table is out.
>
>It is DELETE FROM "networked_table" WHERE IN (SELECT ... FROM "No_Matter_What")
>See also the first post in this thread for all the things I tried
>
>>Point 1.
>>* try
>>BEGIN TRAN
>>DELETE ..... JOIN ....
>>END TRAN
>
>No difference
>
>>Point 2. Simulating this with 2 cursors,
>>the Rushmore report print a Intermediate optimization step,
>>but i don't look this into your Rushmore report.
>
>I know...
>
>>Point 3.
>>The Deleted table is a local table or a LAN table ?
>>Can you do the job into the table's machine ?
>
>LAN. I tried locally and it does make a difference! Unfortunately I cannot run my app like that :).
>
>For what it's worth, this confirms my original guess that it has to do with how VFP performs updates on network. But I still don't know why?
>Hugo Ranea in his post suspected that VFP has to RLOCK each record in the table being updated... But, if that's the case, what makes it do it? Nested Select?

I'm not sure for this,
you have tested RLOCK with a array loop into a previous message.

If you retry the array test with a single command ?

SELECT id FROM Task WHERE MainId = 12345 INTO ARRAY aTemp
DELETE FROM Resource WHERE ASCAN(aTemp,TaskId)>0