In the designer we define the behaviour of the indicator (sum, max, min …).
We can also add this propertie directly in the sql code : sum(mytable.myindicator), I think it should be done like this for QAAWS.
But what about the difference in the final result ?
Is it dangerous to define the aggregattion in the SQL code only for some element.
–> 1 query with a group buy
–> another whithout group by (made by the report)
–> kind a synchronisation ?
mathieuBO (BOB member since 2011-01-06)
In SELECT - using SUM() will cause group by
Aggreagation - using SUM will enable summing up of the result at the report level depending on teh dimension.
Hope this clarifies…
-Aruna
arunmozhi 
(BOB member since 2007-12-26)
Measures should have an aggregate function defined for them - sum, max, count, etc.
Projection varies - sum and count project as sum for example.
Defining a measure with a projection but without an aggregate function means that you will be bringing back far more rows than you need in the query results.
which is the best approach out of the two mentioned above.?
neetuc (BOB member since 2011-03-01)
I know I’ll bring more raws and this is the problem with QAAWS because their is not aggregation as WebI does.
If I don’t care of qaaws, could there be differents results with and without aggregation ?
What about if in my universe I have some objects with a SQL aggreation and some other don’t have ?
mathieuBO (BOB member since 2011-01-06)
Bad things can happen. 
I’ve written up a longer description to this issue on my blog here:
Dave Rathbun 
(BOB member since 2002-06-06)
The best approach is to define aggregate functions for measures. Why have them as measures otherwise? 
(BOB member since 2002-06-20)