Types of Reports (Report Builder 2.0)
In Report Builder 2.0, you can create a variety of reports. This topic describes the terminology used to describe the various types of reports and the ways in which reports get created and used. A single report can have characteristics from more than one type; for example, snapshot reports can be parameterized, and subreports are linked reports. In all cases, these are standardized on-demand reports that are published to a report server; the reports are just used differently or designed for different uses.
With Report Builder 2.0, you can create the following types of reports:
There are several ways to think about the report type. You might think about it as the way data appears in the report. In Report Builder 2.0, the appearance of data in a report depends on the type of data region you use; for example, table reports and chart reports use different data regions. For more information about how to display data, see Data Regions (Report Builder 2.0). Likewise, the functionality that is available in a report depends on what format you use to export the report; for example, interactive features like drillthrough reports are available in Web-based export formats but not in all image-based export formats like PDF. A report's final output format influences which features you should include in a report. For more information about design considerations for various export formats, see Exporting Reports (Report Builder 2.0).
There is also terminology associated with the stage of processing a report is in. For more information about the differences between reportdefinitions, publishedreports, and renderedreports, see Reports and Report Definitions (Report Builder 2.0). Finally, for information about report scheduling and on-demand reports, see How to: Subscribe to a Report in Report Manager (Report Builder 2.0).
A parameterized report requires your report readers to input values to complete report or data processing. With a parameterized report, the output of a report varies based on values that are set when the report runs. Parameterized reports are frequently used for drillthrough reports, linked reports, and subreports, and connecting and filtering reports with related data.
Parameters are used in dataset queries to select report data, to filter the result set that the query returns, or to set layout properties used to display or hide parts of a report. You can also specify cascading parameters that populate a series of dependent, drop-down parameter lists. For example, choosing a value in a drop-down list of Region parameter values determines the contents of a drop-down list of City parameter values.
You can use parameters with linked reports by pairing a specific parameter with each linked report to change the outcome. For example, you can create a single regional sales report that shows the sales for all regions, and then use a parameter for each linked report to filter data for a particular region. Specific parameter values can be stored with the report so that users do not have to type values.
Not all parameters may be visible in the report at run time. A report author, report server administrator, or content manager can specify which values to use and then hide the input fields on the report.
Query Parameters and Report Parameters
Report Builder 2.0 supports two kinds of parameters: query parameters and report parameters. Query parameters are used during data processing to select or filter data. Query parameters are specified in the syntax of a data processing extension. If a query parameter is specified, a value must be provided either by the user or by default properties to complete the SELECT statement or stored procedure that retrieves data for a report.
Report parameters are used during report processing to show a different aspect of the data. A report parameter is usually used to filter a large set of records, but it can have other uses depending on the queries and expressions used in the report. Report parameters differ from query parameters in that they are defined in a report and processed by the report server, while query parameters are defined as part of the dataset query and processed on the database server. For more information, see Adding Parameters to Your Report (Report Builder 2.0).
A linked report is a report server item that provides an access point to an existing report. Conceptually, it is similar to a program shortcut that you use to run a program or open a file.
A linked report is derived from an existing report and retains the original's report definition. A linked report always inherits report layout and data source properties of the original report. All other properties and settings can be different from those of the original report, including security, parameters, location, subscriptions, and schedules.
You can create a linked report when you want to create additional versions of an existing report. For example, you could use a single regional sales report to create region-specific reports for all of your sales territories.
Although linked reports are typically based on parameterized reports, a parameterized report is not required. You can create linked reports whenever you want to deploy an existing report with different settings. For more information, see How to: Create a Linked Report in Report Manager (Report Builder 2.0).
A report snapshot is a report that contains layout information and query results that were retrieved at a specific point in time. Unlike on-demand reports, which get up-to-date query results when you select the report, report snapshots are processed on a schedule and then saved to a report server. When you select a report snapshot for viewing, the report server retrieves the stored report from the report server database and shows the data and layout that were current for the report at the time the snapshot was created.
Report snapshots are not saved in a particular rendering format. Instead, report snapshots are rendered in a final viewing format (such as HTML) only when a user or an application requests it. Deferred rendering makes a snapshot portable. The report can be rendered in the correct format for the requesting device or Web browser.
Report snapshots serve three purposes:
Report history. By creating a series of report snapshots, you can build a history of a report that shows how data changes over time.
Consistency. Use report snapshots when you want to provide consistent results for multiple users who must work with identical sets of data. With volatile data, an on-demand report can produce different results from one minute to the next. A report snapshot, by contrast, allows you to make valid comparisons against other reports or analytical tools that contain data from the same point in time.
Performance. By scheduling large reports to run during off-peak hours, you can reduce processing impact on the report server during core business hours.
Drillthrough reports are standard reports that are accessed through a hyperlink on a text box in the original report. Drillthrough reports can be filtered by parameters, but they do not have to be. Drillthrough reports differ from subreports in that the report does not display within the original report, but opens separately. They differ from clickthrough reports in that they are not auto-generated from the data source, but are instead custom reports that are saved on the report server. For more information, see Adding Drillthrough Reports (Report Builder 2.0).
A subreport is a report that displays another report inside the body of a main report. Conceptually, a subreport is similar to a frame in a Web page. It is used to embed a report within a report. Any report can be used as a subreport. The report that the subreport displays is stored on a report server, usually in the same folder as the parent report. You can set up the parent report to pass parameters to the subreport. A subreport can be repeated within data regions, using a parameter to filter data in each instance of the subreport. For more information, see Adding Subreports (Report Builder 2.0).