Is MS Reporting Services suitable for stand-alone reports?

Question

Hello all:

I work for a ISV. Our product can use both SQL Server and Oracle as its back-end server. It includes a number of reports (currently in Crystal).

We are investigating moving to Micrsoft Reporting Services, but I'm beginning to think that it's a bad idea.

We want for our reports to look and feel as though they are a part of our application, and we will not require SQL Server (the customer can choose Oracle).

Although I see the reporting services supports a stand-alone mode (RDLC), the boundry between what requires SQL server and what doesn't looks extremely ambiguous. (example, the stand-alone report builder appears to require SQL Server, most of the documentation appears to be part of SQL Server's documentation)

It looks to me like if I want to keep my application DB-agnostic, I had better steer clear of Reporting Services. Have I missed the boat here?

Answer 1

In my experience with stand-alone reports, I basically just bound the report to a strongly-typed DataSet. I did this with data from SQL Server, but I imagine there wouldn't be any issue with using Oracle. All you have to do is get the data into the DataSet.

Answer 2

SSRS for local report templates is doable by setting the LocalReport property on the ReportViewer component but requires distributing the rdlc files to the client. These report templates can be filled via code and datasets.

Granting access to report templates from a centralized repository will require the ServerReport property on the ReportViewer component to be set. This will require Microsoft SQL Server 2005 version of SSRS or later.

Answer 3

The ReportViewer control will work with an Oracle datasource.

If you include a ReportViewer control in your application, the .rdlc files that the control uses can have any data source (e.g. a collection of objects or a DataTable) that your application uses.: http://msdn.microsoft.com/en-us/library/ms252094.aspx

If you just use the ReportViewer control in "local processing mode" you can consider SQL Reporting Services a similar but separate product: http://msdn.microsoft.com/en-us/library/ms251671.aspx If you aren't already, I'd search under "ReportViewer control" rather than "SQL Server Reporting Services".

Your customers would only require SQL Server if they wanted to host a reporting server separate from your product.

Answer 4

Thank you for all of the help on this one, guys. I ended up concluding "no" -- at least not in our case. After researching the issue, here's what I found:

(btw: we want for end users to be able to design reports and then plug them into our product)

1. There are at least 4 designers for reports (Business Intelligence Analyzer, the built-in Visual Studio designer, Report Builder 2.0, Report Builder 3.0 (in CTP).

Each of these designers offers a different mix of features, and some of the features do not overlap. (example, you can't use custom assemblies in ReportBuilder,but you can in Visual Studio).

Most of the support available on the internet targets RDL (sql server) reports, and not RDLC, very little support for RDLC, and sometimes you find yourself wandering "across the fence" to RDL land, and sometimes the feature support is not the same (custom data extensions, for example).

Overall, we decided that we were better off sticking with Crystal. It's just my opinion, but it looks to me like this: Strictly speaking, Reporting Services can run stand-alone, but it's really not marketed/built/designed with that in mind. It seems as though You are really expected to be using it in conjunction with SQL Server -- especially if you want to have advanced users (and not programmers) designing reports.