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

>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