Was this page helpful?
Your feedback about this content is important. Let us know what you think.
Additional feedback?
1500 characters remaining
Introducing Data Processing Extensions

Introducing Data Processing Extensions

SQL Server 2000

Data processing extensions in Reporting Services enable Reporting Services to connect to a data source and retrieve data; they also serve as a bridge between a data source and a dataset. Reporting Services data processing extensions are modeled after a subset of the .NET data provider interfaces.

The following table lists the data processing extensions included with Reporting Services.

Data processing extension Description
Data processing extension for SQL Server Uses the SQL Server .NET data provider to connect to and retrieve data from the SQL Server database engine.
Data processing extension for OLE DB Uses the OLE DB .NET data provider. With this extension, the report server can query any data source that has an OLE DB provider.
Data processing extension for Oracle Uses the Oracle .NET data provider. With this extension, the report server can access Oracle data sources through Oracle client connectivity software.
Data processing extension for ODBC Uses an ODBC driver. With this extension, the report server can access data in any database for which there is an ODBC driver.

You can use the Reporting Services data processing API to add custom data processing to your report server.

Note  Reporting Services has built-in support for data providers in the .NET Framework. If you have already implemented a full .NET data provider, you do not need to implement a Reporting Services data processing extension. However, you should consider extending your .NET data provider to include Reporting Services-specific functionality, which includes secure connection credentials and server-side aggregates.

Each of the data processing extensions included with Reporting Services uses a common set of interfaces. This ensures that each extension implements comparable functionality.

You can develop data processing extensions for your own data sources, or you can use the interfaces to add an additional layer of data processing to common database infrastructures. You can deploy your custom data processing extensions to enable seamless integration of data into the existing report servers in your organization. You can also use them as part of a custom reporting suite that you provide to your consumers.

Reporting Services data processing extension architecture

The advantages to implementing a custom Reporting Services data processing extension include:

  • A simplified data access architecture, often with better maintainability and improved performance.
  • The ability to directly expose extension-specific functionality to consumers.
  • A specific interface for your consumers to access your data source within Reporting Services.

Data Extension Process Flow

Before developing your custom data extension, you should understand how the report server uses data extensions to process data. You should also understand the constructors and methods that are called by the report server.

The step-by-step process flow of a data extension that is called by the report server

The illustration shows the following sequence of events:

  1. The report server creates a connection object and passes in the connection string and credentials associated with the report.
  2. The command text of the report is used to create a command object. In the process, the data processing extension may include code that parses the command text and creates any parameters for the command.
  3. Once the command object and any parameters are processed, a data reader is generated that returns a result set and enables the report server to associate the report data with the report layout.
See Also

Extending Reporting Services

Getting Started with a Data Processing Extension Implementation

Reporting Services Extension Library

© 2015 Microsoft