Tony Davis : The SSRS 2008 Minefield

Home SQL .NET SysAdmin Opinion Blogs Forums Books

Simple-Talk Editor

News, views and good brews

The SSRS 2008 Minefield

Published Friday, October 16, 2009 1:11 PM

One of the big advances in Microsoft's "2008 platform", with regard to Reporting Services, was that there would be a single, consistent Report Definition Language (RDL) across all the products. This means that reports developed in Report Builder can be shared with reports developed in BIDS, and vice-versa. While one can immediately appreciate the advantages of this, it's disappointing that it seems, on this occasion, to have been at the expense of compatibility efforts.

If you've developed reports in Visual Studio 2008 and expect to be able to deploy them to SSRS 2005, then think again. You can't. They will only work with SSRS 2008. This one is perhaps more understandable, given the extent of the changes to RDL, although it has inconvenienced more than a few developers.

Conversely, however, if you are a customer who has made the technical investment in SSRS 2008, you have every right to look forward using your Visual Studio ReportViewer controls across both VS 2008 and SSRS 2008. Well, think again (again), because you can't. While Microsoft made big efforts to improve the number and quality of the report controls available in SSRS 2008, the VS ReportViewer 2008 control is not one of them. It still based on the 2005 version of RDL and so won't work with SSRS 2008.

One can appreciate the extreme difficulties in coordinating releases, and dealing with dependencies across all the different products and versions, but it's still hard to understand why Microsoft has not rectified this issue. About four years ago many people discovered the joy of being able to deliver reports to SQL Express clients, allowing them to move away from disparate reporting solutions based on Crystal Reports, MySQL and so on. In many cases, this ultimately led to a purchase of a full SQL Server 2005 license. However, it also means that there are now thousands of reporting clients that are dependent on the VS ReportViewer control, and so are "blocking" any potential upgrade to SQL Server 2008!

The lack of clear communication on this issue is even more difficult to accept. Back in August 2008, Bill Vaughan printed a retraction to his earlier assertion that SSRS 2008 and the ReportViewer control would work together, suggesting that the problem would be resolved in around 6 months. It has still not happened. Since then, there has been very little news.

Indeed, if you read http://msdn.microsoft.com/en-us/library/ms345248.aspx perhaps you could be forgiven for being led to believe that SSRS 2008 and the VS ReportViewer control play nicely together and so pressing forward with the SSRS 2008 upgrade. Having migrated and tested potentially hundreds of reports and overcome numerous architectural changes and challenges, many will find it extremely disappointing that the anticipated reward to their reporting clients remains elusively out of reach.

As always, you'd love to hear your experiences with this issue!

Cheers,

Tony.

by Tony Davis

