Summary: This white paper covers best practices on report design and helps you avoid common mistakes when choosing a report layout and output format. Take advantage of existing product features to achieve the results you want. The paper includes report and code examples that implement functionality that is frequently requested. (32 printed pages)

Click here to download the associated sample code, ReportTipsTricksSamples.exe.

Click here to download the Word document version of this white paper, ReportDesignTips.doc.

Introduction
Best Practices and Tips
Report Samples
For More Information

Introduction

Microsoft SQL Server Reporting Services is a comprehensive solution for creating, managing, and delivering both traditional, paper-oriented reports and interactive, Web-based reports from different types of data sources. Reporting Services provides a wide variety of options for report controls that you can use to display data and graphical elements in your reports. You can create reports for your application by using one of the design tools shipped with the product, including Report Designer—integrated with Microsoft Visual Studio 2005—and Report Builder, an ad hoc reporting tool that enables business users to create their own reports and explore corporate data, based on a report model. Reports can be rendered into a wide range of formats such as HTML, XML, CSV, Microsoft Office Excel, PDF, and image files.

Although Reporting Services incorporates commonly used functionality and makes it easy and flexible for users to create and manage reports that meet their specific requirements, report design can be a very challenging task given the complexity of business needs. Report authors face many decisions and tradeoffs when choosing the best way to design and deploy a report. This white paper answers the following questions and provides a set of report and code samples:

What are the best practices for designing a report?
How do I avoid common mistakes when choosing a report layout and picking an output format?
How do I take advantage of existing features to achieve the results I want, when no direct support is present?

Note This document assumes that the reader is familiar with the Reporting Services product, report design concepts, and possesses a basic knowledge on how a report is processed and managed by the report server.

Best Practices and Tips

This section describes some common user scenarios and provides report authors and administrators with useful information to help the decision-making and troubleshooting processes.

Design Your Reports for Performance and Scalability

For their reporting platform, many organizations, from small-scale personal businesses to large enterprises, use Reporting Services as the main information delivery channel for daily operations. When handling large or complex reports, report authors and administrators often encounter questions such as:

Can my report handle a large amount of data?
How will the server be affected when many users view a report during peak hours?
How do I troubleshoot a performance problem?

To achieve the best performance, there are a number of factors you should take into account when designing your reports.

Query Design

A report is processed in the following order: query execution, report processing, and report rendering. To reduce overall processing time, some of the first things you need to decide are which data to retrieve from the data source, and which calculations to include in the report. Reporting Services supports a wide range of data sources, including plain file systems, advanced database servers, and powerful data warehousing systems. The functionality of data sources and the structure of the report determine which operations should be done in the query, as opposed to which operations should be done inside of the report. Although the Reporting Services processing engine is capable of doing complex calculations such as grouping, sorting, filtering, data aggregation, and expression evaluations, it is usually the database system that is best optimized to process some or all of these data operations. With that said, always keep the following in mind:

Optimize report queries.
Query execution is the first step of the reporting process. Having a good understanding of the performance characteristics of your database system is the first step to good query design. For example, you can use SQL Profiler to track the performance of your queries if you use SQL Server as the database server.
Retrieve the minimum amount of data needed in your report.
Add conditions to your query to eliminate unnecessary data in the dataset results.

If the initial view of the report shows only aggregated data, consider using drill-through to display details. Drill-through reports are not executed until the user clicks the drill-through link, whereas show/hide reports or subreports are processed during the initial report processing, even if they are hidden.

Rendering Formats

Reports can be exported into various rendering formats through rendering extensions. Different rendering extensions provide different functionality. Their performance and scalability characteristics are also very different. You must understand the difference in their behavior before you can make the right choice to satisfy your business requirements. For more information, see Choose Appropriate Rendering Formats for Your Business Needs in this paper.

Pagination

