Breaking Changes in SQL Server 2005 Reporting Services

This topic describes changes to Reporting Services functionality that will break custom applications, scripts, or reports.

No support for drillthough actions or bookmark links in a header or footer

In SQL Server 2005 and SQL Server 2005 Service Pack 1, Reporting Services does not support drillthough actions or bookmark links in a header or footer. This is a breaking change for reports that you created in SQL Server 2000 Reporting Services.

In Service Pack 2, this issue is partially resolved. Drillthrough actions in the page header and footer are supported for reports that run on-demand, but not for reports that run as a snapshot. Snapshots that contain drillthrough or bookmark links in the header or footer must be recreated to obtain the drillthrough functionality:

1. Start Report Manager or Management Studio.
2. Locate the report and open the Execution properties page for that report.
3. Select the Create a snapshot of the report when this page is saved check box.
4. Click Apply.
5. Repeat these steps for all reports that run as a snapshot and that have drillthrough or bookmark links in the header or footer.

Report Server WMI Provider from SQL Server 2000 is not supported

Reporting Services includes a Windows Management Instrumentation (WMI) provider that you can use to programmatically configure the environment in which a report server runs. The SQL Server 2005 release of Reporting Services includes an all-new version of the WMI provider that completely replaces the earlier version. The original version from SQL Server 2000 is not supported in this release of SQL Server.

New authentication restrictions for data processing extensions

This release of Reporting Services includes new restrictions on how credentials are handled for some data processing extensions:

• You cannot configure an Analysis Services data source connection to use database credentials. The connection will fail if you are using the ADOMD wrapper.
• You cannot configure an XML data source connection to use database credentials. If you specify no credentials and the unattended execution account is not defined, the request is made through Anonymous access.
• Third-party .NET data processing extensions (for example, DB2.NET, Oracle ODP.NET, and Teradata) explicitly fail data processing if database credentials are passed on the connection string and the unattended execution account is not configured.
• Custom data processing extensions that implement IDBConnection (but not IDBConnectionExtension) explicitly fail data processing in every case unless the unattended execution account is configured.
• Whenever connection requests are made by the service account (that is, the security context of the service account is used for the network connection to the data source), Reporting Services removes administrator privileges from the service account before it sends the request.

To configure the unattended execution account, use the Reporting Services Configuration tool or rsconfig utility. For more information, see Specifying Connections for Custom Data Processing Extensions and Configuring an Account for Unattended Report Processing.

Expressions that contain a reference to the object result in report compilation errors

Reports that use expressions to set the Action property on an item will no longer compile if the expression includes a Me.Value reference. Upgrading reports that include Me.Value in Action property expressions will result in compiler errors that resemble "The Value expression for the textbox ‘textbox1’ contains an error: [BC30456] 'Value' is not a member of 'ReportExprHostImpl.textbox1_TextBoxExprHost.DataValue1_DataValueExprHost'. (rsCompilerErrorInExpression)."

To avoid these errors and upgrade your reports, you must rewrite Action expressions, replacing Me.Value with the actual value expression. The following example illustrates how to replace Me.Value in a textbox-style expression with an actual value expression: =iif(Fields!Name.Value = 0, "Solid", "None").

Support for multivalued parameters might break single-valued parameters in reports

Multivalued parameter support is a new feature that is introduced in this release. If you are using the old SOAP endpoint and your code gets or sets multivalued parameters, you will now get multivalued parameters back. In the previous release, if you specified multiple parameters, only the first parameter was returned. Be aware that after you upgrade, additional parameters might be returned for parameters that you thought were single-valued. Make sure that you review existing calls to the Render method to determine whether single or multivalued parameters are used. You should also test all reports that have parameters to verify that single-valued parameters work as expected.

Updating parameters through SetReportParameters

In the previous release, if you wanted to update a parameter property, you had to re-specify all its settings. If the report included query-based or expression-based parameters, updating a single parameter property usually meant you had to republish the report. Failure to republish the report resulted in reports that were missing query-based default values after a parameter property was changed.

In this release, you can update a specific property on a parameter without having to reset all its properties. The default values are no longer set to null if the DefaultValues property is unspecified. Be aware that this change might break application code or scripts that use the old SOAP endpoint if the code or script is handling the Null reference.

Adding the Select All member for multivalue parameters

In a SQL Server 2005 Reporting Services report, a Select All check box was automatically added when you created an available values list for a multivalue report parameter. Checking the Select All check box selected all available values. Clearing the Select All check box cleared all available values. If you upgraded to SQL Server 2005 Service Pack 1 (SP1), the Select All check box was no longer available. In SQL Server 2005 Service Pack 2 (SP2), the Select All check box has been restored. When you upgrade your report authoring client to SP2, the Select All check box is automatically added to the drop-down list of available values in report preview in Report Designer. After you upgrade your report server to SP2, you can use the report server tools (Report Manager, Report Builder, and SQL Server Management Studio) to view all existing and new reports that use the Select All functionality. You do not have to republish existing reports to restore the Select All functionality. If you upgrade your tools and you do not see the Select All check box, you are probably connected to an SP1 report server.

Referencing extended properties from the Microsoft SQL Server Analysis Services data processing extension

In a SQL Server 2005 Reporting Services report, if you needed to refer to the extended Key property for a field from an Analysis Services data source, you needed to use the custom field syntax Fields!FieldName("MEMBER_KEY"). After you upgrade to SQL Server 2005 Service Pack 1 (SP1), this syntax no longer returns the Key value. This workaround is no longer needed or supported. Instead, you must change references to the extended field syntax for the Key property to Fields!FieldName.Key or Fields!FieldName("Key").

Change History

See Also

Concepts

Upgrading Reporting Services

Other Resources

Upgrading SQL Server Components
Reporting Services Backward Compatibility
Backward Compatibility

Help and Information

Getting SQL Server 2005 Assistance