>>>I loaded VFP9. One of my older applications has many SQL statements that will no longer run because of the GROUP BY clause and the not havine an aggregate function. So in the main.prg I SET ENGINEBEHAVIOR 70. Still, one of my SQL statemetns got an error. In the debugger SET ('enginebehavior') = 90. But my SET ENGINEBEHAVIOR 70 is the only other place that I reference ENGINEBEHAVIOR. What is up?
>>>
>>>Brenda
>>
>>Not an answer to your real problem, but be aware that by setting enginehaviour to 70, you risk getting WRONG data! I strongly recommend that you change your select statements to comply with the ANSI standard. Set enginehaviour to 70 is band aid to stop the bleeding, it will cure nothing.
>
>I do not buy the arguement that 70 gives you WRONG data. So everyone coding in Fox and VFP prior to VFP8 were getting wrong data? Thousands of systems were built on VFP6, VFP7 and prior versions and nobody complained about wrong data. But yes, I am making the changes where I am able, but some older systems - that work - will not be given the hours needed to make them SQL standard.
>
>Brenda

I'm with you:) Knowing what you should expect from return ENGINEBEHAVIOR doesn't return incorrect results. They might be 'incorrect' from ANSI standards POV but VFP SQL is not fully ANSI standard anyway. Sometimes what's proposed as 'incorrect' is the actual resultset that one would like to get. ie: Assuming logintime field is physically resembles actual logintime order:

select loginId, logintime from myTable group by 1

would be 'correct' resultset showing last logintimes per ID. Or consider another sample:

select customer.*, max(order_date) as lastordate ;
 from customer ;
 left JOIN orders ON orders.cust_id = customer.cust_id ;
 group by customer.cust_id

would give perfectly 'correct' result with ENGINEBEHAVIOR 70.

In migration what I do is "set enginebehavior to 70" in main.prg and where I can revise or write new SQL wrap it:

set enginebehavior 90
*...
set enginebehavior 70

Cetin