I never thought I'd say this, but working with SQL Server Reporting Services (SSRS) has taught me a valuable lesson...

It doesn't matter what report engine you use, they all have their quirks.

I have a Crystal Reports background thanks to the ERP system that I used to support. I learned how to work with it inside outside upside down. It got to the point that I knew how to get it to do what I needed, no matter how obscure my end users got with their requests. It was a good thing.

Now I'm in a SSRS environment, and I curse my unfamiliarity with this report builder. I have to keep reminding myself that it's a Microsoft tool - so many options that I'd be looking for in context menus are probably hidden in toolbars. For example, I was looking on doing conditionally-formatted row backgrounds, and I eventually found it in a toolbar - as soon as I reminded myself that it's a Microsoft product.

But then there's this other maddening (lack of a) feature. Why can I create an expression for my tablix's sort field but I can't use an expression to specify the sort order?

And what's this "A to Z" and "Z to A" sorting terminology? Who are they designing this tool for? As a database admin and a developer, I would know ASC and DESC or even ascending and descending. Dates sort on their date type, numeric types in a numeric order... and neither of those are handled the same way as a character sort. Is the report converting all of its data to strings and literally doing a character sort? Nope - it is sorting ascending and descending. Can SSRS get an update so that it accurately represents the sorting? Is it smart enough to possibly detect the data type of a field and show "highest to lowest" for numbers and "earliest to latest" for dates?

As I continue to work with SSRS, I hope my complaints will subside. But there are some quirks that, in my opinion, make it worthy of the SUX appearances.

Just when I thought I was done with the SUX series for the year, I came across this gem.

Recently, I've been working with SQL Server Reporting Services and trying to work with it in ASP.NET. While reading logs, I came across an error regarding TERADATA. Why is it that my SQL Server Reporting Services (SSRS) is giving me an error like this on a fresh install?

So I did some searching through Bing, which led me to this article on Troubleshooting Configuration Problems. And then I saw this...


This error occurs because the Teradata extension is registered in the Reporting Services configuration file by default, but the Teradata assemblies are not shipped with SQL Server 2008 or as part of the .NET Framework. If the error message does not bother you, you can ignore the error when it is logged.


Wow... really? Why is an extension registered by default if none of the assemblies are included? Why is it an acceptable practice to pollute the event log with errors right after a fresh install?

Granted, they included how to avoid the error. But still....

If the assemblies aren't included, I would expect the extension not to be registered. Let the installer detect if the assemblies are installed and then enable it by default if it is detected. Include instructions in the installer that the TERADATA extension is enabled by default and have a simple way of disabling it on install. Strike up a deal with TERADATA so that the assemblies can be included in the installer. And if that isn't feasible then don't include the extension in the installer and let an installer with the TERADATA assemblies handle registering the extension.

Why add unnecessary clutter to the event logs when it should be avoided in the first place?

Don't get me wrong - adding support for TERADATA may be a nice feature. But for those of us who aren't using it, it's cleaning up setup stuff that - in my opinion - shouldn't be included in the first place.

Because of this approach, the combination of SSRS with SQL 2008 and TERADATA on a fresh SSRS install truly SUX.