Lately, IĄŻve been working on generating reports for a few projects. This post is an initial impression/comparison of my experiences with Crystal Reports and MS SQL 2000 Reporting Services.
First, I began using Crystal Reports, the free reporting package included with Visual Studio .Net. Before I started using it, I had heard that it was an unpleasant piece of software to use. This is sort of a general overview of the process that I went through:
I created an xml schema to define the fields that I would retrieve from the db. After the schema was complete, I got into starting to generate the report template using the Crystal Reports GUI designer integrated into VS.Net. The first annoyance popped up; the registration dialog that bugs the *** out of you. The designer was fairly straightforward and I have little issues with that. You can right-click on the report and select Ą±view source,Ą± to see the generated c# code representing the report template. After the initial template was created, I created a class to generate a dataset based on user input. The class calls a stored procedure which then returns fields in the same format as those specified in my xml schema. The dataset is then created with these fields and used as the data source for the report. At this point, I built an .aspx page with a CrystalReportViewer object. After binding the dataset to the report object and the report object to the viewer object, you finally can view the report from a browser. To me, this seems like a hell of a lot of work for generating reports.
Next, I got into a project that didnĄŻt have a reporting solution. For this project, I chose to use MS SQL Reporting Services to generate the reports. SQL Reporting Services integrates nicely with Visual Studio .Net and best of all... no annoying registration dialog! One of the differences in VS.Net that initially threw me off was that I had to create a separate project to house Reporting Services reports. This is different than Crystal Reports, which just lets you add a report (.rpt) to any project in the solution. The point behind having a separate Reporting type project is mainly for deployment issues (I think) and it is a nice way to keep the reports organized. The two main parts of the report project are shared data sources and reports. As the name implies, you can setup one or many data sources to be shared between reports. Generating reports seems to have a little learning curve, but overall is a pretty easy procedure. There are wizards to drive you through the initial process, if that is your thing. Once again, the GUI editor for reports is friendly and done pretty well, but it contains some very cool features that Crystal Reports does not. First, it uses tabbed views to switch between modifying the data source, layout, and dun dun dah.... preview. The layout view is where you are able to modify the look and feel of the report. You can then view the expected result (using real data from the data store) by clicking the preview tab. Right-clicking on the report and selecting Ą°view source,Ą± presents the underlying xml used to represent the report. My initial thought is that itĄŻll be really nice and easy to generate my own XML representation, if the need arises. Now, rather than having to generate a separate .aspx page to view the report results, you can deploy the report to the reporting server. The reporting server is basically a server that has the reporting services web service installed. Reporting services uses this web service as their front end to reports too. So, you can just go to the web service and navigate to your report, to view it. If you need to specify parameters to limit the query, the web service will auto generate a framed webpage to do this for you. This is all well and good, but exposing the reports via a web service also allows you to build your own front end, if desired. Now there are many other cool features that IĄŻm finding with SQL Reporting Services (drill down and access to any .Net class within the expression syntax, to name a few) and IĄŻll try to write about those in other posts.
For both solutions, the documentation is pretty minimal. I have to give the edge to MS SQL Reporting Services, since they do have a section on MSDN devoted to reporting services. Also, Reporting Services provides a sample solution with multiple reports, showing what is possible. Even though the reports are different, the performance seemed to be pretty much the same for both reports. IĄŻm not saying that I benchmarked the report performance, but visually I didnĄŻt notice that one reporting package was faster than the other. Also, both reporting packages allow for reports to be exported to a variety of formats (Excel, PDF, Word, etc..) which is nice.
All in all, I will choose to go with MS Reporting Services for any future reporting needs...