>>will SQL read memory variables if they are without alias in the SQL statement on settings [0,2] ? For me SQL Select fieldlist without alias was the best reason for selectedalias.field read first, as it allows SQL statements without specifying alias (with knowledge that mDot was established in dBase/fox well before SQL came along...)

It's interesting that the even more ancient m-> also still works. Re unaliased field lists: I have not yet checked but expect that the parser will continue to identify UNambiguous content. Select field1,field2,field3 presumably is as unambiguous as myvar= .

>>Also curious why he argues/opts for
>>m.xxx = m.yyy
>>on assign... should microbench again.

When I raised that point, Chuanbing provided detail on actual byte storage of m.myvar= versus myvar= and his conclusion that any parser difference would be minimal.

In the context of VFP C++ Compiler, any potential difference would be swamped by the obfuscation anyway and very often there will be other useful stuff going on, so that this could be "straining at gnats while swallowing camels".

>>In theory, on an app working mainly off memvars/objects, this sys() might give a small boost in speed, wrapping SQL with different setting might keep SQL speed, which probably is higher if current alias is first in giving value.
p>>ls keep us updated on tests and findings

Will do, though as one who always tries to use m. on the right side of attributions, others may have more skin in this...