Mike,

I haven't read every word of every message of this thread, but I have heard/read that a **properly** coded GROUP BY will run unambiguously correctly in either ENGINEBEHAVIOR.

That being true, what's really wrong with running at 70 all the time?


>Hi George
>
>>>>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.
>>>>
>>>
>>>Funny, when it comes to spacing in code, you don't seem to agree with that! ;)
>>
>>Moi???? I'm positively AR when it comes to spacing. Spaces between operators, after commas in parameter lists, minimum 2 space indentation. etc., etc. In fact, since I'm in charge of standards at work, one of the first questions that I asked the members of our group was, "What's the purpose of indentation? What does it demonstrate?"
>>
>>Sorry, Mike, I don't get what you're referring to.
>>
>
>I thought you told me there is a standard for spacing in code. I maintain there is no standard since every programmer has their own *conventions*. I may be over-estimating your convictions about a standard. ;) I thought you left no room for avoiding what you call a standard. If that's true, then your statement that "There's a time to adhere to the standards, and there's a time not to." seems inconsistent.
>
>>I'd say that in future design, most definetly. The results of the fields involved in the functions are, from my experience, unquestionably correct. They've been tested and proven to be so, and, not once in at least the past 10 years has anyone been able to prove otherwise (and believe me, it's been tried). As I said earlier, the values of the fields not involved in the group by clause and not using an aggregate function are irrelevant.
>
>I think relevence is the very heart of the issue. I fear most think the non-aggregate fields are very relevant and rely on them. But if they are not relevant, then why include them in the selection list? See message #779327