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.