>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.

Ah...In this case the "standard" I was referring to was ANSI SQL-92. Standard may be a poor choice of words here. Better may be something like "rules imposed by...". In the case of writing code, I think that "coding standards" and "coding conventions" are probably interchangable. My coding standards/conventions are, generally, not subject to being broken.

This does not mean, and I never intended to imply that, all of these are always adhered to, especially if there is no other solution possible. For example, jumping out of a loop or multiple returns aren't allowed unless there is a significant and quantitatively justifiable reason for doing so.

>>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

To answer the question, if you have multiple SQLs that calculate the same thing, with the only difference being the non-aggregate fields in the group by clause, there's no compelling reason to create multiple SQL statements to generate the result sets. In some ways, this violates, in fact, one of the basic tenets of both structured and object oriented programming, "There should be only one place where a particular function or procedure exists." IOW, you create multiple instances of the same code by creating an SQL statement that has only the difference of the non-aggregate fields in the group bny clause.