>>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,
>
>Your query will produces incorrect result if the assumption is incorrect. Properly written query doesn't require any assumptions.

If you write code that'd make the assumption a reality in the first place then it works out as perfect. If data with physical order does not match the time order you already have problem in data you have. Proper query doesn't help you identifying that situation.
Cetin