This post was originally inspired by T-SQL Tuesday #5 hosted by Aaron Nelson (blog|twitter) and a great rant by Jeremiah Peschka (blog|twitter) where he discussed the relative merits of encrypted stored procedures and their effect upon his rug http://facility9.com/2010/04/08/encrypted-stored-procedures-and-their-effect-on-my-rug

At work we have an implementation of an enterprise level reporting solution. It’s from a very large international independent software vendor who I shall call IISV (the initial draft named names, however I’ve decided to be a tad more discrete).

The report writers seem to love it. I believe that it gives them the opportunity to quickly develop and deploy reports, which they do on a frequent basis. The trouble is that the code it writes is shall we say, a little poor. In fact this tool is the whole reason that I have had massive blocking issues on a reporting server, although this has luckily provided me with an opportunity to gain a much greater understanding of different transaction isolation levels and the locking methods employed by each when queries are executed. You can read up on this in a previous post “T-SQL Tuesday #005 – Changing Your Isolation Level“

So this enterprise level tool, created by this huge company DOES NOT SUPPORT SQL 2008 SP1! Yup, that’s right, a service pack that has been out for over a year is not supported. Incidentally neither is SQL 2005 SP3, however if you are on SQL 2000 SP4 then it’s all good.

Earlier this year the reporting team were advised that we were going to be applying SP1 to all of our SQL 2008 servers. This caused a minor panic as we wouldn’t be supported by said company in the event of a problem. My response was quite simple on this:

“We have a choice, be supported by IISV on SQL 2008 RTM or we can be supported by Microsoft on SQL 2008 SP1. I choose the support of Microsoft because if I have a server issue then your reporting solution isn’t going to be functioning anyway”

We’re running SP1 on all our SQL 2008 servers now.

As a side bar, this IISV application has a repository database, one that has been causing deadlocks on our SQL 2000 system since it was implemented. My guess is that it was developed by some Oracle folks because every column on the main table has an index. Additionally, whenever a value is updated in a row rather than just change that value it actually updates every single cloumn, they think that it’s all good though.

While this post has been related to reporting and this one vendor they are far from the only offender with this kind of thing. Another major ISV, for example, recently refused to certify one of their major products with SQL Server 2008, as such said product will be deployed on Oracle.

Is this something that is just an inherent issue with large vendors? They just can’t keep up with the technology and ultimately force you down a road where you have to deploy a solution that is unsupported in some fashion?

I makes wonder if there is something to be said for going with some of the smaller shops and tools given that they are more likely to be agile in keeeping up with version support.