Like parameters, report filters can limit the results of data on a report; however, you don’t nec-essarily have to use them in conjunction with a parameter. In fact, filters, which can be defined at many points in the report, evaluate an expression and filter the results based on that evaluation. Filters take this form:
<Filter Expression> <Operator><Filter Value>
An example of a filter is one that limits the data on a report to a specific user or that is based on user input from a parameter value.
Chapter 9 demonstrates how to use a filter that limits the report based on a built-in Global collection, which includes the username of the person executing the report. Filters are beneficial in that once the report is rendered, you can use them in conjunction with parame-ters to limit the data in the report without requerying the data source. In Figure 3-9, you can see a filter that limits the data displayed based on a parameter called User. The logic is this: if the parameter value for Useris equal to a field value of User, then include only those records where they match and otherwise include all records. Parameters and filters are included as elements of an RDL report file.
Listing 3-3 shows the sample RDL elements.
Listing 3-3. Parameter and Filter RDL Elements
<ReportParameter Name="User">
<DataType>String</DataType>
<Nullable>true</Nullable>
<DefaultValue>
<Values>
<Value>= nothing</Value>
</Values>
</DefaultValue>
<AllowBlank>true</AllowBlank>
<Prompt>User</Prompt>
<ValidValues>
<DataSetReference>
<DataSetName>User</DataSetName>
<ValueField>fullname</ValueField>
<LabelField>fullname</LabelField>
</DataSetReference>
</ValidValues>
Figure 3-9. Sample filter on a table data region
<Filter>
Throughout this section, you’ll use fields from the dataset to create sample report segments.
Because the values from the fields are derived from expressions that are essentially VB .NET code, we will cover them now because they play a crucial role in the report design process.
You can use expressions to produce a value for any report item that uses them. In SSRS, you can assign expressions to almost any report property, from formatting such as color or padding to the value of a textbox. A simple expression such as that of a field assignment is commonly used while designing reports. In fact, every time you add a field to an area of a report, it’s automatically converted to an expression, like so:
=Fields!FieldName.Value
An expression is signified by prefacing its content, typically a VB .NET function, with the equal sign (=). You can also concatenate expressions with other functions and literals. We will show several examples of expressions throughout the book. We will list several sample expres-sions here and show how to assign them to report items:
• =Parameters!ParameterName.Value: Used to assign the value of a parameter to a report item such as a textbox or cell in a table.
• =IIF(Fields!FieldName.Value > 10, Red, Black): You use the IIFfunction for condi-tional expressions. In this case, it would set the color for a property, such as the text color to red, if the value of FieldNamewas greater than ten.
• =Fields!FieldName1.Value & " " & Fields!FieldName2 .Value: Used to concatenate the value of two fields.
• =Avg(Fields!FieldName.Value): Aggregate functions such as Sum, Avg, Min, and Maxthat return the average value of the fields.
• =RowNumber(Nothing): Used to maintain a running total for the row numbers in a report.
Nothing in this case is a scope parameter passed to the function indicating a grouping or dataset. The scope parameter could be a group name or dataset, in which case a new row count would begin at the end of each group or dataset.
In SSRS for SQL Server 2005, the expression builder application that is used inside the report development environment was rebuilt to give it the type of functionality that is required to assist users in easily creating useful expressions. The former incarnation of the expression builder, released with SSRS for SQL Server 2000, was little more than a text-entry box, with limited report object selections. Report designers needed to be intimately familiar with VB
.NET functions or spend time muddling through help files to find the appropriate syntax. With the new expression builder, most of the common functions are listed, along with their syntax;
in addition, they are categorized based on their type, that is, Text, Conversion, and Date & Time.
This makes it much quicker to find the right function and place it as part of the expression you are building. Another great feature that developers have become accustomed to, and frankly should not have to live without, is IntelliSense, which is a contextual, in-line command com-pletion feature. As you can see in Figure 3-10, as you are typing the expression (in this case a field value expression from your stored procedure), you are prompted with all the possible selections based on that expression. Once the expression is complete and syntactically correct, you can click OK, and the expression will become a part of the report object where you have associated it. If any syntax errors exist, these will be evidenced by a standard red underline that indicates a problem. Hovering the mouse over the red underline will display the type of error; in most cases “Invalid Syntax.”