Comments

	lyndon said: I wish i'd read this two weeks ago, when I built a new report in VS 2008 and then discovered it wouldn't deploy to SSRS 2005. I even tried removing the xml tags that were being flagged as errors in the rdl, until it became clear that there wouldn't be much left. Luckily it wasn't massively complex, but it still wasted 90 minutes or so... October 20, 2009 3:42 AM
	TATWORTH said: Has this problem been formally reported to Microsoft at https://connect.microsoft.com/dashboard/?wa=wsignin1.0 ? If not, please make a formal bug report there. Please publish the URL so that all affected by it can vote on its seriousness October 20, 2009 4:07 AM
	paschott said: I don't think we've been hit by this one, but we were hit by a couple of issues with SSRS that either surprised us or caused us a lot of trouble. The first major one was when MS released a service pack that changed the way Excel files were rendered when working with Macs. If there was a hyphen in the report file name, it wouldn't open properly. Took them at least 6 months to fix it after we'd opened a case (with them insisting that it wasn't broken and we could work around it by renaming all 5k of our reports to remove hyphens). Then, after it was fixed, we weren't told about it. We called in to ask about the status and they told us the fix had been released a while back. (To their credit, it did work.) The one that surprised me was that SSRS 2005 could not work correctly with SQL 2008 data servers as their data source. We tried all sorts of things, got a couple of them working, but ultimately had to upgrade our reporting services servers to 2008 in order to get them to connect. Happily, we have not been hit by the issue outlined here. We have some changes that we need to make to our reports to keep them all running and there's been a learning curve to replace older functionality with the newer conventions, but SSRS has generally worked well for us. Now if they'd just come up with a SaaS-friendly Report Builder program, we'd be in much better shape. :) (I agree with Tatworth, this needs to be opened at Connect if it's not already and then posted and re-posted so people will vote it up. Hopefully it will get some response other than "Closed - won't fix.") October 20, 2009 11:09 AM
	randyvol said: I think you've just hit the tip of the "iceberg of lamention" w/r/t SSRS2008. Not only is there the compatibility issue you discussed, but the tablix object - one of the primary 'features' that would make one want to move foward is rife with gotchas, as anyone who has tried to make use of the grouping features will tell you. Microsoft's sole readout on that one is "yep, its a problem"; one wonders why no patch has been issued to fix it though. Bottom Line - SSRS 2008 looks like it was 'mandated' as ready for release by the executives. You know what I mean by this - this happens when a large product such as SQL Server has many components that need to be lined up for a release. As the time for release draws near, the lining up isn't happening based on readiness, QA, etc. and so the executives, who have already reported their revenue projections for the next fiscal period, based in large part on the projected take rate of the new product just decide that the laggards are 'ready for release' anyway and mandate they get into the product in some minimalist form or fashion. As I look at what is being touted as SQL Server 2008 R2, and I look at all the other production releases in the pipe, I begin to worry the MSFT is in the mode of making releases based on revenue desires over the quality and usefulness of the products. I guess they want to move the market back to the tried and true rule of "don't buy anything from MSFT until release 3" mode of purchasing. If they keep up, it certainly looks like that will happen. For instance, I saw an article recently that states that the feature in Windows 7 that most corporate accounts have requested more information on is 'XP compatibility mode'. This should tell MSFT something, but looking at their roadmap, I don't think the message is getting through. At any rate, SSRS is most definitely in the 'embarassed and red-faced' category of the SQL Server 2008 release. That said, the way we have decided to 'fix' our reports is to move the SSRS2k5 reports to our SSRS2k8 report site. This will consolidate our reports onto the lateste report engine, where, hopefully, the breakages will be less in number than if we were to try and take SSRS2k8 reports the other direction. randyv October 20, 2009 2:52 PM
	meklembl2 said: It's just plain silly, but we've seen silly (or maybe stupid) before. We were burnt by this and the workaround was to build the reports on both platforms, separately. But as the database administrator, I do see the wasted effort and need to upgrade the existing SQL2005 to SQL2008. I will say that as I read about the differences in the RDL files, that I took for granted that Report Viewer would only process 2008, so when I tested the 2005 SSRS files and it worked I was excited (it's the little things in life). So I pointed towards a 2008 SSRS and nothing. Come on MS. Not only should you give us a tool to migrate basic RDL between 2005 and 2008, but your viewer tool should work on either. October 20, 2009 2:52 PM
	Rahul Desai's Blog » Editorial: The SSRS 2008 Minefield said: PingBack from http://nationalcom.com/wordpress/?p=258 October 20, 2009 4:42 PM
	Geoff Schaller said: The difficulties arise with good intentions. When SQL Server 2005 Reporting Services was introduced and the VS control shipped, it was fantastic. Perhaps the most outstanding feature was the ability to deliver reports (the same reports) to clients who did not have or want a full blown report server on their laptop or PC. It also meant corporate clients could take the database home or on the road with them and also still run the server based reports. The viewer control was fantastic and the flexibility it offered convinced many of our clients to abandon other solutions and go with ours, based on Reporting Services. Developing an rdlc though, which required the application to run to view the report and its various editing stages, was a pain. It was slow and inefficient. So we didn't. We developed the reports as rdl and could therefor do design time review and testing. Then it was a simple matter to rename the file and upload it into position for use by the report viewer control. Terrific! This was real progress. So along comes SQL Server 2008 and a new version of Reporting Services and Report Builder 2.0 - and a new problem. No report viewer control with the 2008 schema. What this effectively meant was that any thought of upgrading to the new server and all those wonderful new reporting features was dead in the water because the report viewer side of our applications would cease to function. This means retaining SQL Server 2005, VS and SSMS, all so that we can continue to use the 2005 schema. This is really disappointing. Lost revenue for MS, lost revenue for us and no new features and efficiencies for the client. Lose lose all round. What is saddest is the lack of even the slightest recognition from Microsoft that this is even an issue. We were taken down this path originally by MS and were thrilled that it worked so well but now we are locked out of SQL Server 2008 until this simple thing is resolved. October 21, 2009 12:58 AM
	Incompatabilities with 2005.RDL and 2008.RDL « CGoldwater’s Blog said: PingBack from http://cgoldwater.wordpress.com/2009/10/21/incompatabilities-with-2005-rdl-and-2008-rdl/ October 21, 2009 6:07 PM
	JamieClayton said: We did a big fixed price reporting solution based on SSRS 2005 and got burnt by the features and limitations. We lost $50k on the project and still have to repair the 50 reports when we get a non buggy solution from Microsoft. We do have 500+ users running reports via the Report viewer and they are happy for the time being. I do see the SSRS solution approach to be a much better architecture than may of the other commercial reporting tools, so we are persisting with this technology for the time being. If the SSRS R2 changes don't rectify these issues, then we might drop Microsoft as a reporting vendor, because I'm not seeing enough support for this technology from Microsoft. I often don't get newsgroup responses for questions about the product, so I'm not sure the product managers are getting feedback from the user community. I have submitted numerous errors to MS Connect (with very detailed software examples) and I'm getting resolved messages for VS2010 editions of the control SSRS Viewer control. One can only hope that we are not far away from 2010 and a hopefully an early year release of that product so we can move forward and get our reports and users happy with SSRS. October 21, 2009 6:54 PM
	Sean Fowler said: Given that you can call the SSRS web service and get the report HTML it should be fairly simple to use this in a WinForm browser control. This is probably all the old report wiewer control was doing. Due to various issues with displaying reports over the web (SSL and load-balancing causing their own issues) we couldn't use the ASP.NET report viewer control. Instead we get the HTML from the web service and display it on our website by setting the InnerHtml of a div. We had to do some work-arounds for images as they normally come from the database server and we obviously didn't want to expose that to the internet, but other than that it worked fine. The image work-arounds are hacky but they work. November 2, 2009 8:20 AM
	aaron_kempf said: Hey I'd really like to know where you get off- -spreading misinformation like this ' It still based on the 2005 version of RDL and so won't work with SSRS 2008. '. I've been using SQL 2008 SSRS against the Report Viewer without any trouble whatsoever.. So plz.. let me know what you're doing wrong.. and then plz apologize to the public for being incorrect. SQL 2008 RDL works great against ReportViewer. Are you using Local Mode? I use Remote mode without any problems, of course, I'm a certified DBA so I know what I'm doing. Thanks -Aaron November 24, 2009 2:49 PM
	aaron_kempf said: I think that you guys are having authentication problems possibly? ReportViewer1.ServerReport.ReportServerUrl = new Uri(AppConstants.DefaultReportServerUrl); ReportViewer1.ServerReport.ReportPath = AppConstants.DefaultReportPathBase + rdlName; ReportViewer1.ServerReport.ReportServerCredentials = new CustomReportCredentials(AppConstants.ReportServerCredentialsUsername, AppConstants.ReportServerCredentialsPassword, AppConstants.ReportServerCredentialsDomain); November 24, 2009 2:52 PM
	aaron_kempf said: ReportParameter[] parameters = new ReportParameter[strReportParams.Length]; for (int i=0; i<strReportParams.Length; i++) { if (strReportParams[i].Trim() != String.Empty) parameters[i] = new ReportParameter(strReportParams[i].Trim(), (String)Session[strReportParams[i]]); } ReportViewer1.ServerReport.SetParameters(parameters); November 24, 2009 2:53 PM

You need to sign in to comment on this blog

October 2009

Automated Script-generation with Powershell and SMO

In the first of a series of articles on automating the process of building, modifying and copying SQL... Read more...

Converting String Data to XML and XML to String Data

We all appreciate that, in general, XML documents or fragments are held in strings as text markup. In... Read more...

Geek of the Week: Don Syme

With the arrival of F# 3.0 Microsoft announced a wide range of improvements such as type providers that... Read more...

How to Document and Configure SQL Server Instance Settings

Occasionally, when you install identical databases on two different SQL Server instances, they will... Read more...

What's the Point of Using VARCHAR(n) Anymore?

The arrival of the (MAX) data types in SQL Server 2005 were one of the most popular feature for the... Read more...

About | Site map | Become an author | Newsletters | Contact us

Tony Davis

The SSRS 2008 Minefield

Comments

lyndon said:

TATWORTH said:

paschott said:

randyvol said:

meklembl2 said:

Rahul Desai's Blog » Editorial: The SSRS 2008 Minefield said:

Geoff Schaller said:

Incompatabilities with 2005.RDL and 2008.RDL « CGoldwater’s Blog said:

JamieClayton said:

Sean Fowler said:

aaron_kempf said:

aaron_kempf said:

aaron_kempf said: