I agree with this. OTOH I have cases where I tend to live with the wrong result. I have some stuff that is not 100% normalized. Lets say a unit is used. This is a information that is nothing then nice, it has no influence into any process. This is plain text and used over and over. Normaly it comes as import so all is fine. Sometimes the user enters code via UI so he uses pcs, Pcs, Pieces, t, ton, Tons. Normaly he does not mix up tons with pieces, so there is no real problem. In the old syntax, I just ignore the field and it gives a text. It might not be 100% accurate but good enough. (everybody how deals with the system knows the correct units anyway) So now it spreads me the summation into a couple of records. This is very unexpected. Ok I could do min or max or some other aggregate on unit but this agian raises the chance of wrong resluts for mixed pieces and tons.

So I'm not realy happy.

Agnes

>It's not a problem as long as you know what you're doing. However, many programmers do not understand that "correct result" they're getting from such query is by chance not by design and it can become incorrect when data changes in the future.
>
>>Not in any case. For example if you have a 1 to n and sum all n's and display fields from the 1's then the PK is the only thing you really need. The rest will be from the 1 record anyway. So it's a lot of superfluous work to check each non aggregate for changes. I found it to much work to redesign all the views etc and stuck with the old behavior.