Jim,

>>
>>Conforming to standards is "byproduct" of changes made in VFP8. The main reason for those changes in VFP8 was that those queries (DISTINCT with memo and GROUP BY with fields not included in the GROUP BY) returned incorrect results in previous version of VFP. That explains why it wasn't implemented in any other DB.
>
>Ya know, Sergey, that's one fine reason to make ANY change.
>But, in THIS case, the evidence is slim (actually none that I can remember here in UT threads [but I KNOW you'll find them, if they exist < s >]).

What evidence you're looking for? That above mentioned queries may return incorrect result in VFP7? Or that changes in VFP8 SQL engine was made to correct that?

>Personally, I see nothing wrong with stating outright that something is done to enhance "compatibility" with existing products or SQL (ANSI) 'standards'. But I'd rather see an implementation that was INCLUSIVE rather than exclusive on an issue like this.
>"Inclusive" in the sense that it supported both, even providing some warning in SYS(3054) when ANSI is broken in a query.

You lost me here. Doesn't SYS(3099)/SET ENGINEBEHAVIOR provide such backward compability?