Quality Control with SQL Server


I'm a big SQL Server guy. I preach the benefits, and advantages, and that it's a great product, worthy of picking over Oracle, DB2, or any other platform.

I get dinged all the time for being pro-Microsoft and while I do support the company and especially the people, I also try to call things as I see them. So...

What is up with Quality Control at Microsoft?

I mean they have released a great product in SQL Server 2005. It's highly secure, not needing any security released in its first 18 months of life. There are numerous subsystems, allowing you to build a complex, SOA-oriented, reporting platform that delivers reports through a queuing system after transforming data from any source imaginable.

But apparently all the senior people have moved on to SQL Server 2008. Or 2009. Or they're not paying attention.

Quality Control

First there was the release of SP2, which occurred after a long cycle. Beta last summer, CTP early this year and then a release last month.

Followed by a "re-release" on the down low because of a maintenance plan bug. They added hours to the cleanup task, but renumbered the drop down so your cleanups after "days" became "hours", "weeks" became "days", etc.

OK, we all make mistakes, it slipped by most of us in the CTP process as well, so we can understand. Admit it and move on. But there's more.

There's also a problem with DBCCs in maintenance plans. Then there's a hot fix that takes 10 minutes to run.

Now I got two more sent to me this week by people. First David P. opened a case with MS and reports this:

The MS Security Bulletin MS07-017 KB925902 hot fix that was released on 4/3/07 will cause a PC to crash if a client is attempting to print a Reporting Services Report using the small print icon on the right side of the report header. There is a bug in the patch that conflicts with the RSPrint Client Class Active-X control. Currently the only resolution is to uninstall the patch which has to be done manually.

Then I got a note from John B:

Yesterday my machine downloaded and installed yet another SP2 critical update to build 3054. This KB article describes (inadequately, I might add), the update: http://support.microsoft.com/kb/934458. It provides a download link for those whose SQL Server is on builds 3042 thru 3053, but also mentions a different patch for SQL Servers on build 3150 thru 3158. There is no explanation why there are different build ranges. One of my colleagues installed the update intended for 31xx builds on a server that had a 30xx build, and now were wondering if that was a bad thing to do. Do you know the difference between builds 30xx and 31xx?

I can't help John, but maybe one of you can.

But what is wrong with Microsoft's quality control here? We have had numerous problems with patches to SQL Server 2005. Supposedly the testing is as good as it's every been, more tests, more configurations, etc. and for some reason it's not working.

I like patches to come quickly. And I think we should have regular roll ups to make life easier. But I also want them tested well, tested with real scenarios that we use, and with someone reviewing the results.

Honestly it almost seems like testers are looking more at feedback from users in the beta/CTP cycles than at their own tests. Or their results are too automated and things are being missed. How can you miss that the DBCCs don't work? It's simple. How can you miss that cleanups occur in hours?

I know how, and I missed it as well, but it's still sloppy work from a vendor.


I'm very disappointed to be seeing issues and I'm a little put off that I don't see anyone at Microsoft blogging about issues. I scan dozens a blogs and they're mostly silent these days.

At least from the SQL Server team. The Vista folks, Exchange, Office, and especially the Visual Studio/Team Foundation Server folks. But SQL Server? Not many posts. Not much information and not much interaction.

I think SQL Server is one of the best Microsoft products. It performs well, sells well, and is very popular. So I'd like to see more exposure for the SQL Server team, more information, more press, and more honesty. Do high quality work and if things slip by, admit it, work harder, and get them fixed.


5 (2)




5 (2)