Alternative to Report Viewer for SQL Reporting Services

10
votes

We're looking to develop an upgrade to our existing ASP.NET application in MVC3. Our current app is IE only based and the upgrade will be browser neutral, i.e. it must work in IE8+, firefox, chrome and safari.

The main issue we have is that we have a number of reports based on SQL Reporting Services 2008 R2 and we use the Report Viewer 2010 control.

We don't really want to use this going forward because:

  • It's buggy (for example, we can't use the SP1 version as renders HTML sometimes that breaks our site)
  • It's got issues with non IE browsers (e.g. the IterationId missing on URL bug)
  • It's based on Viewstate
  • It's hard to localise some of the rendered output of the control

I'd really like to replace it with an alternative (even if its viewstate based and we have to hack in a solution with MVC) but I've not been able to find one. Is there an alternative control out there that renders Reporting Services reports? It's the viewer we want to replace, not RS.

3
sql-serverreporting-servicesreportviewer
To update my own comment for others So far, haven't found one for MVC, but been looking into the Web services engine for RS. This might be an option. – GrahamB
I'm busy trying to run away from the Report Viewer as well. I've managed to get most of the required functionality using the WCF Service. The only problem I've faced though is handling linked reports. Please share your experiences as it is one of the most important aspects of integrating SSRS to web applications. – ntombela
I haven't tried it, but once you track down the API for linked reports it seems straight forward: msdn.microsoft.com/en-us/library/ms152864.aspx – Robert Paulsen

3 Answers

2
votes

We wanted to integrate SSRS with out existing website but didn't want to use the SSRS UI (since it's very much it's own website) and we didn't want to uses the Report View Controls (although we have an ASP.NET Website, the report viewer controls have limited options for making it do what you want). The solution that worked for us was:

  1. Call the SSRS Web Service to return a list of Reports, and drop the values into a Drop Down List.

  2. Read the report path from the Drop Down List and get the SSRS Web Service that returns the parameters of the selected report.

  3. Build input controls based on what came back in #2.

  4. Users supply the input values and submit the form.

  5. The page passes the values to the SSRS Web Service and gets back a PDF, Excel, Word document based on what the user requested.

This wasn't all that hard (it took < 40-hours to code & test) and works really well. The biggest issue we have is supporting different versions of the SSRS Web Service as you move from one version of SSRS to another.

I'm guessing if you wanted to output the reports as HTML and pump that to the UI, you could do that too.

Obviously if you want to all users to edit report properties, create subscriptions, etc -- you'll have additional work to do.

0
votes

I agree with you. It is really a buggy control. I played with my DOCTYPE settings to tweak my html output.

If you can try commercial ones,have a look into Telerik control.

Also look at this discussion:

http://siddhumehta.blogspot.com/2011/07/ssrs-reportviewer-webpart-control.html

0
votes

You may be able to just view the HTML version and set the controls to be bound by the service in a REST URI instead. EG:

http:// (servername)/(ReportServer)/(PathtoReport)&(Parameter=Value)&rs:Command=Render

I have never tried anything beyond hosting this in a 'Form' html object but I would wonder if you could get away just using a default html browser object and just forcing the REST URI to have conditions.

You may also if you really want to dive into VB.NET or C#.NET in your ASP.NET code. Maybe you can just render the byte array of Reporting Services to a type of PDF or HTML, then present that in a viewer as well. This may not be a viable solution as I am not sure of your level of wants to then try to present a binary object in a proprietary format versus just a web portion of an existing call. This may be more work and would be more tailored to a rendering of just that type you choose of PDF, Excel, HTML, etc. But it can be done. I basically made a library project with the logic to do the calls after making a proxy class out of the SSRS Service. More on that here: Programmatically Export SSRS report from sharepoint using ReportService2010.asmx