>>>>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.
True - at the cost of more code running.

>So there is no need for awkward IN ALIAS.

Here POV comes into play: why awkward ? It is another form of syntax helping to make code succinct.
not directly portable if straying outside vfp/xBase world - yes - but offering clearly defined table operations made more secure (except for locate - which can either be circumvented by seek() for known candidate filters or by wrapping in a function accepting workarea/alias as parameter).

>If you sit on a CA or VIEW, the final change to the target goes by SQL UPDATE (or DELETE/INSERT) anyway.

True. I view the buffered cursor values as "internal throwaway" similar to Java/C#/Hibernate Pojo_orLombok/Poco/ORM objects representing database records - find and modify them as fast as possible.
Not depending workarea currently selected is similar to depending on a "currentpointer" like .activepage: sometimes makes sense, sometimes not ;-))