It's been a couple of months since I last wrote a blog entry. I have a good excuse: went through some major-ish surgery and was laid up for about a month.

Luckily I/we do the kind of work you can do at home; after I stopped the "good drugs", mostly I was just lying down with my brain intact.  I wasn't more-than-usually thick-witted. Still, it was a struggle just to keep up with required things, so I haven't felt much like writing here.

While I was immobile, I spent some time reading a book called Learning SQL Server 2008 Reporting Services at the request of its publisher, Packt Publishing.  Saalim Shaikh (mailto:saalims@packtpub.com , in case you would like to offer your services to the company, they might need writers) wrote to offer me a copy if I would review it "within 30-45 days of receipt". 

I'm probably at that limit now, or close, so I'll write my review immediately, and I hope I start writing more blog entries here on a regular basis now.

Why should I review this book?

Saalim seemed to think I was a good candidate as a reviewer because I know something about Reporting Services, and maybe for that reason my opinion of the book would carry weight with potential buyers.  That's very flattering.

I'm not sure if Saalim is going to have the same opinion of my opinion, once he reads this review.  Sigh. 

But, to be honest, I am a subjective reviewer, nothing more.  I need to start by considering my own opinions of why people read IT books on subjects like Reporting Services, and what they are looking for. 

Maybe your opinions about why you buy and read these books are different from mine, and maybe this book is perfect for you. I'll try to give you the information you need to decide whether that's the case. 

Also Saalim has offered to give me a link to an excerpted chapter, to share with you — if he still wants me to do that, when he reads this post, I will update it with the link and you will have more information to help you decide for yourself.

Who should read this book?  What's it for?

The title, again, is Learning SQL Server 2008 Reporting Services, and its subtitle is A step-by-step guide to getting the most of Microsoft SQL Server Reporting Services 2008. 

The first thing you should know is that this book is for people who don't find clumsy English usage distracting or jarring when they are trying to read (getting the most of?).  But, okay, that quibble probably doesn't filter out very many IT people.

The second thing you should know is that this book is not for people who want to get the most out of, or the most from, SSRS 2008.  It's for people who don't know anything about SSRS and need step-by-step handholding through the various features of the product that are touched on as part of the most basic usage.

Let's be honest: there are probably a lot of people in this boat.  What's more, SSRS may be a particularly apt candidate for this approach in a book. 

Why do I think this? The most off-putting thing about MS reporting is the way it touches on so many different aspects of MS technology.  Let's take a stab at listing them:

