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
whiteline
Master II
Master II

Yeah, you're right, the loop is performed for each record without 'distinct' whether the fields are in the same table or not.

Probably, the join that is performed in case the fields are from different tables, confused me sometime ago in an incorrectly designed datamodel.

Furthermore, the expression with simple if() has really much better performance, especially if the fields are not in the same table.

Thanks for clarification.

0 Likes
5,180 Views
robert99
Specialist III
Specialist III

Agree. Set analysis is a bit of a nightmare when it comes to this sort of formula

Sum ({$<OrderDate = {'>=$(vReferenceDate)}'} Amount))

Much easier is

OrderDate >= vReferenceDate

And I think OrderDate > SalesDate does not work anyway in set analysis (at least i can not get it to work)

5,180 Views
whiteline
Master II
Master II

Hi, RJ.

If you mean the condition OrderDate > SalesDate to select the orders, you can do it with set analysis like this:

Sum({<OrderId={'=OrderDate>SalesDate'}>} Amount)

5,180 Views
hic
Former Employee
Former Employee

@ whiteline

Your search expression will work in most cases, but only because there is only one OrderDate and one SalesDate per OrderID. Both OrderDate and SalesDate are naked field references, so the search will not work if there are several SalesDate:s per OrderID.

HIC

5,180 Views
whiteline
Master II
Master II

Henric Cronström

I understand that. There is some lack of context about the data model.

Anyway, returning to the theme topic, in most cases we have to use aggregation within set analysis too )

0 Likes
5,118 Views
Not applicable

Thanks for this share....

0 Likes
5,118 Views
robert99
Specialist III
Specialist III

Sum({<OrderId={'=OrderDate>SalesDate'}>} Amount)

Thanks for this. It works in my case. I actually was using it for a service business. To measure the number of calls completed within the required time

So Count  ({<Call_Num={'=Call_ResponseDate >= Call_StartDate '}>} distinct Call_Num)

rather than count (if ( Call_ResponseDate >= Call_StartDate , distinct Call_Num))

0 Likes
5,118 Views
shawn-qv
Creator
Creator

A useful blog highlighting on the difference between if(sum) and sum(if) which I think a lot of people don't think much about.

Hopefully this is now more clear, as it's quite fundamental to understanding how QV reads and performs aggregation.

0 Likes
5,118 Views
barryharmsen
Luminary Alumni
Luminary Alumni

Henric Cronström Would it also be correct to say that placing single dimensions (with or without the Only() aggregation function) in the expressions tab instead of the dimensions tab would cause them to be cached differently? (or, cause them to be included in the cache) I recently did a health check on a QlikView application where developers had put all but one of the dimensions into the expressions tab and the chart was using lots of RAM and had a really poor response time. Just moving all the dimensions to the proper tab caused the chart to calculate 5 times faster and also reduced RAM consumption.

0 Likes
5,118 Views
hic
Former Employee
Former Employee

Yes, they will be cached differently. Where to put a field - as dimension or expression - is a question that has different answers in different cases. Adding a dimension is often not a good idea since it may increase the size of the cube. Then it is better to have the field as dimension expression instead. In your case it was obviously the other way around, probably because the added dimensions didn't increase the size of the cube significantly.

HIC

0 Likes
5,118 Views