Two commonly-used functions in Reporting Services are the IIF() and the Switch().  These are two functions of the Program Flow type, or Decision Functions as they are called on this MSDN page.

In case you’re wondering why it’s so difficult to find a function reference for the built-in functions of SSRS, it’s because these are actually Visual Basic functions and Microsoft refers to those for any detailed explanation.  Click this link for the IIF() function in the Visual Basic Language Reference, and this one for the Switch().

Anyone who’s done some programming most likely already knows the if <expression> then <some_code> else <other_code> statement.  If <expression> evaluates to true then <some_code> gets executed, else <other_code>  gets executed.

The IIF() works in the same way.  According to its description it

Returns one of two objects, depending on the evaluation of an expression.

This is its definition:

Public Function IIf( _
ByVal Expression As Boolean, _
ByVal TruePart As Object, _
ByVal FalsePart As Object _
) As Object

Here’s a simple example:

=IIf(Fields!YearlyIncome.Value >= 60000,"High","Low")

Using this expression, the "High" string is returned when the value of the YearlyIncome field is equal to or above 600, while the string "Low" is returned when the value is below 600.

Now have a look at the following example.  It has been nicely structured with indentation and line breaks to make reading easier.

=IIF
(
    Sum(Fields!LineTotal.Value) >= 100,
    "Violet",
    IIF()
    (
        Sum(Fields!LineTotal.Value) < 25,
        "Transparent",
        "Cornsilk"
    )
)

As you see, it shows a nested IIF inside another one.  Imagine that there were several more nestings and that line breaks were not used by the coder.  Would be a nightmare to read, right?

That’s why the Switch() was invented.  The description for the Switch function reads:

Evaluates a list of expressions and returns an Object value corresponding to the first expression in the list that is True.

And this is the function definition:

Public Function Switch( _
    ByVal ParamArray VarExpr() As Object _
) As Object

In Reporting Services, the VarExpr parameter is simply an even list of expressions and/or object references separated by commas.  Which comes down to something like this: Switch(<expr1>, val1, <expr2>, val2).

Here’s a simple example:

=Switch
(
    Fields!State.Value = "OR", "Oregon",
    Fields!State.Value = "WA", "Washington"
)

This expression says that if the value for the State field is "OR" then the Switch function will return "Oregon", and so on…

Now, to get to the point of this article, the Switch function does not contain an ELSE part like the IIF does.

But I wouldn’t be writing this if there wasn’t a workaround, would I?  If you read the Switch’s description closely, it says that it will return the first expression in the list that is true.  So each expression is evaluated in the order that they are passed to the function.  To get ELSE-like behavior we would need an expression that evaluates to True but only when all other expressions are False.  So, why not use True as expression?  It’s the simplest expression that I can think of and it does the works!

Have a look at the following, it’s a rewrite of the last IIF example mentioned earlier.

=Switch
(
    Sum(Fields!LineTotal.Value) >= 100, "Violet",
    Sum(Fields!LineTotal.Value) < 25, "Transparent",
    True, "Cornsilk"
)

So, which one do you think is the most readable?  The IIF, or the Switch?  These are only simple examples that I’ve been using, imagine situations with ten or more possibilities.  Well, I think you’ve got my point by now.

Quick tip for users of Report Builder 2.0: to be able to format your expression with line breaks and tabs, you need to use CTRL + ENTER or CTRL + TAB in the Expression Builder.  Just hitting ENTER will close the popup window.  It’s quite annoying if you’re used to the BIDS interface, but it works

Happy reporting,

Valentino.

This report cannot be run in report builder because it contains one or more embedded data sources with credential options that are not supported.  Instead of embedded data sources use shared data sources or save and view the report on the server.

Okay, no problem I thought, let’s just create a shared data source and switch to that one then.  So I opened up the Data Source Properties in Report Builder and selected the Use a shared connection or report model radio button.

Unfortunately, when running the report it threw me that same error?!  And when I open the Data Source properties again, my change was undone!  It was still using the embedded data source.

As far as I’m concerned that should be a bug.

The only way that I could switch my data source to a shared connection was by creating a new data source, which means you also need to move all datasets connected to the original data source.

Quick tip: if you first rename the original data source and datasets to something like srcMyDataset_OLD, you can give the correct name to the new one straightaway.

So I guess that’s another workaround on my list

This issue was encountered while using Report Builder 2.0 (10.0.2531.0).  I tried to reproduce it using Report Builder 3.0 (10.50.1092.20 – that’s the version of the SQL Server 2008 R2 August CTP) and I couldn’t.  Which means it has been fixed.  Good on you Microsoft!