Reports are rendered into pages based on where page breaks occur. Although the entire report is processed before the rendering phase, the performance of the rendering extension is significantly impacted by the page size. Also in some case (for example, HTML), how well the report is displayed in the client tool depends on the page size, as well as other factors. For information on the different types of page breaks and how they are used in various rendering formats, see Control Page Size.

Check the Execution Log to Assess Performance

Once a report is deployed on the report server, the administrator will want to monitor the activities associated with the report, including how frequently it is requested, what output formats are used, how many resources are consumed, and other performance information. TheCheck Reporting Services Log Files section describes how to use the execution log to gather this data. It also tells you how to use the information to optimize report execution.

Choose Appropriate Rendering Formats

Reporting Services supports seven rendering formats out of the box—HTML, XML, CSV, GDI, PDF, Image, and Office Excel. A rendering extension interface is also provided for third-party vendors to implement additional rendering extensions to support other formats.

The following table contains a brief description of the built-in rendering extensions. They are listed in the order of memory consumption, from least to the most.

Table 1. Reporting Services rendering extensions

HTML/Webform control	Renders into the format used for HTML 4.0 browsers, including Microsoft Internet Explorer, Netscape Navigator 7.1, and Firefox Web Browser. One of the most popular formats for online and interactive report viewing, as well as the rendering extension used in the ReportViewer Web server control, Report Manager, and for URL access.
XML	Renders the report data as an XML document. If an XSLT transformation is specified through device information settings, the XML rendering extension could consume more memory than the CSV rendering extension.
CSV	Renders report data into comma-delimited plain text files. Also called the Text-rendering extension.
WinForm control/Report Preview	The rendering extension used in the ReportViewer. Windows Forms control draws directly to your screen. It is also used in the preview mode for Report Designer and Report Builder. This is the other rendering format that supports interactive report viewing.
PDF	Renders into Portable Document Format (PDF) that can be opened and viewed with Adobe Acrobat 4.0 or later.
Image	Renders a report as a static image in bitmaps or metafiles. Supported image formats are .bmp, .emf, .gif, .jpeg, .png, .tiff, and .wmf.
Office Excel	Renders reports into Office Excel format. Supports Office Excel 1997 and later versions.

Control Page Size

Controlling page size in the report not only changes the report layout, it also impacts how the report is handled by the Report Processing and Rendering engine. There are three types of page breaks: logical page breaks, soft page breaks, and physical page breaks.

Logical Page Breaks

Logical page breaks are defined in the report definition by using the PageBreakAtStart and PageBreakAtEnd properties in various report elements, including group, rectangle, list, table, matrix, and chart. Logical page breaks are considered in all rendering extensions except for data rendering extensions (XML and CSV).

Soft Page Breaks

Interactive rendering extensions (HTML and WinForm control) use the report's InteractiveHeight and InteractiveWidth properties to determine page size. The rendered pages can be slightly larger than the specified size; therefore, they are called soft pages. Soft pages were introduced to solve the issue of getting long pages in HTML when report authors did not include logical page breaks in the report definition to achieve reasonable page sizes. Very long pages are not only unreadable, but also cause performance problems in Internet Explorer. Soft page breaks can be disabled by setting the InteractiveHeight and InteractiveWidth to zero.

Physical Page Breaks

Set the PageHeight and PageWidth properties on the report controls where physical page breaks occur. Physical page breaks are used in physical page rendering extensions, such as PDF and Image. These rendering extensions respect the page size precisely during pagination. The PageHeight and PageWidth values defined in the report definition can be overridden by device information settings in the rendering extension. For details, see Use Device Info to Control the Behavior of a Rendering Extension.

Check Reporting Services Log Files

When you experience problems with report execution or need to interpret the performance characteristics of your reports, check the log files described in this section. Reporting Services uses these log files to record information about server operations and status.

Windows Application Log