• SQL and other ways to get a result set from data (business objects, web services, XML files, semantic models, various design surfaces that don't match up with each other)
• UI design and usability principles (both for the reports themselves and for the interface surrounding them)
• Security (particularly if you're using integrated authentication, you may be asked to understand the underpinnings in ways you hadn't needed before, if you're sharing reports over the web you'll need to decide appropriate authentication strategies )
• .NET coding (whether you're a web type or a winforms type, whether you add custom extension code to the reports themselves or confine your code to the interface surrounding the reports)
• Deployment and packaging principles for "pull" clients, plus potential SSIS packaging for "push" clients (do you want to use SSRS default scheduling, or are your needs more extensive?)
• Printing and rendering systems on clients (god help us)
• XML and XSD as the underpinnings of the system
• Architecture decisions (if you're using ReportViewer controls, should you use local or remote mode? What difference will it make? What are the performance, efficiency, and flexibility tradeoffs?)
• SharePoint integration (for those whose organizations are committed to SharePoint, you may be asked to house reports in SharePoint and write integration code that puts your head in an entirely new place)
• … I'm sure I've left some out.   And the plain truth is that most people coming to SSRS don't know anything about at least a few of these areas.

I'm not saying that this book covers all of these subject areas adjacent, or tangential, to.  It doesn't cover all of them. 

Even where it covers something, in some cases it gives the lightest possible "demo example", as if knocking something off a checklist, and then moves on to the next topic.  For example, the SSIS section, which is about a page, uses a script task to to create an instance of IE and feed it a report URL to display the report.  Not only is this not a very realistic idea, but it doesn't actually do anything with SSIS or tell you why you might want to use SSIS with SSRS.  What's the benefit?  What's the business idea behind such an integration?

Also, for some reason, the author chose to use a DTS-oriented ActiveX scripting task, which may require a backward-compatible download over the standard install in 2008, rather than a new-style Scripting task.  I have no idea why anybody would do this in a book about SSRS 2008.

But, depending on where you're coming from, this book may give you the perspective you need to decide what's possible and what you need to investigate to use SSRS productively.

You may be a SQL programmer who's been tasked by management to provide reporting; in that case, this book will show you how to expose reports in the default Report Manager interface with no additional .NET programming.  If Report Manager is not what you need, you'll be given a very light walkthrough showing you how to create a web form or a win form that incorporates the ReportViewer control, so you understand something about the potential.  You'll also be given a walkthrough with ReportBuilder 2.0 and how you can use it to move some of the responsibility for report creation to your end users.

If you're a .NET programmer who's been asked to incorporate RDLs in your applications, you'll benefit from these sections in the same way: you'll see what's possible and how you might begin to incorporate reporting into the tasks you already know how to do.

Okay, we've looked at possible reasons to read the book, depending on who you might be and what you might need.  What more, you might ask, would I really buy a book for?    

This book is about wizards, not for them.

No individual perspective from which I could imagine reading this book (the .NET programmer, the SQL programmer, etc)  is entirely satisfactory.  No professional, from any background, is going to learn enough to get any real work done.  

But at least you'll get started.  And the author announces his intentions, and limitations, on the second page of the text, they're not hidden:

Microsoft has strived [sic] hard and is striving harder to ramp up productivity (write less code) by advocating the idea of RAD (Rapid Application Development), what I call Microsoft Wizardry.  The idea that anyone can generate a report even if he/she is not well versed in the inricacies involved is a great motivator.  The major emphasis of this book is on this very idea, knowing the wizards.  In doing so, coding has been kept to a minimum, but it is not absent.

Leaving aside the author's interpretation of RAD for a moment, there's no doubt that this emphasis and approach is my core objection to this book.  It goes through exactly what MS already did a good job helping you do; it goes no further.

Considering that it calls Microsoft's documentation "excellent, the last word on anything you need to know", a reader would be forgiven for thinking that there actually isn't any further to go.  Considering the number of times that the same wizard-driven activity is repeated during different report creation exercises during the book — selecting a datasource and testing the connection, lovingly detailed with screenshots for multiple pages, is dealt with I-didn't-count-how-many times, even though these dialogs are really not unique to reporting — a reader would be forgiven for thinking there isn't any hard work to do in SSRS or enough to write about to fill up the required number of pages.

To the author's credit he also mentions that "You can go beyond and invade [sic] its [Microsoft's] forums to learn even more, as I have done myself." And there's an appendix with a number of really useful URLs you can use to go further, by people who take a more creative approach to the potential value of SSRS and what you can do with it.

Well, I don't want a book that walks me through the wizards.  What do I want a book for?  

I want a book to consider "why" and "when"

One core reason I read books, besides going beyond the documentation and the wizards, is to find out why certain features exist.  It's there, MS may even have made it easy to spot and easy to use with Wizards and other GUI exposure, but…

Why would I want to integrate SSIS and SSRS, what will it buy my business users?  In what scenarios does it make sense to use an XML file as a reporting data source?  Why would linking reports be a good strategy, and why not (what are the maintenance implications)?  If I use a subreport as compared with a drillthrough, what are the performance implications, why would I choose one versus the other?  Why is Crystal Reports still in Visual Studio and why would I use Crystal versus SSRS?

For that matter, why is Crystal Reports even in this book, even though Microsoft and Crystal Reports "have an established relationship" and Crystal is a "great technology, considering that it isn't part of SSRS ?

The last question leads into… so many others.  My additional questions about MS technology often require a sense of product history to understand and answer. When a feature got added — and under what political as well as technical circumstances — is often key to understanding why to use it or not to use it. 

And with this lack of history, from my point of view as an SSRS user, another critical failing of this book surfaces: somebody who already uses SSRS 2005 and wants to upgrade isn't going to get a lot of perspective on what has changed, what's better, what might break their existing code and interfaces. 

That's okay, if you've never used the product before, and don't care.  There are probably lots of users in this boat, considering that RS is an MS technology that is first reaching its "adult" (3.0) status in this version. 

Some of the users in this boat used to use Crystal Reports; this is one reason why some informed comparison of the two products might have been useful rather than a disconnected chapter.  Why and how might you go about converting your reporting strategy from one report to another?  And when?

But those of us who are already SSRS users do want to "get the most" out of SSRS 2008.  We want to know:  How has the SQL engine and the rendering set changed? Where do third-party products we may have used before, as add-ons, fit in ?  Which techniques we've used before should be discarded now?  What standard workarounds recommended for RS 2005 should be changed in existing reports? Are there any new wrinkles in displaying some of the new SQL Server 2008 data types, or writing expressions using them in the Expression Builder? Are there recommended configuration differences? 

What are the practical ramifications of the standalone service, versus IIS underpinnings, for Reporting Services? Why were some other new items added, what are they especially good for? Why are Visual Studio and RS out of step with regard to local mode RDL schemas, and when might this change?  Why was Report Builder 1.0 still the click-once application in Report Manager at RTM, and how would you change this? 

The last two questions are especially history-oriented, but people who use MS technologies need to find out these things to make adequate choices.  An author may need to do a little independent reporting and research to find out the answers to this type of question —  but IMHO an author ought to.

I guess I'll keep digging, I'll keep reading, and… I guess I'll keep writing, too.