Getting Your "Favorite" SQL Server Bug Fixed

As a PM in SQL Server I read through just about every bug entered for the components my team owns. Given the surface area of what my team owns this translates into a lot of bugs. I don't characterize it that way to disrespect the team or the quality of the product but rather to make a point there are a lot of things that are vying for attention. Add in the new feature requests and there's a lot to look at. We have limited resources and limited time. We cannot possibly fix every bug. So we have to prioritize what we work on and when we work on it. The first order of business is to determine which bugs are "real".

When we triage bugs we take in account many different factors. For example, how many customers does it impact, how often will a user hit it, is there a workaround, is it a regression, does the bug result in data loss or a crash.

So the question is how do you get your bug fixed? Here are some tips for increasing the odds:

1) Include detailed information about your environment. What OS are you running, what SP, are you up to date with Microsoft Update critical updates, what other interesting software do you have installed (think Visual Studio),

2) Include detailed information about your SQL install. What is the full version number, how many instances do you have on the machine, is it a named instance, what's the collation, what SQL components are installed, etc.

3) Include detailed steps to reproduce the problem. Be as specific and detailed as possible. State if the problem consistently happens or is intermittent.

4) State what you expected to happen vs what actually happened. Include a screen shot if applicable

5) Include all error messages. If you get an exception, include the full exception message.

6) Finally, include the impact the bug has on your "business". Do you have to reboot the machine every time you hit it - meaning you have to take down a server.  

Does doing all this guarantee your bug will be fixed? No. But it does increase the odds. Remember, if we don't understand the bug we can't fix it. If we can't repro it, we can't fix it.

Oh, one last thing. Don't be disrespectful in the bug. You'd be amazed some of the comments we get in bugs. Why would I put any effort in to a bug that came from someone who's insulting me, the team, or the product? Think of it this way. Would you hire someone with a sloppy resume and insulting comments? Would you expect to be hired with that resume?

One more last thing. I'm a big fan of Connect. Yes, it has its quirks, but it's an invaluable tool for collecting and responding to customer feedback.

Comments

• Anonymous
  January 11, 2008
  PingBack from http://geeklectures.info/2008/01/11/getting-your-favorite-sql-server-bug-fixed/

• Anonymous
  January 11, 2008
  PingBack from http://geeklectures.info/2008/01/11/getting-your-favorite-sql-server-bug-fixed/

• Anonymous
  January 11, 2008
  PingBack from http://meaningofnames.co.cc/getting-your-favorite-sql-server-bug-fixed/

• Anonymous
  January 13, 2008
  A very interesting article describing how Microsoft personnel decides which bugs get fixed first. Getting

• Anonymous
  January 13, 2008
  Isn't there a tool (executable file) that one can run to fully document their system, dumping the output to a text file? I'm pretty sure there is, but I cannot remember the name of this tool right now. If you simply had folks run this tool and send the text file, it seems like the output should answer all questions raised in paragraphs 1 and 2.

• Anonymous
  January 13, 2008
  I'm sometimes amazed how personal people takes the bug issue. If you look at users you can sometimes think that the users think we have a complete bug list or that we have super powers to figure out what the problem are. And believing that a rotten attitude gets the problem fixed faster is so stupid. But if you look at it from the other perspective, I often find developers taking pride in classifying something as a bug. In these days of agile and customer driven development, why taking so much pride into saying if something is a bug or a change request. During the past two years we've gotten two synchronization bugs fixed in SQL Server 2005. My tips: be honest, give all information you have, understand that everyone wants to fix the bugs and don't forget that the guys fixing and confirming the stuff are people. Often really nice people. And also remember that reporting a bug is like going to the ER: sometimes there are people who are sicker than you and they need help first.

• Anonymous
  January 17, 2008
  I understand there is no justification for using faulty language or offend the developers. Most of the users that report bug fixes are developers as well.  I have reported a few bugs myself and have dealt with extensive hours on hold on the phone waiting for  tech support. Once I get a hold of an engineer and he/she is able to test the repro, things go faster. On the other hand, there has been several bugs, for instance in replication that did not happen on previous versions. SQL Server Developers should also understand that data loss is a serious problem for any organization, if the organization is a financial institution, the problem is even bigger. There is a very annoying fact that bugs are not published or documented, I personally believe that if they are documented, even for only those users that have access to tech support, it would be easier to match an existing bug with the current problem, without waiting for a MS tech support to do the match. We know everyone wants to have the bugs fixed, but it is worrisome that the numbers of bugs of a new version is higher to the previous version. Maybe slowing down the the new releases will ensure higher quality in the existing products? Just my two cents... Someone should be accountable for bugs that cause data loss/money to organizations, even if that someone is a very nice person.

• Anonymous
  January 29, 2008
  Someone asked if there wa a tool they could use to generate the systrm information. You can use "System Information" and export the info to a text file. This provides far more data than we generally need, but it will save you a bunch of typing. The generated text file is ~800Kb.

• Anonymous
  February 04, 2008
  << One more last thing. I'm a big fan of Connect. Yes, it has its quirks, but it's an invaluable tool for collecting and responding to customer feedback. >> Well...  why is it so hard to Connect?  Seems like it could be much easier, especially for the first time user who would like to report a bug.  I've documented my first time frustrating experience with it here:  http://web.mac.com/downeycp/CPD/Blog/Entries/2008/1/30_SQL_Server_2005_Invalid_Subquery_Bug.html

• Anonymous
  August 20, 2008
  In SQL Server we use Visual Studio Team System to track all of our work. There is a back-end integration