Rick,
don't forget SQL also always happens in a separate workarea, no matter if the name you address is already an alias of a currently used workarea or the sql engine finds it as dbf file or table name of the currently set dbc.
So even in case of an alias you select from, update or insert into DBF('alias'), not alias itself. So you don't get influenced by index, filter, position and you don't influence index order, filter and position. The effect on data can of course be in the alias workarea, as it is about dbf('alias'), no matter if that's a tmp cursor/view file or a real dbf file.
Sometimes it would be nice to let filter have an effect on SQL, but once you internelaze the very general truth SQL always works in separate workareas, you don't need to fear repositioning, getting positioned to EOF, having another order set, causing implicit tableupdate in row buffering mode because the record pointer moves or anything else you could fear if the SQL engine would use the alias itself.
It's not becoming that obvious because - as said - surely you see the effefct of sql inserts or updates in the alias. But whatever was done, was done on either the dbf (which in buffering mode can mean you don't see an update in the alias itself, but only as curval) or done on dbf('alias') which is actually the same as the alias, still a different workarea was used, so that alias - whatever it really is - is used again.
It's a very essential thing to keep in mind: SQL - own workareas. Any SQL. The special case also exists, if you query with sqlbuffering, the buffer of the specified alias is also taken into account. Still the actual SQL is done in a separate workarea and you don't have to fear any interference aside of the wanted interference (in case of inserts or updates, of course. In case of selects you get the selected data in a new workarea anyway, and don't effect the alias, but only read from it).
Chriss