The Problem

One of the questions I hear most often is (and I have asked it myself a few times) is, “Why can I not have a multi-value parameter that also allows NULL?”

It is a good question, and one that does not have a simple answer.  The easiest way to justify this restriction is that the meaning of such a parameter is unclear.  If you consider a SQL query that makes use of a multi value parameter, it might look like this:

                SELECT * FROM MyTable WHERE MyField IN (@MyParam)

Passing non-null values in here works quite well by substituting @MyParam with a comma separated list of values.  Expanded, that might look like this:

                SELECT * FROM MyTable WHERE MyField IN (‘Value1’,’Value2’)

You might think that passing null in here would work, but unfortunately you would be wrong.  The first issue is how to translate NULL from something Reporting Services (RS) understands to something the database understands.  Is NULL in RS equivalent to System.DbNull, an empty string, or something else?  Does it need quotation marks around it?  The second problem is that even if we find the right translation, we are still not out of the woods.  This query does not do what you likely want:

                SELECT * FROM MyTable WHERE MyField IN (‘Value1’,NULL)   ß Not going to work

So where does that leave us?  To return the values from a table where a field is null, we need to use the IS operator with NULL :

SELECT * FROM MyTable WHERE MyField IS NULL

Of course now we have lost the rest of our filter.  Combining the two does not work:

SELECT * FROM MyTable WHERE MyField IN (@MyParam) OR MyField IS NULL

This would always return the filtered values AND the records where MyField is NULL.

One Solution

The following trick takes a bit of setting up, but it works quite well.  The first thing you want to do is create a query where we can compare apples to apples.  In other words, we want stop treating NULL differently than any other value.  One way you can do this is to force NULL into a string:

SELECT * FROM MyTable WHERE

                CASE  

WHEN Customers.Region IS NULL THEN 'NULL' 

ELSE Customers.Region  END IN (@Region)

Now we need to pass NULL in to this query as a string.  Let us assume we have a multi-value report parameter whose available values come from another query:

                SELECT DISTINCT MyField FROM MyTable

RS is going to do some massaging of this data to remove the NULL values before presenting the available values to the user.  We need to add that back in not as NULL, but as the string ‘NULL’ instead.  We can modify that query to do this:

                SELECT DISTINCT MyField FROM MyTable

                UNION

                SELECT ‘NULL’ AS MyField

Unfortunately, NULL now appears alphabetized under “N” in your list.  We can tweak this by introducing a sort order in a nested query:

SELECT * FROM

(SELECT DISTINCT  Customers.Region, 1 AS SortOrder FROM Customers

UNION

 SELECT 'NULL' AS Region, 0 AS SortOrder) WithNull

ORDER BY SortOrder ASC

You can now set the default value of this parameter to ‘NULL’ if you like.

[Thanks to BB who suggested using ' NULL' (note the space) instead; this causes it to be sorted to the top of the list without the need for the sort order in a nested query.]

This sample works for the simple SQL query case, but since there are many flavours of SQL running on a variety of DBMSs and, of course, non-SQL queries it is difficult to cover all cases.  This article is meant as a jumping-off point to get you started down the right path.

Showing the Selected Values in your Report

In order to display the selected values of a parameter in your report, you need to know whether or not the parameter allows multiple values.

Single-value Parameter

If you are using single-value parameters, the solution is trivial: set the expression of the textbox in which you wish to display the value to

=Parameters!ParameterName.Value

You can use ‘=Parameters!ParameterName.Label’ to display the label instead.

Multi-value Parameter

If the parameter is a multi-value parameter, then the expression gets a bit more complicated.  Multi-value parameters are represented as arrays and the expressions that use them need to account for that.  Using the above expression on a multi-value parameter would result in an error at view time.  Report Builder is a bit nicer when selecting a multi-value parameter from the values list in the expression builder; it builds an expression that will not result in an error, but it is not particularly useful either: ‘=Parameters!MyParameter.Value(0)’.  This will only give you the first parameter value in the selection.  The easiest way to change the expression to handle an arbitrary number of selected parameter values is to use the JOIN function, like this:

=Join(Parameters!MyParameter.Label, “, “)

The first argument to the JOIN function is an array; the array index (0) is not needed (nor expected) in this context.

Using the JOIN function works well unless the user has selected a very large number of parameters (or has chosen the ‘Select All’ option).  This could result in a spectacularly long list which might not be that useful.  In this case you might want to limit the number of items to show:

