SQL Server 2005 Reporting Services - Pros And Cons
Solution 1:
I know you said 2005, but I will put in notes around 2008 as well.
SRS Pros:
- It is free (provided you have the SQL server license)
- Tight data integration with SQL Server, but it handles anything .NET can (Oracle, ODBC etc...) just fine. (2008 has native support for Terradata too)
- Components for Visual Studio, SharePoint and PerformancePoint all exist to make it easy to leverage it. It is just a web app though so integration into any web page or app that can talk to a web server is easy too.
- Built in tools to do subscriptions (i.e. emails that get sent out on a regular basis to a list of people with the report on them). The list of recipients can be static people or a sharepoint site or a dynamic list of people (pulled from a DB) (08 adds support for dynamic to sharepoint too)
- 3rd party vendors exist to enhance the product
- Export to a variety of formats (XML, CSV, Excel, PDF etc...)
- Ability to design templates which power users can use to build reports without knowing SQL (since the SQL is contained in the template). Power users use a special report builder tool which is delivered via click once.
- Works differently to Crystal reports (I don't like Crystal thats why this is a pro for me)
SRS Cons:
- Charting controls look like Excel 2003 and are limited. (2008 has the Dundas controls in by default so they are much more powerful, more varied and better looking)
- Kerberos issues due to it being a web app can cause annoying problems (2008 removes that as it is no longer an IIS web app. It runs it's own web server based off the IIS core but is closer to a stand alone app - so the security issues aren't a problem)
- Designer support is a pain. 2000 Reports must be developed in VS 2003, 2005 reports must be developed in VS 2005, 2008 reports must be developed in VS 2008. By Visual Studio I mean the normal one or the thin downed version you get with the SQL Management tools.
- Compatibility. Each version of reporting services can run only the current version and one version back of the reports.
- Security is limited to Integrated Windows or Anonymous (2008 has added support for forms based security and for custom providers, like you get with ASP.NET)
Solution 2:
One of the Cons I see with your setup, is you will have to use Visual Studio 2005 for your reporting project since you are using SSRS 2005.
Since it looks like you are using Visual Studio 2008 for your other development, this means having both versions installed and having to have both open and running most the time.
I'm in the same situation and it is a hassle, but one I've gotten used to.
EDIT:
Some of the other Cons I've run across are usually designer related. They may have been fixed in 2008 (don't know for sure), but I attribute them to the infancy of SSRS compared to other more mature reporting solutions.
Datasets changing to Text even though you set them to Stored Procedure every time you enter the data tab
Web Service datasets losing their parameters when changing the query
The expression editor is very dumbed-down. Its slightly better than using notepad.
Solution 3:
The CONS:
Rendering might be different in Firefox or other browsers. When using SSRS ReportViewer on an ASP.NET page, just make sure to verify the look/feel/layout of the report when rendered on browsers other than IE.
One con is that with SSRS, there are so many options available to the developer that it could be confusing at first. I am talking more about whether to use Local Reports or Server Reports, whether to put code inside code modules, in reusable assemblies, or use reusable Managed Code (C#) Stored Procedures.
The biggest con I could think of in SSRS is that the code module is very basic. No intellisense and no debugging features. Also it would be great if SSRS scripting supported C# instead of just VB.NET.
While expressions are great, the problem is there is no single container/place which allows you to see all the expressions defined in a report. This could present a maintenance nightmare down the road.
That said, SSRS is a powerful tool in the hands of a seasoned developer.
Solution 4:
Pros:
- Free
- Probably better tied to MS SQL than most others
- Works well for most types of reporting
Cons:
- Free; Support access isn't like Crystal
- Doesn't have every feature other, older competitors have. Being a newer piece of software, it is still getting new functionality that other products like Crystal Reports has had for years.
I often end up running reports in whatever way they're easiest. Lately I built my own web based interface that drives any combination of PDF/HTML/Crystal/SRSS reports and delivers them. Often Crystal will do some in 2 steps, or SRSS does something else better. If I had to pick one right now as a go-to for all scenarios I'd probably pick Crystal. The more I use SRSS being a few years old and still in active feature development (catching up to products like Crystal), I can see it being used a lot more... not quite yet though.
Solution 5:
I find SSRS is very Robust and provides a very large range of capabilities to suit your reporting needs. I have tried others (Crystal) and did not like it nearly as much. (This could just be personal taste though).
Even for a beginner, SSRS has many wizards which will get you the results you desire and for the experienced developer, you can fine tune your reports with drill-throughs, colors, coding, etc.
I honestly have nothing bad to say about SSRS. The one downside that Dustin pointed out is that your VS version and SQL version are different. I have an app that is in VS2005, but uses a SQL 2000 backend and I have to have my reports separate in a VS2003 project to get them to work properly.
Post a Comment for "SQL Server 2005 Reporting Services - Pros And Cons"