Skip to main content
hic
Former Employee
Former Employee

On the discussion forum, I often see people posting questions around expressions that don’t work. When looking at the descriptions, I usually find that the reason is that the expressions lack aggregation functions. So, here is a suggestion...

Always use an aggregation function in your expression.

The reason is that a field reference in an expression always means an array of values. Which in turn means that you must enclose it in an aggregation function to make it collapse into one value:

      OrderDate             An array of values

      Max(OrderDate)     A single value

If you don't use an aggregation function, QlikView will use the Only() function. Hence, if the field reference returns several values, QlikView will interpret it as NULL, and the expression will not be evaluated the way you want it to.

Example 1: Use of the If() function:

If() functions are often used for conditional aggregations:

      If( OrderDate >= vReferenceDate, Sum(Amount) )

At first glance, this expression may look correct: For dates after a reference date, the field Amount should be summed. Right?

Wrong.

OrderDate is a naked field reference: It does not have an aggregation function. Hence, it is an array, possibly with several values, and if so, evaluates to NULL. If you are lucky, there is only one date per dimensional value in your chart, and the expression will calculate fine. However, QlikView will probably not be able to calculate the expression for the subtotals in the chart, since there for those exists several dates.

A correct expression that always works should use a Min() or some other aggregation function in the first parameter of the If() function:

      If( Min(OrderDate) >= vReferenceDate, Sum(Amount) )

Or, alternatively, the If() function should be put inside the Sum() function:

      Sum( If(OrderDate >= vReferenceDate, Amount) )

In the first of the two expressions, the If() function will be evaluated once per dimensional value; in the second once per row in the raw data. The results are slightly different, but both return an answer, as opposed to the original expression. The picture below shows the difference between the expressions, using 2013-02-01 as reference date.

If function.png

Example 2: Sort by expression:

The expression used to sort the dimensional values in a chart is also an aggregation. Often you don’t think about this since you choose an expression that returns just one value per dimensional value, and then a naked field reference works fine.

But sometimes this still doesn't work…

For example, say that you want to show support cases in a CRM system. You create a chart with the support case as dimension and some measure as expression. Of course you want to sort the support cases chronologically, so you use "Sort by Expression" and as expression you choose

      [Opening Date]

This will work in most cases. However, some CRM systems allow you to re-open a support case, hence assigning two opening dates to one single support case.  For these cases, the above expression will not work.

Instead, you should always ask yourself which function to use, should there be two values. The answer is usually Sum(), Avg(), Min() or Max(). In the above case, you should use

      Min([Opening Date]) , or

      Max([Opening Date])

depending on whether you want to use the first or last date.

Bottom line: Use aggregation functions, not just in your chart measures, but also in sort expressions, labels, show conditions, calculation conditions, text boxes, sheet names and searches.

HIC

 

Further reading related to this topic:

It’s all Aggregations

Aggregations and Function Classes

42 Comments
Anonymous
Not applicable

Henric, very interesting post. I didn't realise, that there could be so many problems. Seems to be, that I where lucky until now, to always have an expression without an aggregation that works fine. I will have an eye on it.

0 Likes
5,269 Views
Not applicable

Ioanis,

I agree, its tricky, and who says its the right way to do this?  I think it is one way, not always the right way.  I always prefer my developers to use code thats easy to understand, and efficient.  I have seen bad code done both ways. (I have myself written bad code, both ways )

I also think the example Henric Cronström was using was to demonstrate the Naked Field Reference

0 Likes
5,269 Views
giakoum
Partner - Master II
Partner - Master II

I need to insist on that Richard. Set analysis is definitely the right way. Check out all best practices documents from QlikTech, it is not only me saying that....

0 Likes
5,250 Views
martin_dideriks
Partner - Contributor III
Partner - Contributor III

If not both fields (OrderDate and Amount) are to be found in the same table and you use the expression sum(if(...)), your chances to get a wrong result is pretty big caused by multiple values.

loannis Giakournakis is right..Learn the Set Analysis as this will give you the correct result.

I am not sure, though, that the point with Henrics post was to teach everyone best practices.

As I see it, it is how QV in general works.

5,250 Views
Anonymous
Not applicable

HIC Thnx !!

understood what you want to say or suggest

If( Min(OrderDate) >= vReferenceDate, Sum(Amount) )

Or, alternatively, the If() function should be put inside the Sum() function:

      Sum( If(OrderDate >= vReferenceDate, Amount) )

not understood the this line :

"In the first of the two expressions, the If() function will be evaluated once per dimensional value; in the second once per row in the raw data"      

If() function will be evaluated once per dimensional value ?? What does that meann

Anant

0 Likes
5,250 Views
hic
Former Employee
Former Employee

If you put the If() outside the aggregation function (the first example), then the If() will be evaluated once per dimensional value, i.e. once per row in the pivot table or once per slice of the pie chart.

But if you instead put the If() inside the aggregation function (the second example), then the If() will be evaluated once per row in the raw data, which could mean a considerable performance problem.

HIC

5,250 Views
IAMDV
Luminary Alumni
Luminary Alumni

Another good foundation & must know lesson for all the Qlikers. Many thanks HIC.

0 Likes
5,250 Views
Anonymous
Not applicable

Make sense , thanks for your Prompt Answer !!

0 Likes
5,250 Views
whiteline
Master II
Master II

Hi Henric.

I doubt that this:

Sum(If(OrderDate >= vReferenceDate, Amount))

implicitly implies this:

Sum(aggr(If(OrderDate >= vReferenceDate, Amount), OrderDate, Amount))

So that it can lead to the unexpected results in case of orders for the same date and amount.

I guess it's the second most popular mistake after the lack of aggregation functions.

In such a case (if under the aggregation) I usually suggest (upd: not anymore) to use explicit aggr() function to be sure the granularity that is used for the condition calculation.

In this case it could be the field that truly represents the row:

Sum(aggr(If(OrderDate >= vReferenceDate, Amount), OrderID))

0 Likes
5,238 Views
hic
Former Employee
Former Employee

No, the two expressions are not the same. The Sum(...) function is a sum over all records in the source data, whereas the Sum(Aggr(..., Dim)) is a sum over the records created by the Aggr(), i.e. the number of records is determined by the number of distinct values of Dim.

Further, you need to have an aggregation function as first parameter in the Aggr() function. It needs to be a single value. The Aggr() function is just like a for-next loop. The following are correct constructions:

OrderDate             An array of values

Max(OrderDate)     A single value

Aggr(Count(OrderDate), … )       An array of values

Max(Aggr(Count(OrderDate), … ))           A single value

HIC

5,238 Views