Practical ASP.NET

Crystal Reports vs. SQL Server Reporting Services

If you're trying to decide whether to use Crystal Reports or SQL Server Reporting Services with ASP.NET, you can rest assured that there is no bad choice.

• By Peter Vogel
• 12/14/2010

I sometimes get asked to compare Crystal Reports with SQL Server Reporting Services. I tell people it's like choosing between Visual Basic and C#: It's a lifestyle choice. From my point of view, with the latest versions of the two tools, they are both equally capable. While the two tools do things in different ways, I don't know of anything that I can do in one that I can't do in another. Things that are easy in one tool are marginally more difficult in the other but they're really not all that different.

Since this is an ASP.NET column rather than a reporting column, I'll demonstrate that claim with examples of the typical things you would do when integrating reports into an ASP.NET page.

For instance: To display a Crystal Report, you add a CrystalReportSource and a CrystalReportViewer to the page. If you're using a client-side Crystal Report (represented by an .rpc file) you bind the CrystalReportSource to the report and the CrystalReportViewer to the CrystalReportSource.

With SQL Server Reporting Services (SSRS) you just drag a ReportViewer onto your page and bind it to the .rdlc file that represents an SSRS report. There is an equivalent to the CrystalReportSource in SSRS but it's an ordinary ObjectDataSource and it's generated automatically when you add the ReportViewer to the page.

There are several different ways that you can provide data for a report -- for these examples I'll assume that I've loaded data into a dataset (a great strategy, by the way, because it provides an easy way to cache data and reduce trips to the database server). With SSRS if you referenced the DataSet when you built the report, no additional code is required to get the data out of the DataSet and into the report.

With Crystal Reports getting the data out of the DataSet and into the report requires a little more work. You must pass the DataSet to the SetDataSource method of the ReportDocument available from the CrystalReportSource control. That's only a single line of code and it looks like this:

Me.CrystalReportSource1.ReportDocument.SetDataSource(ds)

One more example: If you're dropping data into a DataSet and caching it, then you're probably retrieving more data than you need for any particular report. So, for any report you'll be filtering your data as part of passing it to the report. In Crystal Reports that's easy: you don't have to do anything at design time and, at run time, you just have to set the CrystalReportViewer's SelectionFormula property to something that looks very much like a SQL Where clause. This example, for instance, limits the data to those rows where the Region field of the CustomerOrders table is set to BC:

Me.CrystalReportViewer1.SelectionFormula = 
                           "{CustomerOrders.Region} = 'BC'"

With SSRS to filter data, you have to set up a parameter at design time in your report. To use the parameter you have to create an array of ReportParameter objects and pass the array to the SetParameter method of the ReportViewer. Again, it's not a lot of code: These three lines of code limit the report to rows where the Region field is set to BC for an SSRS report:

Dim rps(0) As Microsoft.Reporting.WebForms.ReportParameter
rps(0) = New Microsoft.Reporting.WebForms. _
                           ReportParameter("Region", "BC") 
Me.ReportViewer1.LocalReport.SetParameters(rps)

Throughout these two tools you'll see the same kind of differences. While both tools support the same range of features, a "no code" solution in one tool requires code in the other; some features require no design-time effort in one tool but require design-time set up in the other. It really is a lifestyle choice. Or, to put it another way, "What you gain on the ferris wheel, you lose on the merry-go-round."