I recently had my first opportunity to use Alternate States on a real project. As awesome as I think Alternate States are, I just haven’t had a chance to implement them before now.

As I was developing the expressions for my charts, I came across a predicament. And after some hand-wringing and head-scratching I realized it was a result of how I’ve been treating the set identifier, `$`

.

As a reminder the set identifier `$`

is the default set. It represents the entire data model PLUS all user selections. Insofar as it is the default, it doesn’t need to be explicitly included in the expression. Meaning, when the `$`

is omitted in a set analysis expression, QlikView defaults to the default set. In other words,

`sum({ $ } Sales)`

is equivalent to: `sum(Sales)`

just as

`sum({ $ <Year = {2010}> } Sales)`

is equivalent to: `sum({ <Year = {2010}> } Sales)`

(notice the dollar-sign is absent in the 2nd expression)

Now, although the `$`

is not required, I have diligently included it in any and all expressions that use set analysis, rather than letting QlikView default it. My reasoning on this was to prefer the explicit over the implicit, i.e. leaving nothing to chance and more importantly, improving code understandability. And I’ve coached my students and clients to do the same.

“Always include the dollar-sign.”

B. Lay, said to dozens of students

…turns out that wasn’t such great advice!!

#### $ vs. Alternate States

So here comes the rub …

Without alternate states, the situation is simple: there is one and only one “default” state ($); namely the state of **all user selections**. But with alternate states defined, the concept of a “default” is no longer simple.

Instead of a single “default” state there are now:

- the document default state, $ – this is the state we’re familiar with prior to version 11
- a sheet state – which
*could be*$, inherited from the document-level or one of the alternate states - an object state – which
*could be*$, inherited from the sheet-level or one of the alternate states

Additionally, any expression in any object can either inherit the state of the object or be controlled via set analysis. And this is the **key point**: `sum({ $ } Sales)`

and `sum(Sales)`

now have potentially different meanings.

By hard-coding the $ in the set, we are explicitly choosing the good old-fashioned default state – all user selections. This ignores the alternate states. In fact, even if the object is assigned to an alternate state, by placing the $ in the set expression we are ignoring that alternate.

Contrast this to omitting the dollar-sign: `sum(Sales)`

In this case we are accepting whatever state the object is in. That *could be* the default set `$`

… or it could be an alternate state, if indeed the object is assigned to an alternate state.

**By omitting the dollar-sign we are allowing the set expression to “inherit” the object’s state.**

**My Mistake**

Back to my issue (it’s all about me!) … I had created two identical charts, one in State A and the other in State B. And two groups of list boxes, one State A and the other in State B. Each chart had several expressions and included set analysis (for other calculation reasons). Here are the details (note I’m obscuring the client’s actual field names):

- Chart 1 – State A
- Expression 1:
`sum({$ <CurrYTD = {Y}>} Sales)`

- Expression 2:
`sum({$ <CurrYTD = {Y}>} COGS)`

- Expression 3:
`sum({$ <CurrYTD = {Y}>} Units)`

- Expression 4:
`sum({$ <CurrYTD = {Y}>} #OrderCounter)`

- Chart 1 – State B
- Expression 1:
`sum({$ <CurrYTD = {Y}>} Sales)`

- Expression 2:
`sum({$ <CurrYTD = {Y}>} COGS)`

- Expression 3:
`sum({$ <CurrYTD = {Y}>} Units)`

- Expression 4:
`sum({$ <CurrYTD = {Y}>} #OrderCounter)`

So this is following my old-fashioned approach of always including the set identifier $.

Hence, to my chagrin, when I clicked on values in my State A and State B list boxes, nothing changed. Again, because I had overwrote the object state by using a $ in my set analysis expressions. The fix for this was quite easy; simply removing the $ from the expressions.

- Chart 1 – State A
- Expression 1:
`sum({ <CurrYTD = {Y}>} Sales)`

- Expression 2:
`sum({ <CurrYTD = {Y}>} COGS)`

- Expression 3:
`sum({ <CurrYTD = {Y}>} Units)`

- Expression 4:
`sum({ <CurrYTD = {Y}>} #OrderCounter)`

- Chart 1 – State B
- Expression 1:
`sum({ <CurrYTD = {Y}>} Sales)`

- Expression 2:
`sum({ <CurrYTD = {Y}>} COGS)`

- Expression 3:
`sum({ <CurrYTD = {Y}>} Units)`

- Expression 4:
`sum({ <CurrYTD = {Y}>} #OrderCounter)`

#### The Takeaway

Well, despite the resiliency of old habits 🙂 I will now be omitting the $ in my set expressions.

Keep on Qlikin’

Bill

Thanks for this post, Bill. I first heard about alternate states just today. Your post will help me to avoid making the same mistakes you made.

Thank you for sharing, Bill! Someone asked me this question few days ago, and your article was very helpful to resolve the issue. As you can guess, this user had $ in his set expressions.

Thanks Bill. After a couple of hours of head scratching you have just resolved why my charts are not showing the alternate state data. Now to remove a few $ signs