Breaking Changes in SQL Server Reporting Services

SQL Server 2008 Books Online (October 2009)

This topic describes breaking changes in Reporting Services. These changes might break applications, scripts, or functionalities that are based on earlier versions of SQL Server. You might encounter these issues when you upgrade, or in custom scripts or reports. For more information, see Using Upgrade Advisor to Prepare for Upgrades.

Report Server Breaking Changes

Report Builder Breaking Changes

Report Processing Breaking Changes

Report Rendering Breaking Changes

For more information about new features, see What's New (Reporting Services).

Report Server Breaking Changes

This section describes breaking changes to the report server and management tools.

Feature	Description
IIS and ASP.NET	Reporting Services no longer depends on IIS to provide access to the SOAP endpoint. URLs no longer include Web sites in IIS. Reporting Services uses HTTP.SYS directly to listen for requests on a specific port that you define for report server URLs. This enhancement is a breaking change for some deployments: If you have scripts, tools, or diagnostic processes that include reviewing IIS metadata or properties, you must now develop new approaches for managing a report server deployment. If you implemented an ISAPI filter for security, you must move the ISAPI filter to be hosted in ISA server or create a new HTTP Module that does the same operations in Reporting Services. If you use custom virtual directory settings, you might not be able to configure equivalent settings or URLs in the new report server implementation. In some cases, upgrade operations cannot create equivalent URLs for the report server or Report Manager. Upgrade Advisor will detect breaking changes by checking for ISAPI filters and customized virtual directories. Upgrade Advisor cannot check for all possible customizations. Your installation might pass the Upgrade Advisor check but still break or produce unexpected errors.
Port conflicts on Windows XP	On supported editions of 32-bit Windows XP SP2, IIS 5.1 and Reporting Services cannot use the same port. You cannot configure both IIS 5.1 and a report server to listen on the default HTTP port (port 80). IIS 5.1 does not use HTTP.SYS for Web applications hosted on the Web server. This means there is no common queue management for requests that come over the same port, and there is no common repository of registered and reserved URLs. This issue results in the following behavior for SQL Server 2008 Reporting Services upgrades on Windows XP: On 32-bit editions of Windows XP, if you upgrade an existing SQL Server 2005 Reporting Services installation to SQL Server 2008 Reporting Services, the report server is configured to listen on port 8080. On 64-bit editions of Windows XP, if you upgrade an existing SQL Server 2005 Reporting Services installation to SQL Server 2008 Reporting Services, the report server is configured to listen on port 80. If you perform a SQL Server 2008 build-to-build upgrade, the report server continues to listen on the same port that was configured prior to the upgrade. After upgrade completes, you can use the Reporting Services Configuration tool to change the port on which the report server listens if you want to use a different port. For more information about supported Windows operating systems for SQL Server 2008, see Hardware and Software Requirements for Installing SQL Server 2008. Note: IIS 5.0 is no longer supported. Windows 2000 servers are not supported in SQL Server 2008.
Reporting Services Windows Management Instrumentation (WMI) Provider	The Reporting Services Windows Management Instrumentation (WMI) Provider is not compatible with the previous version. The new version includes additional methods to support URL registration. Because there can only be one version of the Reporting Services WMI provider for a report server installation, this version replaces the previous version. This change represents a breaking change for some deployments. If you created script or tools that call the WMI provider, you must revise your code to use the new version. For more information, see Reporting Services WMI Provider. This change also prevents users from connecting to a SQL Server 2005 instance in SQL Server Management Studio when the user specifies the <server_name>\<instance_name> format to connect. Instead, users must type the report server URL to connect.
Consolidation of services and applications	The Report Server Web service, Report Manager, and the background processing application are consolidated into a single service. You cannot start or stop them separately.
Reporting Services configuration files	Reporting Services configuration files are also consolidated. The RSReportServer.config file is the primary configuration file for Report Manager and the Report Server Web service. The RSWebApplication.config file is obsolete. The following RSWebApplication.config settings have been moved to the RSReportServer.config file: ReportServerUrl ReportServerExternalUrl ReportBuilderTrustLevel DeliveryUI settings for delivery extensions DisplayErrorLink The following settings are obsolete and are no longer used: ReportServerVirtualDirectory MaxActiveReqForOneUser If you modified the RSWebApplication.config file in a previous installation, the file will not be deleted when you upgrade to SQL Server 2008. You should delete the file manually; all settings within the file are ignored in this release.
Reporting Services trace logs	ReportServerService_<timestamp>.log is the primary trace log for all applications that run in the service. The following files are obsolete and are no longer created in SQL Server 2008: ReportServerWebApp_<timestamp>.log, ReportServer_<timestamp>.log, and ReportServerService_main_<timestamp>.log.
Reporting Services Configuration tool	Reporting Services Configuration tool no longer supports the Upgrade Database or Grant Rights features that allowed you to upgrade or grant permissions as independent operations or generate script templates for performing these tasks. In this release, both upgrading and database permissions are handled as internal operations.
SQL Server Management Studio	In Management Studio, the Home folder is removed in this release. You cannot view, manage, distribute or secure report server content in Management Studio.
Report Manager	In Report Manager, the following links are removed from Site Settings: Configure item-level role definitions, Configure system-level role definitions, Manage jobs. Report Manager no longer supports the ability to create, modify, or delete role definitions. You must use Management Studio to manage which tasks are in specific roles. Similarly, job management has moved from Report Manager to Management Studio.
E-mail subscriptions	E-mail subscriptions will not work for e-mail aliases in the Sender, To, Cc, Bcc, and Reply-To fields when the report server or the remote SMTP server is upgraded to Windows Vista or Windows Server 2008. This issue occurs because Windows Server 2003 contains a feature that resolves aliases to their full e-mail addresses. Reporting Services depended on that feature to allow for using e-mail aliases instead of full e-mail addresses. However, to help filter out false e-mail addresses, Windows Vista and Windows Server 2008 do not contain this feature. To work around this issue, you must configure the DefaultHostName property in configuration. For information about resolving this issue, see the Microsoft Knowledge Base article 945601: "SQL Server 2005 Reporting Services e-mail subscriptions do not work in Windows Vista and in Windows Server 2008 if you use aliases as e-mail addresses."
SQL Server 2008 Reporting Services Add-in for SharePoint Technologies	The SQL Server 2008 Reporting Services Add-in for SharePoint Technologies provides report rendering, processing, management capabilities, and data-driven subscriptions when you run a SQL Server 2008 report server instance in SharePoint Integrated mode. The add-in download contains a Report Viewer Web part, Web application pages, and support for using either Windows SharePoint Services (WSS) or Microsoft Office SharePoint Services (MOSS). The SQL Server 2008 Reporting Services Add-in for SharePoint Technologies requires a SQL Server 2008 report server instance because this add-in is not supported with earlier versions of SQL Server. If you have a pre-SQL Server 2008 report server, and you install or upgrade to the SQL Server 2008 Reporting Services Add-in for SharePoint Technologies, the report server will not function as expected. For example, you will be unable to configure database access by using the Grant Database Access page and render reports using a SharePoint product or technology. To resolve this issue, you must either upgrade your report server instance to SQL Server 2008, or you must uninstall the SQL Server 2008 Reporting Services Add-in for SharePoint Technologies and re-install the SQL Server 2005 Reporting Services Add-in for SharePoint Technologies. For more information about the SQL Server 2008 Reporting Services Add-in for SharePoint Technologies, see the Microsoft SQL Server 2008 Reporting Services Add-in Readme.
Basic authentication	In SQL Server 2008 Reporting Services, only NETWORK and NETWORK_CLEARTEXT logon types are supported with Basic authentication; Interactive and BATCH logon types are not supported.

