My first glimpse of SSRS

I have just completed a four-day SQL Server Reporting Services (SSRS) training course and wanted to collect my thoughts in a posting. Although I have been tinkering with SSIS and SSAS for a little over a year now, this is my first look at Reporting Services. In general, I enjoy the simplicity with which it can be administered, but am still hesitant about its report development tool(s).

Simply, SSRS is a repository for reports and reporting elements (data sources).  In SSRS, reports are developed using either the Business Intelligence Development Studio (BIDS) or the web-based Report Builder. Reports get deployed to the report server as XML and stored in the Report Catalog, a SQL Server table. Users access reports In Report Manager via a web browser.

What I like:

• SSRS comes free with MS SQL Server, so it is a cheap reporting solution if you are already using a SQL Server backend.  Remember, a separate license is required for every server running any component(s) of MS SQL Server.
• Additionally, the report development tool are downloadable for free.
• Administration seemed easy.  Cache settings are particularly easy to manage and are set at the individual report level.
• Reports are organized in a folder structure, which people tend to easily understand especially when you match folders to business functions or systems.  More importantly, security is applied at the folder level.  Remember, though, that these are not really saved in a file structure anywhere.  The definitions are really being stored in a database.
• Table based report-scheduling.
• Cascading prompts are built within the report.  No additional tools are needed to build or schedule cascading prompts.
• Integration with .NET.  The entire SSRS object model is accessible for custom programming.  People out there are designing their own report writers.
• Integration with Source Safe.  Although I did not see it in class, our teacher ensured us that reports can be version-controlled using Source Safe.
• SSRS easily integrates with SharePoint.  However, this needs to be coordinated with your SharePoint installation if you want SharePoint to serve as the main access point to your reports.  Otherwise, there are webparts in SharePoint that can display an SSRS object if a coordinated implementation is not possible or is too late.

What I do not like:

• I gave a queasy look a lot, while the teacher was showing us the report development tool.  Nothing extreme sticks out, I just know you will not find it nearly as user-friendly as Crystal Reports.  The teacher 100% agreed.
• Security administration is managed in two places: SQL Server Management Studio and Report Manager.
• The undefined report header/footer is not natural to me.
• Cascading prompts are always called on-demand and they are not reusable across multiple reports.
• Instances are only kept for snapshots, which seems like an administrator task to me.

If it were up to me, my next steps would be to get into a .NET class so I get into customizing with Microsoft’s free API.  Who knows, maybe develop a new report writing tool in my spare time!