In theory yes, but in practice only marginally. But by setting EB to 70, you also take a risk which it's up to you to consider whether it's worth it or or not. Remember that's not without a good reason that the SQL engine was changed, primarily this was done to make VFP more ANSI compliant. This means that for all EB=70 you set, you must change your select statements later if you switch to a "real" SQL server.

My advice is to consider any EB setting other than default as band aid to stop the bleeding. Personally I prefer to fix the problem instead of fixing the symptoms.

>But if you set EB to 70, will this:
>
>Select UserID, MemberName, Count(*) as NTally Group by UserID
>
>...typically run faster than this:
>
>Select UserID, MemberName, Count(*) as NTally Group by UserID, MemberName
>
>????
>
>
>>>Jim,
>>>I was wondering: Assuming that the data is known well enough to know that it won't produce ambig results, can you just flip to EB 70 and run the query and then flip EB back to a newer version? Also, if you do this, will the query then run faster by omitting the extra group-by elements? Kind of a concidence that I happen to have some situations like that... i.e., where you don't necessarily need to "group by" all non-aggregated items listed in the select clause in order to get unambiguous results.
>>>
>>>For example, if a UserID is always uniquely associated with one MemberName, and you do:
>>>
>>>Select UserID, MemberName, Count(*) as NTally Group by UserID
>>
>>In this case then you have no problem with
>>
>>Select UserID, MemberName, Count(*) as NTally Group by UserID, MemberName
>>
>>OR
>>
>>Select UserID, MAX(MemberName) AS MemberName, Count(*) as NTally Group by UserID
>>
>>which both follow the ANSI standard for SQL syntax.