Configuring ReportViewer for Remote Processing

  • Article

ReportViewer controls can be configured to use the processing capability of a Microsoft SQL Server 2005 Reporting Services report server. The report server processes the data and renders the report into an output format. The ReportViewer control retrieves the finished report from the report server and displays it on the screen.

To use a server report, you must have access to a SQL Server 2005 Reporting Services report server and the report you select must be published on the report server. The ReportViewer controls require information that is only exposed through the SQL Server 2005 SOAP execution endpoint. The controls do not support reports that run on a SQL Server 2000 Reporting Services report server.

You can verify that you have access to a report by opening a browser window and typing the report server URL and report path in the URL address. When you configure a connection to the report server, connect using an account that has permission to view the report. By default, this is the thread user. In a Windows application, the thread user is typically a user account. In an ASP.NET application, it is typically the ASP.NET account. Regardless of how you configure the connection, you must ensure that there is a role assignment on the report server that grants report access to the account used to make the connection. To learn more about connection configuration, see IReportServerCredentials.

How to Configure ReportViewer for Remote Processing

To configure a ReportViewer control for remote processing, specify a server report to use with the control. Follow these steps to select a server report:

  1. Add the ReportViewer control from the Data section of the Toolbox to the form or Web page in your project.

  2. In the ReportViewer Tasks smart tags panel, in Choose Report, select Server Report.

  3. In the Report Server text box, type the report server URL. The default URL syntax is https://localhost/reportserver. The actual URL that is used in your installation might be different depending on how the report server virtual directory settings are configured.

  4. In the Report Path text box, type the fully qualified path of a published report. The report path must start with a forward slash ( / ). The path must not include report URL parameters. The path consists of folders in the report server folder namespace and the name of the report. For example, if you installed the SQL Server 2005 sample report Company Sales on your report server, the report path might be /AdventureWorks Sample Reports/Company Sales.

  5. Build or deploy the application to verify that the report appears correctly in your application. If you receive HTTP proxy errors, verify that the report server URL is correct. If you receive a compatibility error, confirm that the report server is a SQL Server 2005 instance.

  6. Select the ReportViewer control and open the Properties window.

  7. Set properties on the ReportViewer control to configure the report toolbar and run-time functionality. Use the reference documentation to learn about each property. For more information, see ReportViewer Properties.

Understanding Server Report Characteristics

There are important visual and functional differences between server reports and reports that are processed locally. The following table describes the characteristics of server reports that are processed remotely:

Report processing

Server reports run on a SQL Server 2005 Reporting Services report server. Server reports are published from report definition (.rdl) files created in the SQL Server 2005 version of Report Designer. The composition of a .rdl file varies slightly from the composition of a .rdlc file that you might create in an ASP.NET or Windows application project. You can easily adjust report definition files to run on a report server or in the controls. For more information about .rdl and .rdlc differences, see Converting RDL and RDLC Files.

Data processing

Server reports use the data processing extensions of a report server to connect to and process a result set. Default data processing extensions are provided for SQL Server, Analysis Services, SQL Server Integration Services, Oracle, SAP NetWeaver® Business Intelligence, XML, ODBC, and OLE DB data sources. You can create or use custom data processing extensions to support additional types of data.

In contrast with client reports, server reports include data source connection information and one or more queries in the report definition. For server reports, data processing and report processing are integrated. As a result, a server report might include report parameters that map to query parameters, or expressions that incorporate query results at run time.

Parameterization

A server report can include a parameter input area at the top of the report so that users can type or select parameter values to use in the query. In a client report definition, you must provide a parameter input area in the form or Web page.

Connecting to external servers

Data sources used by server reports typically retrieve data from external data sources on other servers. When running a server report in your application, make sure that you understand how the report server connects to and retrieves data from external data sources for the report. If the report uses Windows integrated security, there are limits on how many times a user security token can be passed to other computers. Users who access the report through your application might encounter connection errors if multiple connections must be made using the same token. If the report is configured to prompt for credentials or if the report server uses forms-based authentication, users might have to type a user name and password to view the report. Note that the ReportViewer control does not provide pages for prompted credentials. If your application connects to a report server that uses forms-based authentication, your application must provide the logon page.

Managing reports

Server reports are managed on a report server. A report server administrator can modify the role assignments that provide access to a report, reconfigure the data source connections, and update, move, rename, or delete the report. Any of these changes can affect or prevent the report from running in your application. When you use a server report in your application, make sure that you understand how it will be managed after the application is deployed.

For more information about report design, data retrieval, deployment, and security settings for SQL Server Reporting Services, see SQL Server 2005 Books Online. SQL Server 2005 Books Online can be installed through the SQL Server 2005 installation media. You can also find it on www.microsoft.com.

When to Use Remote Processing

Server-based reporting lets you centralize report storage and management, set policies and secure access to reports and folders, control how reports are processed and distributed, and standardize how reports are used in your business. Reporting Services can be installed in single-server, distributed, and clustered configurations. Consider using remote processing if your report has the following characteristics:

  • Report will be accessed by many users.

  • Report has a very complex query or contains a very large amount of data, resulting in system resource overload on the computer that hosts the application.

  • Report is already published on a report server, and you want to include it an application that you create and deploy.

See Also

Concepts

Converting RDL and RDLC Files
Adding and Configuring the ReportViewer Controls
Configuring ReportViewer for Local Processing
Deploying Reports and ReportViewer Controls