>>>>>SELECT ThisTable
>>>>>REPLACE OtherTable.SomeField WITH Something
>>>>>
>>>>>fails if ThisTable is at EOF. Adding IN is the fix, not the problem.
>>>>
>>>>Then it was this way around. The solution is SQL UPDATE rather then REPLACE anyway. :)
>>>
>>>From my POV embolded is not using vfp full capabilities. My "best practice" in vfp is to work with xBase when record pointer is "relatively static", in other words stays on record for certain piece of code. On-Record-Replace does not need to lock table like SQL does IMO.
>>>
>>>Whenever "unclear" sets are updated, SQL update often makes more sense.
>>>Gray area where I decide case-by-case is when record scope already has been set, for instance with set Key or set relation, then I might opt for xBase Scan or even Replace. Similar for identifying single records to work on from table: seek (+locate) preferred to SQL Select going to the trouble of using again behind the scenes just to give me PK or RecNo() of that particular record.
>>>
>>>Just trying to be kind to CPUs... :-))
>>
>>SQL UPDATE will not be harmed by change of workarea nor record pointer. So there is no need for awkward IN ALIAS.
>>If you sit on a CA or VIEW, the final change to the target goes by SQL UPDATE (or DELETE/INSERT) anyway.
>
>Because SQL UPDATE by definition includes the alias.
>
>Tamar

I would rather say SQL does not know about workarea, but it ends up the same. In may POV (and please, it's academical) IN ALIAS is DBX, targeting a WORKAREA named by the alias, while SQL is targeting the table aliased. This is a difference.