The report server logs events to the Windows Application log of the local computer. Only information that can be useful for diagnosing a hardware or software problem is logged. The event log is not intended to be used as a tracing tool. The Reporting Services trace logs are used for that purpose. You can use the Windows Event Viewer to view and filter the events based on the event sources, types, and categories. For details on the event sources, types and categories, see Windows Application Log and Reporting Services Errors and Events in SQL Server Books Online.

Reporting Services Trace Logs

Reporting Services records detailed operation information in trace logs.

Trace log file names
Each of the Reporting Services components creates a log file with a unique name. For example, the Report Server Web Service trace logs are named ReportServer_<timestamp>.log, and the trace logs for the Windows Service are namedReportServerService_<timestamp>.log.
Trace levels
The level of detail of the information in trace files that the server logs can be configured by setting DefaultTraceSwitch in the configuration files. For the Report Server Web service, this option is in the Web.config file. The switch for the Report Server Windows service is in ReportingServicesService.config. Four trace levels are available:

1—error (any exception and restarts)
2—warning (for example, warnings related to low resources)
3—info (including informational messages)
4—verbose

By default, the trace level is set to 3.
Error information
When a failure happens in the report server, check the trace log for error details if there is not enough information given in the UI. The trace files should contain the complete stack trace dump, which is helpful to diagnose the problem. One example of this would be subreport errors. When a subreport fails, it does not prevent the main report and other subreports from executing. A message is displayed in place of the subreport contents telling the user that an error occurred while executing the subreport. You may want to view the trace log to find out what the problem was.

The trace logs are located in \Microsoft SQL Server\<SQL Server Instance>\Reporting Services\LogFiles. New log files are created every time a Reporting Services component starts. They are created daily starting with the first entry that occurs after midnight. The logs can become very large, depending on the traffic on the Reporting Services component. Therefore, when looking up file contents, search for the entries with the corresponding timestamp.

Report Server Execution Log

The execution log is a database table that contains report execution information on a report server. It is an internal table residing in the Report Server catalog. The table name is ExecutionLog. Server administrators can use the information in the execution log to analyze report usage and execution performance.

The execution log records data about which reports are executed, when each report starts and ends, how much time is spent on each processing phase, who requested the report, and the export format. Following are fields you may find particularly interesting for performance tuning:

TimeDataRetrieval—Time (in milliseconds) spent executing the query and retrieving data.

TimeProcessing—Time spent processing the report.

TimeRendering—Time spent rendering the report.

Format—Requested rendering format.

ByteCount—Size of rendered report in bytes.

RowCount—Number of rows returned from queries.

The combination of the time spent in the three processing phases (query execution, report processing, and report rendering) determines how long report execution takes. Finding a good balance between what to do in the query and what is processed in the report is very important. These numbers can provide a great starting point for administrators and report authors to monitor and optimize report execution on the server.

To make it easier for users to view the execution log data, a sample SQL Server Integration Services (SSIS) package is shipped as part of the product. This package extracts the information from the execution log table and puts it into a separate database. For details, seeQuerying and Reporting on Report Execution Log Data in SQL Server Books Online.

Use Device Info to Control the Behavior of a Rendering Extension

Device information settings are a set of rendering parameters that are passed to a rendering extension. Through the use of device information, users can override the default settings specified in the report definition and change the behavior of a rendering extension. There are different sets of device information settings for different rendering extensions. For a complete list of settings, see Reporting Services Device Information Settings in SQL Server Books Online. Following are some of the most commonly used device information (DeviceInfo) settings.

HTML

The LinkTarget device information setting specifies the value of the Target attribute used to render hyperlinks in the report. The default behavior is to navigate within the same frame as the original report. You can target a specific frame by setting it to the name of the frame. It can also be set to _blank (opens up a new window), _self (in the current frame), _parent (in the immediate frameset parent) to _top (the top window without frame).

PDF/Image

If an explicit PageHeight or PageWidth is specified in the device information settings, it overrides the value defined in the report definition. Thus, different users can supply different values when they export the same report to PDF or Image files. StartPage and EndPage tell the rendering extensions to render a range of the pages starting from the StartPage to the EndPage.

