In local mode, the ReportViewer morphs itself into a mini-Report Server. In this configuration, the ReportViewer control handles the report processing and rendering, not the Report Server. In fact, if you plan to use local mode only, you don't need Reporting Services at all (neither at design nor at runtime). That's because the ReportViewer controls don't have any dependencies to the Report Server. Local mode offers the following advantages:
- Easy report distribution. You can package the report definitions with your application and distribute them without requiring your customers to have the Report Server installed.
- Flexible data binding scenarios. The application can bind the local report to an ADO.NET dataset or a business object. As with RS 2000, binding datasets to server reports is not supported and may require a custom data extension.
Before you get too excited about not needing the Report Server (and a SQL Server 2005 license), take some time to compare and evaluate remote and local modes. You shouldn't view the ReportViewer local mode as a replacement for Report Server; its features are limited to report processing and rendering only, which means no report catalog, no caching, no subscribed delivery, no security, etc. In addition, it limits export formats to PDF and Excel only. Therefore, the Report Server and the Report Viewer are not competing products, they're complementary technologies. The Report Server gives you a server-based reporting platform; the Report Viewer makes it easy to distribute your reports with custom applications.
In the absence of Report Server, the ReportViewer must obtain its data from your application. In local mode, your application is responsible for providing the necessary input to the report. That's why the ReportViewer doesn't display the parameter prompt area with local reports. Parameters and data are external to ReportViewer.
Authoring a local report consists of three steps:
- Configure the report data source
- Design the report layout
- Request the local report programmatically
I'll explain each of these steps in more detail below.
Configuring the Report Data Source
|Author's Note: To differentiate remote from local reports, the RS team introduced a RDLC file extension where "C" stands for client-side processing—a logical difference only. You describe both server (RDL) and client-side reports (RDLC) in the same XML schema-Report Definition Language. The RDLC definitions are more flexible because the Report Server doesn't validate them. For example, some values, such as dataset queries, may be missing. This means that in most cases, you can use the server-side report definition as a client-side report with no additional steps (see the Converting RDL and RDLC topic in the VS.NET documentation for more information). The Report Viewer doesn't require a local report definition to have an RDLC extension. That said, I will stick to the Microsoft naming convention and use RDLC for local files.
If you have a server report that you need to convert to a local report, you can skip this step. That's because your report definition already describes the dataset(s) that will feed the report. The only thing left is to bind the local report to an application dataset with an identical schema at runtime. If you create a local report from scratch, there are two ways to create a data source in Visual Studio.NETinside the local report itself or as an external dataset.
Selecting a Report Data Source
To try this option, create a new local report (right-click on the project node in the Solution Explorer and choose Add-->New Item-->Report. Next, click on the Add New Data Source button inside the Data Source window. This starts the Data Source Configuration Wizard which allows you to create a data source from a database (table, view, or stored procedure), Web service, or an application object. However, as it stands, the Data Source Configuration Wizard does not support free-form SQL queries.
A second (and recommended) way is to add a new dataset to the project. For example, here is how you can create an identical dataset definition to the one used by the Customer Orders server-side report.
- Copy the SQL SELECT statement that loads the dsOrders dataset in the Customer Orders.rdl report.
- Right-click on the WinReporter project and choose Add-->New Item-->Dataset. Name the dataset CustomerOrders.xsd.
- Right-click on the Dataset Designer canvas and choose Add-->TableAdapter. This launches the TableAdapter Configuration Wizard (the same wizard available in ASP.NET), which supports SELECT queries.
|Figure 5. Configuring the Dataset Schema: The figure shows the process of selecting a report data source.|
- Create a connection to the AdventureWorks database or create a new one if it doesn't already exist. Save the connection string in the application configuration file as AdventureWorksConnectionString.
- In the "Choose a Command Type" step, leave the "Use SQL Statements" options selected.
- In the "Enter a SQL Statement" step, paste the SQL SELECT statement you copied in step 1.
- In the "Choose Methods to Generate" step, accept the defaults and finish the wizard.
- Rename DataTable1 to CustomerOrders.
The end result of running the TableAdapter Configuration Wizard is a typed dataset (CustomerOrders.xsd
), as shown in Figure 5
. With either approach, all typed datasets defined in the project are made available to the report, so you can proceed to authoring the report from these datasets.