Report Builder Breaking Changes

This section describes breaking changes to Report Builder.

Report Builder Runs in Full Trust Mode Only

In earlier versions of Reporting Services running in native mode, SQL Server 2005 Report Builder could be started using the following URLS:

Full trust For example, http://<servername>/reportserver/reportbuilder/reportbuilder.application
Partial trust For example, http://<servername>/reportserver/reportbuilder/reportbuilderlocalintranet.application

For both URLs, <servername> is the name of the computer that specifies the report server. For both URLs, reportserver is the name of the report server instance.

In this release, you must use the full trust URL to run Report Builder. When you use the full trust URL for the first time, you might be prompted to grant a higher level of permissions for the application.

Note:
If Report Builder does not run, or if you get an error, contact the system administrator. You might not have the permissions that you need to grant a higher level of trust for this application.

After you grant these permissions the first time, you do not have to set them again.

In this release, if you use the partial trust URL, the following error appears when you open or save a report, or switch report servers:

"Failed. An error occurred while processing your request. Save your report and restart the application."

Report Processing Breaking Changes

Report processing architecture is fundamentally changed in this release by providing on-demand report processing. On-demand report processing significantly reduces memory usage on a report server.

RDL Upgrade Breaking Changes

The following RDL elements are not supported when you upgrade an existing report:

Object Identifiers in RDL limited to 256 characters
Identifiers for objects in RDL (for example, textboxID) were previously unrestricted in length. In this release, the length of object identifiers is restricted to 256 characters. Identifiers still must be CLS-compliant.

Interactivity Information Saved Only For the Last Request

In earlier versions of Reporting Services, snapshots saved all possible combinations of interactive choices, such as drillthrough information and toggle choices. You could view page five of a report, but programmatically toggle an item on page one by keeping track of the correct ID for the toggle.

In SQL Server 2008, interactivity information is generated and saved only for the last rendering request. You cannot view a page and programmatically toggle an item on another page. You can only toggle drill down items on the current report page.

Report Object Model Namespace Change

In this release, the Report Object Model namespace has changed. This namespace provides read-only access from custom code to global collections like Fields, Parameters, and ReportItems. If existing custom code explicitly uses a fully qualified reference to an earlier namespace, this change is a breaking change.

It is recommended that you do not use fully qualified references to access built-in collections from your code. By not explicitly specifying the namespace, custom code references resolve to the version of the report object model for the currently installed version of Reporting Services.

For example, in SQL Server 2005 Reporting Services, the following two examples contrast the use of a fully qualified reference to a parameter (Microsoft.ReportingServices.ReportProcessing.ReportObjectModel.Parameter) and a default reference to a parameter (Parameter) for passing a report parameter to a custom function that returns the report parameter label.

The following example is not recommended. It shows the fully qualified reference for a report parameter. The second example is recommended and shows the default namespace reference for a report parameter.

DO NOT USE FULLY QUALIFIED NAMESPACE REFERENCES FOR RUN-TIME COLLECTIONS

Public Function ShowParams(ByVal reportparameter As _

Microsoft.ReportingServices.ReportProcessing.ReportObjectModel.Parameter) _

As String

Return reportparameter.Label

End Function

The recommended way to access a run-time collection is shown in the following example:

Public Function ShowParams(ByVal reportparameter As Parameter) _

As String

Return reportparameter.Label

End Function

Report Rendering Breaking Changes

Report rendering architecture is fundamentally changed in this release to provide more consistent rendering for paging and layout among different renderers.

New Rendering Object Model and Consistent Pagination

The Rendering Object Model (ROM) has changed for SQL Server 2008. Earlier versions of the rendering object model are no longer supported. Accessing the Rendering Object Model from a multi-threaded rendering extension (and switching context from multiple threads) is not supported.

The new ROM makes the rules for rendering pages more consistent. For more information, see Understanding Pagination in Reporting Services.

Redesigned CSV Data Renderer

In earlier versions of Reporting Services, when you exported a report to a CSV file format, the data was formatted in a way that preserved the way the data appeared on the report page. For matrix data regions, this resulted in a data format that was inconvenient to import into other applications in order to continue to work with the data.

In this release, when you export a report to a CSV file, you can choose between two supported formats: Default mode and Compliant mode. Default mode is optimized for Excel. Compliant mode is optimized for third-party applications. For more information, see Exporting to a CSV File.

The earlier format for CSV files is no longer available. However, for reports that do not use matrix data regions, you can use Compliant mode to get a file format closest to the earlier CSV file format.

Aggregates with Conditional Visibility in Page Headers and Footers

In earlier versions of Reporting Services, different renderers used different rules to determine which items with conditional visibility to include on a report page. For example, aggregate calculations were not performed for hidden items in printed reports, but were calculated for hidden items in reports that you viewed with a browser or in Excel.

In this release, all renderers use the same set of rules to determine which items are on a page.

No Formula Support in Excel

In earlier versions of Reporting Services, there was limited support for translating expressions in RDL to Microsoft Excel formulas. In this release, when you export a report to Excel, RDL expressions are not translated to Excel formulas.

Overlapping Items

In earlier versions of Reporting Services, if a report had overlapping items on the report design surface, publishing the report produced a warning ("Overlapping report items are not supported in all renderers."), but the report items remained in their original location on the design surface. In SQL Server 2008, report items may be moved to correct overlapping boundaries when a report is viewed or exported to a renderer based that does not support overlapping items. For more information, see Understanding Rendering Behaviors.