Office Excel

If you want the report page header rather than the first row of the worksheet to be rendered as an Office Excel page header, set the SimplePageHeader device information setting to true. Since the functionality supported by an Office Excel page header is quite limited, doing this means that you might lose information in your page header.

By default, the Office Excel rendering extension tries to preserve Office Excel formulas whenever possible. Visual Basic .NET formulas are translated to Office Excel formulas. The references to report items on the current page are converted to the appropriate cell references. If you don't want this behavior, set OmitFormulas to true.

XML

The value of the XSLT parameter specifies a relative URL of an XSLT to apply to the report XML. Note that only XSL files that are published on the same report server can be used.

By default, the XML rendering extension uses the original value of the expression evaluation result when rendering a text box. The type of the text box is set to the type of the original value in the XML. You can use the UseFormattedValue device information setting to override this behavior. If it is set to true, the formatted value (which is always a string) is used instead. In this case, the type of the text box will be string.

Multivalue Parameters

Multivalue parameters are very useful to many users. This also seems to be one of the areas that customers need the most help with.

A multivalue parameter is a report parameter that can take a set of values. To define a multivalue parameter, simply add a parameter and mark it as multivalue when creating a report. There are two main scenarios where multivalue parameters are used.

Use a Multivalue Parameter Inside a Report

The properties exposed on a report parameter object include IsMultiValue, Count, Value, and Label. You can access the value and label of a multivalue parameter as zero-based arrays.

=Parameters!<paramName>.IsMultiValue—The parameter defined as multivalue.

=Parameters! <paramName>.Count—Returns the number of values in the array.

=Parameters! <paramName>.Value(0)—Returns the first selected value.

=Parameters! <paramName>.Label(0)—Returns the label for the first selected value.

=Join(Parameters! <paramName>.Value)—Creates a space separated list of values.

=Join(Parameters! <paramName>.Value, ", ")—Creates a comma-separated list of values.

Pass the Value of a Multivalue Parameter to a Subreport

Directly pass the value of a multivalue parameter from the main report to the subreport:

=Parameters!<paramName>.Value

Create a multidimensional object array on-the-fly =Split("a,b,c", ",") and pass it to a multivalue parameter of the subreport.

Pass the first selected value from the main report's parameter:

=Parameters!<paramName>.Value(0)

Using RDL from SQL Server Reporting Services 2005 in SQL Server Reporting Services 2000

When you open a Report Definition Language (RDL) file that was created in SQL Server 2000 Reporting Services in a SQL Server 2005 version of Report Designer, or publish it to a SQL Server 2005 report server, the file is automatically upgraded to SQL Server 2005 format. But is it possible to downgrade a RDL file so that it can be used with the 2000 version of the product again? There is no automated tool to do this, but you can modify the XML file manually to accomplish it.

To modify the RDL file

Change the RDL namespace:

Replace <Report xmlns="http://schemas.microsoft.com/sqlserver/reporting/2005/01/reportdefinition" ... >
With <Report xmlns="http://schemas.microsoft.com/sqlserver/reporting/2003/10/reportdefinition" ... >

Remove the following elements entirely if present in the RDL file:

<InteractiveWidth>21cm</InteractiveWidth>
<InteractiveHeight>29.7cm</InteractiveHeight>

To remove all occurrences of interactive sort in the RDL file, remove all <UserSort> elements, including the inner contents.

Report Samples

Reporting Services supports a variety of report items and built-in functions for report authors to use when designing reports. While creating simple reports has been made quite easy, it can be problematic to find solutions for report display and/or calculations that are not very straightforward. This section covers some of these more complex scenarios to help report developers achieve the functionality they are looking for by using combinations of or alternatives to existing features.

Custom Code for Aggregates

Aggregate of aggregates and aggregate of report items are not currently supported. There have been requests for other aggregate functions that are not currently available. Many times, the desired behavior can be achieved through custom code.