=iif(Parameters!MyParameter.Count<5, Join(Parameters!MyParameter.Label, “, “), “5 or more!”)

Select All: Special Case

Suppose that you want to show the entire list of selected parameter values, unless the user has selected all the values, in which case you want to display ‘All’.  This requires a bit of a trick. 

First: the chicken or the egg?  There is no way to get the count of all the possible parameter values in a parameters list at view time unless the user selects them all, but that does not help because, without knowing what that total is, we cannot tell that the user has selected them all.

The trick: hide a parameter that tells us the total!  Suppose you have a dataset that drives the available values of your parameter:

SELECT id, name FROM people

You can create a new dataset (CountValues) that counts the values that your existing parameter will use:

SELECT COUNT(id) AS ValCount FROM people

Now create a new parameter (MyCountParameter) with these properties:
Data Type: Integer
Allow Null: False
Allow Multiple Values: False
Parameter Visibility: Hidden
Available Values: None
Default Values:  From Query “CountValues” (Value field: ValCount)

Finally, set this as the expression on an appropriate textbox in your report:

=iif(Parameters!MyParameter.Count<Parameters!MyCountParameter.Value,Join(Parameters!MyParameter.Label,","),"All")

More to come later.

In the SQL Server case, the queries are simpler, and the query designer even helps me by recognizing query parameters in the query command text and prompting for values.  In the AS case, queries can get pretty complex and query parameters can be anything: scalar values, strings that represent members, strings that represent sets, strings to be used in any number of MDX functions.  This means that there is no easy way for the query designer to determine what to prompt for... so it doesn't prompt for any value, it simply tells you that your parameter is undefined.  Not super helpful.

Until we add a complete MDX parser to the tool to help get past some of the difficulties metioned above, here is a sample of how you can get started:

First:
You'll want to create a dataset called OrganizationsQuery that you can use to use for your report parameter's available values (this is something you won't want to hard code since unique names in AS can be long and ugly).  Your dataset's query might look something like this:

WITH
  MEMBER OrgUniqueName as [Organization].[Organizations].CurrentMember.UniqueName
SELECT
  NON EMPTY { [Measures].[OrgUniqueName] } ON COLUMNS,
  NON EMPTY { (DESCENDANTS([Organization].[Organizations].[Organization Level 01].ALLMEMBERS) ) }
    DIMENSION PROPERTIES MEMBER_CAPTION, MEMBER_UNIQUE_NAME ON ROWS
FROM [Adventure Works]

This will give you results that look like this:
Organizations                     OrgUniqueName
AdventureWorks Cycle        [Organization].[Organizations].&[1]
European Operations          [Organization].[Organizations].&[9]
France                               [Organization].[Organizations].&[11]
Germany                            [Organization].[Organizations].&[12]
etc...

Note: To build this query you will have to modify MDX directly.  Use the right-most toolbar button to change to MDX editing mode.

Second:
Create a report parameter called @OrganizationsRP
-Set the Available Values to use the OrganizationsQuery dataset
  -Set the Value to OrgUniqueName
  -Set the Label to Organizations

Third:
Create a dataset called (FinancialAmountBySelectedOrganization):

SELECT
  NON EMPTY { [Measures].[Amount] } ON COLUMNS,
  NON EMPTY { strtoset(@OrganizationQP) }
    DIMENSION PROPERTIES MEMBER_CAPTION, MEMBER_UNIQUE_NAME, PARENT_UNIQUE_NAME, LEVEL_NUMBER ON ROWS
FROM [Adventure Works]
  CELL PROPERTIES VALUE, BACK_COLOR, FORE_COLOR, FORMATTED_VALUE, FORMAT_STRING, FONT_NAME, FONT_SIZE, FONT_FLAGS

Note: To build this query you will have to modify MDX directly.  Use the right-most toolbar button to change to MDX editing mode.

Executing this query from inside the query designer will not work yet; the query designer does not know what to use for @OrganizationQP.  To fix this, click on the button that has the '@' symbol on it.  Create a new query parameter called OrganizationQP (note that it should match the name used in your query, but without the @), and give it an appropriate dimension, hierarchy and default value(s).  MDX query parameters need default values because the query needs to be executed in order to retrieve the schema (field names, etc.)

Finally:
Make sure that your dataset properties map the query parameter (OrganizationQP) to the report parameter [@OrganizationRP].

You should now be able to drop a table on to your report canvas, throw some fields from your FinancialAmountBySelectedOrganization dataset into it, and run the report.  The table will only display results that match the parameters you select at view time.