|
Sponsored Links
Resources
.NET Research Library
Get .NET related white papers, case studies and webcasts
|
ADO.NET and the database
ADO.NET and the database
ADO.NET and the database
|
Messages: 2
Messages: 2
Messages: 2
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
SSRS Sucks!
I recently completed an evaluation of Microsoft SQL Server 2008 Reporting Services, henceforth known as SSRS, and the only thing I’m happy about at this point is that I will never have to use this horrid software again. What I thought would be a simple and perhaps even enjoyable experience turned into an endless trial and error journey full of head-meets-desk scenarios. SSRS revealed itself to be one of the worst pieces of software I’ve ever used, incapable of proving itself across a very broad range of benchmarks. From the first moment you download the software to the last few clicks required to generate reports, SSRS’s only consistency is in failure. I’m going to provide a brief account of the evaluation process as well as the less-than-desirable results achieved at each stage and hopefully convince you to avoid SSRS like Mexico after the Swine Flu outbreak.
The first step (and first headache) occurs with the installation process. SSRS is available as an install option on Microsoft Enterprise Servers and also as a standalone application with Microsoft Report Builder. Installing Report Builder is just like installing any other application, but you had better set an entire day aside if you plan on setting up an Enterprise Server. Thanks to my Network Administrator I only had to uninstall and reinstall the server once after botching the initial installation. Without his help I easily could have gone through two or three installations before achieving the exact configuration needed. With the install complete and a tingly feeling inside (excited nervousness perhaps, or most likely just nausea) I decided it was time to create my first report, although a better decision would have been to quit while I was still moderately ahead.
I was feeling discouraged after the installation process, and the disappointment continued after I discovered the reporting services for SQL Server are actually integrated into Visual Studio. Leave it to Microsoft to place an application intended for business users into one of the most complicated and convoluted development environments in existence. Microsoft tries to cater to business users by labeling an instance of Visual Studio “SQL Server Business Intelligence Development Studio,” but the charade doesn’t last very long when the application opens and is indeed labeled Microsoft Visual Studio. From here even creating a blank report template gets complicated. You have the option of either creating a Report Server Project or Report Server Project Wizard. The Wizard is recommended for new users and effectively walks down the typical reporting path in order to create basic table and matrix reports. The main problem with the Wizard is that it provides no help or explanation for what you’re supposed to do at each step. Even if you succeed in creating a table or matrix with the Wizard, you’ll still feel unprepared to create your own tables and matrices. Not to mention the fact that the Wizard only creates tables and matrices, so too bad if you want to make a chart!
When I finally mustered up the courage to take on some reports without the Wizard, I discovered how little support is available for SSRS. Unfortunately I turned to a library of Microsoft Developers Network (MSDN) articles for help. These articles were created by users (I’m fairly certain) and are by no means what I would recommend if you’re trying to learn SSRS. In fact only two articles in the whole library have a rating above one star out of five. Considering the only other resource I managed to find with Google proved useless (a tutorial video in Spanish) I decided to put my head down and truck through them. These tutorial documents all make use of a Microsoft sample database named AdventureWorks. Thinking it wouldn’t be too difficult to install a database, I downloaded the setup files and got to work. Once again I have to praise my Network Admin, who rescued me after two days of failed attempts to properly set up the database. He set aside a day of his precious time to install and get AdventureWorks up and running. With this major speed bump out of the way I set out to tackle the MSDN tutorials.
At this point a strong gut feeling was telling me to cut my losses and ditch the SSRS evaluation, but for some reason I stuck with it. Most of the tutorials contain at least one piece of valuable or useful information, but overall I was taken aback at how poorly the tutorials were organized and even after completing all of them I still felt like I was unprepared and incapable of creating my own reports. Every tutorial gives the user query code to copy and paste, and while learning how to create queries is a quintessential part of SSRS, I understood that they were trying to focus on one thing at a time. I tried to play along, but since every query produced an error and I was forced to decipher SQL code and recreate the queries if I wanted to pursue the tutorials any further. The queries turned out to be much more complex than I originally thought and it took quite a long time to adequately reproduce my own queries along the same lines as those found in the tutorials. Despite the query mishap the remainder of the tutorial documents turned out to be fairly straightforward, although I was surprised at how much significant (and time wasting) detail the reports required. Different properties and preferences for data regions are scattered across numerous locations and formatting reports is far more of a challenge than it needs to be. Not to mention report generation takes a horrendously long time and making the slightest change to your template means you get to wait another two or three minutes for your report to generate once again.
If you take one thing away from this evaluation, make it that the benefits of SSRS are just not worth the pitfalls that come with it. From the initial install to the last reports you create, SSRS manages to turn the simple act of reporting into one of most complicated processes I’ve ever seen. Even if you’re prepared to set aside the time needed to adequately learn the software, you’ll feel abandoned when you get stuck in a hole with no way out and completely drained when trying to overcome all the major obstacles without a positive result to show for it. The tedious and meticulous work each report requires will not only waste your valuable time but also frustrate you beyond recognition. If you’re smart, you’ll do your business a favor and stay as far away from SSRS as humanly possible.
|
|
|
Message #322838
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SSRS doesn't suck!
I beg to differ with your blanket statement, "SSRS Sucks!" I've just been through a major proof-of-concept review of both the Microsoft BI stack (including SSRS) and Business Objects for a major corporate installation. Although BO edged out MS by .02 (out of a total of 3.0) in our particular environment, we certainly didn't find that "SSRS Sucks". I'll take his issues point by point:
1) Installation of SQL Server Enterprise shouldn't take a full day and shouldn't have to be done repeatedly. A little knowledge, planning and forethought is required, and I challenge you to find ANY enterprise level database or business intelligence server that does not require some knowledge, planning and forethought.
2) Visual Studio (Business Intelligence Development Studio) is not the end-user report creation tool. That's the BI developer's report creation tool. Microsoft has introduced Report Builder as the end-users report creation tool in SSRS. Report Builder 2.0 is found in the newest builds of SQL Server 2008 or is available as a free standalone download. It's a wonderful, fairly easy-to-use, full-fledged report creation tool and I highly recommend it. It's a huge improvement over 1.0, so if that's the only version you've looked at you owe it to yourself to check out the changes. Report Builder 2.0 is a great tool that can create all kinds of cool reports with multiple charts and tables and other nifty features.
3) SSRS is fully documented in Books Online and there are many websites with hugely helpful tutorials, articles, forums, etc. For a non-Microsoft owned site I highly recommend www.sqlservercentral.com. There are also many excellent books available.
4) Although developers should certainly be familiar with SQL querying, in a properly set-up environment an end-user using Report Builder 2.0 will never need to write any sql. They would use a drag-and-drop query builder. In a larger environment the recommendations are to use a Report Model or SSAS Cube as the semantic layer between the database and the end-user. In a smaller environment, or any time a relational database is used directly as the source for a report, then the user does need to have some understanding of the underlying database but they do not need to write sql. For instance, they need to drag a field from one table to the connecting field in another (drag the foreign key to the primary key) but all it's pretty straightforward. Even in Visual Studio there are visual query builders (similar to the way queries are created in MS Access). SQL queries are used in all the tutorials because it's a short-hand way for the tutorial writer to give the learner the same dataset so they can get right to report creation. It's easier to copy and paste a query than to describe clicking and dragging and dropping. And it's also easier to make sure the learner doesn't make a mistake if all they're doing is copying and pasting. But that doesn't mean that the average user would ever be writing a query.
5) Again, the complex set of properties for data regions that he describes is due to the fact that he's using a developer tool, not an end-user tool. He should have been using Report Builder 2.0, not Business Intelligence Development Studio. As an analogy for those familiar with Business Objects it's like using Crystal Reports compared to using Web Intelligence. They are two different animals with two different intended purposes and users. If you're not a developer comfortable and familiar with Visual Studio than you should be using Report Builder 2.0.
Designing a reporting solution for a company is rarely ever a seemless, quickie project that can be done with no knowledge or planning. Even the smallest businesses deserve a little research before someone dives into a project as complex as this. And that is not because we are talking about SSRS. I challenge anyone to find an overall reporting solution that has as many features as SSRS and has any fewer complications than those described by Mr. Fitzer.
|
|
|
Message #322839
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SSRS doesn't suck!
OK, one more quick analogy then I'll shut up ;-)
It's like you've never been swimming before but you went to the end of the pool and dove head-first into the deep end. It doesn't mean that the pool sucks or that diving sucks or that swimming sucks or that you suck or anything of the sort. No one would tell you that swimming is an entirely intuitive thing that you can do right off the bat. But most people would say, "Sure, swimming is easy. You just need to get a few tips and relax and you'll get it in no time. It may seem overwhelming at first but it's really not that hard." That's what I'd say about SSRS.
|
|
|
|
Hot threads
Hot threads
Hot threads
|
More hot threads
More hot threads
More hot threads
|
|
Speaking at EclipseCon 2006, Java developer and independent consultant Madhu Siddalingaiah compared Microsoft's Visual Studio IDE to the open source development environment of Eclipse.
(33 comments,
last posted
July 13, 2009)
In this tech talk, Microsoft's Peter Provost talks about the design of the Composite UI Application Block and how the p&p team has led Microsoft in the adoption of Agile methodologies.
(0 comments,
last posted
April 17, 2006)
Chapter 4 of Framework Design Guidelines, titled "Type Design Guidelines," presents patterns that describe when and how to design classes, constructs and interfaces. In this chapter, Abrams and Cwalina divide types into four groups and discuss the do's and don'ts of type design.
(2 comments,
last posted
July 07, 2006)
Paul Ferrill caught up with prime open-source .NET applications driver Miguel De Icaza at Novell's BrainShare conference last week. They discussed the status of Windows Forms for Mono (it's coming along) and VB.NET for Mono (it looks like it's out).
(5 comments,
last posted
March 30, 2006)
In this tech talk, Microsoft Visual Studio architect Jack Greenfield discusses the company's approach to Domain-Specific Languages, or DSLs, and the part they play in software factories.
(0 comments,
last posted
March 15, 2006)
More hot threads »
|
|