Scenario 1: Median()

Median is a commonly requested aggregate function that is not yet supported in Reporting Services.

To calculate median by using custom code

In Report Designer, open the Report Properties dialog box and click the Code tab. Define an array, a function that takes a value and adds it to the array, and a function that calculates the median value from the array; for example, GetMedian(). Figure 1 shows an example.

Figure 1
Wrap the call to the function in an aggregate and add it to an expression in the detail rows. For example:
=Max(Code.AddValue(Fields!field.Name))
Set the Hidden property of the table column or the text box to true so that it does not show up in the report.
From a text box in the table footer, call into GetMedian() to retrieve the value—in this example, =Code.GetMedian(), as shown in Figure 2.

Figure 2 (Click on the picture for a larger image)

Figure 3 shows what the final report looks like.

Figure 3 (Click on the picture for a larger image)

Scenario 2: Distinct Sum

If a dataset contains values for duplicate records, you don't want to count those values multiple times. Reporting Services supports a CountDistinct function, but there is not a similar function for Sum. You must do this by using custom code.

To calculate distinct sum by using custom code

Open the Report Properties dialog box and click the Code tab. Define a hash table and a function that takes an argument. Inside the function, check the value of the argument against the hash table. If the value does not exist yet, add it to the total and save it in the hash table.

Figure 4
Wrap the call to the function in an aggregate and add it to an expression in the scope where you want to calculate the sum, for example:
=Sum(Code.CalculateSum(Fields!OrderID.Value, Fields!Freight.Value))
In the text box in which you want to display the sum, retrieve the calculated aggregate value:
=Code.CalculateSum(Nothing, Fields!Freight.Value)

Image Value Referring to a Text-Box Value

Direct references to field values in page headers and footers are not currently possible. A common workaround is to add a hidden text-box in the report body, and refer to the text-box value from the page header or footer. Does this work for an image? Yes, but since the image data is a binary array, while the text-box value is a string, you need to use a Microsoft .NET base64 encoding mechanism to convert the data between binary and string types.

To add an image that uses the value of a text box

In the Report Designer, add a text box in the report body. Use the ToBase64String function to encode the binary data to string in the value expression of the text box, for example:
=Convert.ToBase64String(Fields!LargePhoto.Value)
Figure 5 (Click on the picture for a larger image)
In the page header, add an image. Set the source type to database, and the value to:
=Convert.FromBase64String(ReportItems!LargePicture.Value)
This uses FromBase64String to decode the text-box value back into binary.

Figure 6 (Click on the picture for a larger image)

Getting Data from Different Sources

Reporting Services doesn't currently support using multiple datasets in one data region. To display an aggregate value from the dataset, specify the dataset scope in the aggregate function; for example, =Sum(Fields!Freight.Value, "DataSet2"). This syntax works even in a data region that is bound to a different dataset. If, however, you need to correlate the data from the two datasets in one data region, use the following two workarounds:

Modify the query to return data from both datasets as one dataset. If the queries are based on different databases, use SQL OPENROWSET.
Use subreports. Try adding a subreport that receives a parameter from the main report and gets data from another data source based on the parameter value.

To use the subreport approach

Add a table to the main report. Bind it to DataSet1. In the detail row, display the values you want from DataSet1. Add a subreport and in the Subreport Properties dialog box, pass the field from DataSet1 as a parameter.

Figure 7 (Click on the picture for a larger image)
Create a subreport that receives a parameter from the main report. Reference the parameter value in the query to retrieve the records for the corresponding parameter value and display the data rows.

Figure 8 (Click on the picture for a larger image)

Figure 9 shows the rendered main report.

Figure 9 (Click on the picture for a larger image)

Changing the Report Structure at Run Time

A frequently asked question is whether it is possible to change the report structure at run time. You can, of course, dynamically generate RDL files in your custom application. There are also other ways to modify the structural elements in the report definition to achieve this. This section describes various scenarios and solutions.

