>>you have tested RLOCK with a array loop into a previous message.
>
>Yes, but I RLOCked only those records found in aTemp.
>Hugo Romea suspects that in my case with the nested select VFP has to RLOCK every single record. Still no explanation of *why* though.

Possible, but then why VFP does not use one technical of lock escalation
( like MS SQL ) and lock the header ?.

>
>>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
>
>Sure enough, works fast. Is it because there is no nested SELECT?
>
>My main issue is that I am trying to use VFP the same way as I would the "big guys" like MS SQL Server or Oracle. If for no other reason then portability.
>And all the improvements made to SQL in VFP are quite encouraging. However, if it means such a performance hit, then I think we should at least be aware of that. Better yet, I think we should know *what exactly* makes VFP work so slowly.
>So far it looks like UPDATEs and DELETEs are no good if they involve intermediary cursor as in a nested select of VFP 8 format or using Joins in VFP 9
>--Andrew

I agree with you.
But MS SQL and Oracle have a large advantage:
they files are in exclusive modality!!
VFP is practically a system distributed that it shares files,
distributed on separated pc;
to guarantee performances and correctness is a terrible task (I says impossible).


You have try it with SET TABLEVALIDATE TO 0 ?

Fabio