Printed reports were the norm for decades. When a user wanted to get some important information, they would use their software to print a report and then read it from the page. Today online reports are used to give user access to important information without the need to put ink or toner on paper.
Aside from saving the forests, one of the many advantages of using a report displayed on the screen is that user can interact with reports to get as little or as much information as they need.
Reports with multi-level groups and drill-down actions
Multi-level grouped reports are one of the most fundamental report designs. A natural extension of this style of report has each subgroup collapsed with the ability to click a toggle item to expand or collapse each group to view detail at a lower level.
Using Reporting Services, this is a straight-forward design pattern but it?s not well documented for the novice report designer.
There are also a number of options and decision points when designing multi-level drill-down reports:
- Multi-level Grouped Report with Subtotals
- Drill-down Report on a Single Dataset
- Drill-down Report with Dynamic Details
- Embedded Drill-through Targets
I spend a good deal of time answering questions and moderating the Microsoft Developer Network (MSDN) forum for Reporting Services. New SSRS users tend to use different terms inconsistently to describe report design elements and concepts. For example ?I wan to click a drill-down link to open a subreport in a new window to view the details for the item I clicked on.? Although this probably makes sense to the user who wrote it, it may not make sense to those familiar with standard Reporting Services concepts. Before we can discuss these design concepts, it?s important that we?re on the same page, using the same words a phrases to describe the same concepts. Our discussion in this article is limited to designing reports using a table data region.
A table data region can have one or more row groups. A group may be created by dragging a field into the Row Groups list in the lower-left area of the report designer while the table is selected. A group may optionally have numeric subtotals in the group header (above the details) or the group footer (below the details.) Each group has one or more group field expressions. A tables with two nested groups might have sales records grouped first by the Year and then subgrouped by the Month.
This example uses a table data region with grouped rows. The drill-down functionality in the next section will work just as well with a matrix style reports with column groups.
The levels or details within a group may be hidden from view until the user clicks on a drill-down icon next to a toggle item. Using the prior example, the aggregated sales for each Year are visible until the user clicks the [+] before a specific year value. This expands details for that year and shows a row for each Month. Likewise, each month shows a [+] which can be used to expand the details for that month and to show individual detail rows. The year is expanded to show related months and then the month is expanded to show sales details for each product category.
Beyond the basic drill-down report design, where a multi-level grouped table has group header rows which may be expanded and collapsed using a toggle item, certain details could also be hidden and shown using a toggle item as well. For example, a product name could be displayed in the detail row with a toggle item used to show a description or order details.
The name of a report item existing in a row at a level above the current group. In typical reports, a toggle item is a textbox in the header of a parent group used to expand (show all) or collapse (or hide) a set of rows. By default a plus or minus icon is displayed to the left of the toggle item to indicate the expanded or collapsed state. When a user clicks this icon, the plus icon [+] is used to expand the level and the minus icon [-] is used to collapse and hide details in the lower-level group for that parent value.
A type of report action that navigates from a specific report item to a different report. Optionally, one or more field values in the context of the current row are passed to parameters in the target report to filter records related to the row or item in the source report. By default, the target report is displayed in the same browser or viewer window as the source report. Optionally, the drill-through target report can be displayed in a secondary window. In HTML report rendering, drill-through is implemented using a hyperlink and anchor tag to navigate to the target report. A drill-through report may be implemented using a Report action or a URL action; using an expression to specify the server path, folder name, report name, parameters and optional query string commands.
The report containing one or more report items having a Report or URL action. A user navigates from a source report to a drill-through target report.
The report that a user navigates to in a drill-through Report or URL action. Any report on the report server may be used as a drill-through target using a relative folder path. When using Business Intelligence Development Studio to design a Report action for a textbox or other report item, all reports in the same project (which are deployed to the same folder) are listed as available target reports.
In Figure 3, a target source report contains a table data region. The textbox for the Year field has a drillthrough action that opens a drillthorugh target report. The corresponding Year field value is passed to a parameter on the target report that filters data in the query for the specified year. In this example, product category sales for 2004.
A subreport is a report embedded inside another report. Subreports can simply be independent reports or master/detail reports that show detail records related to a group header or master record. Independent subreports are often used to display standardized header and footer information, such as legal statements and disclaimers. To filter and correlate master/detail records, the subreport should be designed with parameters used to filter records in each instance of the subreport related to the master record in the parent report. The parent report in the report designer which shows a dark gray placeholder labeled with the path and name of the child subreport.
The second instance of the subreport is called-out, which displays subcategory sales details related to the Bikes category.
One of the advantages of using a subreport to display master/detail records is that each report is based on a separate data source and dataset query. As such, this technique may be used to federate and correlate related data from two different data sources. Even the database platforms and query languages can be different. Conversely, one of the disadvantages of this technique is that by opening multiple data connections and running separate queries, report processing may be slower and less-efficient. However, if the data truly resides in different locations and in different database platforms, this may be the best method to bring it into a single view. Subreports are also one of the more challenging report elements to render or export into different formats with the same fidelity as a single table or matrix.