Dynamic Field Based on Parameter, Dynamic Grouping

How do I decide which field value to use dynamically—for example, based on a parameter in my report? How can I give my users the ability to dynamically select the fields on which to group within a report?

Use this syntax to refer to a field value in your expression:

=Fields(Parameters!<paramName>.Value).Value.

To change the field reference and group expressions based on user input

In Report Designer, open the Report Parameters dialog box. Add a report parameter that represents the field on which you want to group the report data.

Figure 10 (Click on the picture for a larger image)
In the Details Grouping dialog box for the table, set the group expression to the following:
=Fields(Parameters!GroupOrdersBy.Value).Value
Figure 11
Change the text box expression in the report to display the corresponding field value based on the parameter value by using the IIF function; for example:
=IIF(Parameters!GroupOrdersBy.Value="CustomerID", Fields!CompanyName.Value, Fields!FirstName.Value & " " & Fields!LastName.Value)
Figure 12 shows the report when GroupOrdersBy is Customer.

Figure 12 (Click on the picture for a larger image)

Here is how the report looks when GroupOrdersBy is changed to Employee:

Figure 13 (Click on the picture for a larger image)

Changing the Filter Operator at Run Time

It is not possible to change the filter operator at run time, but you can include all the conditions in the filter expression and leave the filter operator and the value as static (filter operator is =, and filter value is =true). This way, by dynamically switching the conditions in the filter expression by using IIF, you can achieve the effect of changing the filters based on user input.

To dynamically change the filter conditions based on parameter value

In Report Designer, open the Report Parameters dialog box. Add a report parameter for the filter operator. If you want the user to be able to control the number to compare against, add a second parameter.

Figure 14 (Click on the picture for a larger image)
Open the Table Properties dialog box and click the Filters tab. Set up the filter on the table (or the dataset or group). The filter expression in this example is:
=IIF(Parameters!FilterOp.Value=">=", Fields!UnitsInStock.Value >= Parameters!Units.Value, Fields!UnitsInStock.Value < Parameters!Units.Value)
Figure 15

Figure 16 shows how the report looks when the value of FilterOp is set to GreatThanOrEqual.

Figure 16 (Click on the picture for a larger image)

And Figure 17 shows when the user changes the parameter value to LessThan:

Figure 17 (Click on the picture for a larger image)

Dynamic Columns

I'd like to programmatically determine the columns to display based on what is returned by the dataset. Is that possible?

Yes, you can define a table with all the possible columns, then decide whether to show each column based on the value of the IsMissing property on Field. Here is an example that shows information from two different database tables based on user selection.

To add dynamic columns to your report

In Report Designer, open the Report Parameters dialog box. Add a report parameter for users to select which table to display.

Figure 18 (Click on the picture for a larger image)
Define a column for every field you want to display from the two tables. For the Hidden property of the column, set the expression to the following:
=IIF(Fields!CompanyName.IsMissing, true, false)
This is shown in Figure 19.

Figure 19 (Click on the picture for a larger image)

Dynamic Rows

My dataset contains a large amount of data. Can I control how many rows are shown initially through a parameter, and toggle the rest?

Yes, set the Hidden property on the rows to:

= RowNumber("DataSet1") > Parameters!RowCount.Value

Set the ToggleItem to a text box that you want to toggle the rest of rows with, as shown in Figure 20.

Figure 20 (Click on the picture for a larger image)

InScope Function

My matrix shows the percentage of the sales to a customer out of the total sales for each employee. In the subtotal cells, this is always going to be 100 percent, which is not useful. How can I get different contents in the subtotal cells?

Use the InScope function in your expression to do this. For example, suppose you have a row grouping (called "matrix1_CustomerID"), and a column grouping (called "matrix1_EmployeeID"). To show different contents in the column subtotal cells, set the cell text-box expression to the following:

=IIF(InScope("matrix1_CustomerID"),
CountRows()/CountRows("matrix1_EmployeeID"), CountRows())

