>whow,whow, whow.....
>
>George,
>
>>I'd have to disagree completely. First, you obscure the intended output. Second, you're messing with working code (If it ain't broke, don't fix it). Third, and most importantly, you're introducing completely unnecessary processing overhead with the function calls.
>
>I'd have to agree that in existing code, a SET ENGINEBEHAVIOUR is the most easy solution. I use this very same strategy in existing projects. So yes, I agree that in many cases this is the most easy solution.
>
>HOWEVER, it's not compatible with most other SQL implementations. In my cases I'm faced with an application that has to work with either local or remote data. Having the same SQL syntax is important so that I don't have to write different SQL statements for each situation. Further, the undocumented VFP SQL-SELECT ... GROUP BY behaviour is a problem when upsizing existing applications. IMO, it is wise to use the new behaviour for new projects as the chances are that it has to be upsized some day.
>
>Also, I'm not sure about the overhead of having a MAX() function in the clause. Have you done tests to support this claim. If I look at the problem, the MAX() function is not that different from the selecting the last row in a group. Some minor test do not support your claim. Please give me some figures. If the difference is less than say 5%, performance should not be an issue.
>
>I'm aware that in situation that you specificly want to display the last row in a group, there is no real comfortable alternative to the ENGINEBEHAVIOUR 70. OTOH, if you take to following real world example:
>
>

SELECT Article, Description, Location, ...., SUM(InStock) ;
>    FROM Articles A ;
>        INNER JOIN Stock S ON A.Article = S.Article ;
>    GROUP BY Article

>where result is just the article table with the In stock value from the joined stock table. Because all the other fields in the article table are the same within each group. It does not matter to write a
>
>

SELECT Article, MAX(Description) AS Description, MAX(Location) AS Location, ...., SUM(InStock) ;
>    FROM Articles A ;
>        INNER JOIN Stock S ON A.Article = S.Article ;
>    GROUP BY Article

>
>Which should work in all SQL implementations
>
Walter (and Mike too),

Take a look at my response to Jim Booth (MESSAGE#774526) before going on.

Assuming that you've done that, what I'll say is that in all cases it is neither necessary nor advantageous to do anything other than use SET ENGINEBEHAVIOR.

My original post was meant to be purely applied to VFP SQL statements, not any other environment. That was the context of the original question. Certainly, there are cases where sticking to strictly SQL-92 is the best an most obvious choice. However, this should not be blindly applied to every situation. In fact, where writing an SQL Server stored procedure, one would not by-pass T-SQL simply because it is an extension of the standard and not supported by other backends.

There's a time to adhere to the standards, and there's a time not to. The trick is knowing (through analysis of the requirements) when and where.

And Walter, adding unnecessary functions, such as MIN(), to an SQL statement unquestionably adds additional processing overhead. There's no question about it.