>>Despite someone says that this is not documented,
>>I don't believe someone succeeds in finding an against example.
>
>One example I could quote to you would be that previous version of VFP allowed to include fields in the dields list that were not aggregates nor part of the group by. This was a quirk of VFP and not part of standard SQL syntax. Suddenly one day they fixed it and then a whole bunch of code had to revisited.

Every thing can change into a dev env.

However, to make that GROUP BY doesn't return orderly records,
it needs that the VFP SQL engine
- uses indexes to optimize GROUP BY
- uses techniques of hashing to join two tables

But if this happened, then the engine could optimize also ORDER BY (as in MSSQL),
and therefore to remove ORDER BY would not have sense anymore.

I am sure, that this won't happen.

BTW, is VFP9 the end version ?

>
>It is a bad idea to depend on a sideeffect of a specific implementation of SQL. Your code is then NOT portable to other SQL environments like SQL Server or Oracle.

This can be true, but all it takes is documenting the code, and when he passes to SQL/DB2/ORACLE... to systematize the syntax.
I don't believe that it exist any non banal (handwritten) code that can be brought
from a backend to another without analysis.

However, with all the problems that are in VFP, this for me is the last worry.