Dynamic Page Breaks

For the logical page breaks defined in the RDL, the only options seem to be turning them on or off. There is no expression for them. Is it possible to dynamically change which groups have page breaks either before or after?

It is possible, although not very straightforward. You create a dummy group with page break at end equal to true. The expression for the group will be set according to a parameter value.

To add dynamic page breaks based on the parameter value

Open the Report Parameters dialog box. Define a report parameter for the user to control the page break.

Figure 21 (Click on the picture for a larger image)
Add a dummy group in your report. Turn off the group header/footer, and enable Page break at end. Set the group expression to the following:
=IIF(Parameters!PageBreak.Value, Fields!CategoryID.Value, 1)
Figure 22 (Click on the picture for a larger image)

Figure 23 shows the report when the page break is turned on.

Figure 23 (Click on the picture for a larger image)

And Figure 24 when it is turned off:

Figure 24 (Click on the picture for a larger image)

Resetting the Page Number on a Group

I have many pages and many groups in my report. I can use Globals!PageNumber to display the current page number in the page header, but I want to reset the page number back to one every time I enter a new group. How do I do this?

Resetting the page number on group breaks is not natively supported, but it can be achieved by tracking group breaks in a shared variable in custom code and subtracting off the page offset of the first page of the group from the current page number.

To reset the page number at the start of each group

Make sure the report has a text box that contains the group expression. In this example, this is the Category text box.

Figure 25 (Click on the picture for a larger image)
Open the Report Properties dialog box and click the Code tab. Add shared variables to track the current group and page offset. Add a custom function to set the shared variables and retrieve the group page number, as shown in Figure 26.

Figure 26
Use the function in the page header:
=Code.GetGroupPageNumber(ReportItems!Category.Value,Globals!PageNumber)
Figure 27 shows one of the pages in the rendered report in which the group page number is reset when starting a new group.

Figure 27 (Click on the picture for a larger image)

Note Because this solution uses static variables, if two people run the report at the exact same moment, there is a slim chance that one will break the other's variable state.

Horizontal Tables

Is it possible to rotate a table in Reporting Services? Usually a table grows vertically, based on the number of detail rows. What if I want it to grow horizontally?

Try using a matrix instead of table. The table header becomes a static matrix row header. The report detail would be the column groupings (you'll need to group on a field that's unique across different rows if you want each data row to show up as a column). Put the footer in the subtotal column (you may need to use the InScope() function to display contents different from the detail information).

Figure 28 shows a vertical table and a horizontal table that display the same set of data.

Figure 28 (Click on the picture for a larger image)

Green Bar

Can I create a table or matrix in which every other row is shaded?

Table

Use =IIF(RowNumber(Nothing) Mod 2, "AliceBlue", "White") to control the background color property conditionally.

Figure 29 (Click on the picture for a larger image)

Matrix

It is more difficult to create a matrix with every other row shaded because every row in the matrix must be a group. There is currently no GroupNumber() function on which to base a green-bar calculation. However, GroupNumber can be (mostly) simulated by using theRunningValue function to return a running distinct count of group expression values.

=IIF(RunningValue(Fields!Country.Value,CountDistinct,Nothing) Mod 2, "AliceBlue", "White")

To create a matrix with the green-bar effect

Add a rectangle to the row group header. In the rectangle, drop the text box for the field you want to display in the header. Add another text box (named Color) to calculate the name of the color based on the following expression:
=IIF(RunningValue(Fields!Country.Value, CountDistinct, Nothing) Mod 2, "AliceBlue", "White")
Set the text box's Hidden property to true.

Figure 30 (Click on the picture for a larger image)
Set the background color of the rectangle and the matrix cell to =ReportItems!Color.Value.

Figure 31 (Click on the picture for a larger image)

Figure 32 shows the rendered matrix.

Figure 32 (Click on the picture for a larger image)

Sunday, 13 December 2015

Report Design Tips and Tricks

Contents