Having supported all versions from SQL Server 2000 Reporting Services to SQL Server 2012 Reporting Services, and preparing to support Windows Azure SQL Reporting thought it would be a nice time to look at how it has changed over this time.

SQL Server 2000 Reporting Services

SQL Server 2000 Reporting Services is where it all started. It even had a separate setup than being included as part of the SQL Server setup, like the versions after that.

As mentioned in the SQL Server™ 2000 Reporting Services Deployment Guide "The computer hosting the report server database must be running SQL Server 2000 SP3a...If you rename or move the databases after setup, you must run the Rsconfig.exe utility to update the connection information". That small blurb about Rsconfig.exe does not give it enough merit as it was used like the Reporting Services Configuration Manager is used today. But yes, RSconfig.exe did Not have a GUI! Rsactivate.exe is a command line utility that was used to initialize a single report server instance and multiple report server instances that were part of a single Web farm. Again, no GUI!

And thus started our charge into enterprise reporting and business intelligence.

SQL Server 2005 Reporting Services

SQL Server 2005 Reporting Services was a more integral part of SQL Server, now that it was included as part of the SQL Server setup itself. Changes from SQL Server 2000 Reporting Services were in many aspects, with main among them being
- no drillthough actions or bookmark links in a header or footer
- new restrictions on how credentials are handled for some data processing extensions
- expressions to set the Action property on an item will no longer compile if the expression includes a Me.Value reference
+ Multivalued parameter support is a new feature that is introduced in this release
+ update a specific property on a parameter without having to reset all its properties
+ a Select All check box was automatically added when you created an available values list for a multivalue report parameter
+ Due to changes in how initialization and configuration are performed, rsActivate.exe is now obsolete and no longer provides this functionality

SQL Server 2005 Reporting Services was much improved over SQL Server 2000 Reporting Services in these aspects - 
+ introduces the new Reporting Services Configuration tool used to deploy and administer a Reporting Services installation. (Yay, a GUI for configuration! :)
+ new print functionality, end-user sorting, multivalued parameters, and report navigation and viewing through Microsoft SharePoint Web parts
+ to new tools, Report Builder and Model Designer, have been added in this release to support model-based drag-and-drop reporting
+ introduces new report viewer controls that are included in Microsoft Visual Studio 2005

IIS Requirement

Designed with a web application, web service and windows service, till SQL Server 2005 Reporting Services, IIS was a requirement so as to expose the out-of-the-box reporting site to end users. That requirement continues to this date, even on Windows Server 2008 servers. Of course, that requirement lead to its attendant issues and a conundrum in administration - do web admins manage Reporting Services or is it the database administrator? Either way, there was a lot of learning for all involved.

SQL Server 2008 Reporting Services

Big changes in architecture were implemented in SQL Server 2008 Reporting Services and these were some of the main ones -

+ Introduces the new report server architecture that includes native support for functionality previously provided by Internet Information Services (IIS). 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.

Of course, this made setting Anonymous access on the Reporting Services sites much more difficult than a single click in IIS manager. That way, reporting sites were now, hopefully, more secure and accessible to valid users only. By taking IIS manager out of the equation, it also gave SQL DBAs a chance to continue managing Reporting Services without learning too much IIS. Is that a DBA I hear grumbling? :)

+ This release supports new on-demand report processing that enables the processing of large reports.
On-demand processing is a processing enhancement that renders each page of a report as you view it. This enhancement improves the way report processing handles large amounts of report data at run time.

This addressed one of the main issues with large reports on lower versions of Reporting Services.

It also helped show the first page of the report faster, rather than waiting for the whole report to get rendered before showing the first page of the report as was being done earlier.

+ Introduces tablix, chart, and gauge data regions. It also introduces support for richly formatted text, new data source types, and Report Builder 2.0, which offers many new features, like enhanced data layout and visualization, in an Office-like authoring environment

Visually, reports were more sleek and eye catching, and could certainly be used for scenarios other than printing address forms and invoices, which also worked fine.  Such paginated reports which also included grouping elements together on a page, repetitions etc. did need rework to keep them rolling.

One of the items discontinued was to do with the configuration manager -

- Because the auto-upgrade feature has been added, there is no longer any need for you to create a database upgrade script or for having a manual upgrade option in the Reporting Services Configuration tool. In SQL Server 2008 Reporting Services (SSRS), the button to create the script and the button that performs the upgrade action are removed from the Database Setup page in the Reporting Services Configuration tool.

With such major changes, behavior changes were to be expected.