Dan's Blog : General

What Has 2 Thumbs & Is Excited About Windows 7?

dtjones — Sun, 11 Jan 2009 03:38:26 GMT

Answer: This guy!

I’ve been following very closely the press and reviews on the early peaks of Windows 7. I’m not as big of a Vista hater as some people out there. In fact I like the OS. I recently had to reinstall XP on another machine and was absolutely astonished how old it looked and felt. In fact I couldn’t stand it, I had to reinstall Vista on the machine right away.

Being a MS employee and shareholder I have double the interest in Windows 7 being successful. But I’m also a critic. I look at each of our products with a scrutinizing eye. If you read my blog you’ll find two MS products that I absolutely love: Windows Live Writer (which I use to write this blog) and Windows Live Mesh (which I use to synchronize files between machines). I’m also a huge fan of SQL Server (duh!) But I am a critic of the product and I know first hand it’s not perfect, especially in the manageability space, but I’m working tirelessly to improve it one release at a time.

Back to Windows 7. Part of me felt that Windows 7 wouldn’t have a chance of being successful. Granted it would almost be impossible to cause a worse impression than Vista but I felt people would hold it to an unfairly high bar and nit pick every last square inch. Everything I’ve read thus far is very favorable. On top of that there seems to be some excitement for it!

One of my very good friends did a clean install and an upgrade from Vista without a hitch. He’s super critical and even he had great things to say: GUI enhancements, power management enhancements, etc.

I’m starting to believe that Windows 7 is THE OS everyone wanted Vista to be. Windows 7 will likely be to Vista what XP was to ME.

Next week I’m going to do a clean install of Windows 7 on my main laptop (Lenovo x301). I have 4 GBs so I’m going to do an x64 install. I’ll report back on my experience.

What’s In Your Database?

dtjones — Wed, 17 Dec 2008 10:08:42 GMT

How many different database objects are there? I don’t know the answer either but off the top of my head I’d guess somewhere between 50 and 100, depending on how you count them. Yes, I could go count them but I’m writing this on a Saturday and between you and me I’m just too lazy to go do it. If you profiled (not as in SQL Server Profile) your databases what do you think your Pareto chart of objects would look like. I bet it would look something like the following:

The scale isn’t important, what is interesting is what objects are most in number and what objects are least in number. If you aggregated this data for all of your database the picture probably wouldn’t change all that much. However, we tend to become obsessed with the right-hand side of the chart. The objects that make up the right-hand side (e.g. triggers, types, etc) are important but sometimes we spend far too much time talking about them at the cost of creating solutions that are simple and easy to use. BTW: I purposefully left off indexes – those will likely out number tables. My point here is we should create tools that make it extremely easy to work with the objects that are in abundance. This includes everything from defining them, deploying them, and managing them after they’ve been deployed.

Everyone likely has a few databases that don’t match this relative distribution but I believe you have far more – at least an order of magnitude if not two – that do. Those database are important as they likely house your most valuable applications; your mission and business critical apps. And we need tools that support those apps and objects as well. But in the process of building tools we shouldn’t make the stuff that should be easy hard. The hard stuff should be possible and the easy stuff should, well, be easy.

In general this approach was taken with IntelliSense in SQL2K8. Yes, there are some things that IntelliSense doesn’t cover. But so what. I know, you’re thinking that’s the stuff we should have covered since you don’t do it all that often and that’s when you need help. if we took that approach – the reverse approach – then you wouldn’t have had IntelliSense for something like table. How lame is that? You’d criticize us for not covering the basic objects. Ok, well, you can probably say we should cover it all. And you’re right. We should. But that’s not always practical. Remember we’re constrained by time and resources just like you are. So we have to make trade-offs. This takes us back to my main point – when we have to make choices we should error on the side of covering the common stuff first. We’re getting better at this but I think we have some major work to do on the common stuff (think table designer in SSMS).

Oh, while you’re profiling your databases don’t forget to count filegroups and files. We recently profiled over 1,000 customer databases that had been consolidated or were on the list to be consolidated. Think of these as departmental apps (they’re not Mission or Business Critical). Only 2-3 databases had multiple filegroups and/or multiple files. This shocked me. But given the average size of these databases was less than 2GBs I shouldn’t be surprised as there was no driver for multiple files.

If you decide to profile some of your databases let me know what you find.

Addendum:

We now have customer data on over 1,000 databases. These are DBs that have been consolidated or are candidates for consolidation. Here consolidation means increasing the density of DBs per instance; not increasing the number of apps per DB. Excluding indexes and constraints the average distribution of item types looks like this:

This data aligns more closely to what Adam’s (see comments below) has seen in the wild. Adam, thanks for replying and “forcing” me to provide a more real world example of the distribution. :-)

Getting Started in the Community

dtjones — Sun, 07 Dec 2008 20:34:18 GMT

As an under-grad student @ Cal Poly San Luis Obispo, some 18 years ago, I first experienced the power of the technical community. I was working on a group project to build a little app for the Mac. The class was Software Engineering, CSC440, which covers the entire software lifecycle – requirements, design, implementation and test. My group’s project was to build a search utility for the Mac. Each group member played a different role on the team. I was responsible for writing the code but I was having trouble enumerating all of the hard drives – I couldn’t find the right OS API for this. I know, it seems silly now. I fired up my modem and connected to the university’s newsgroup server and used the comp.mac Usenet newsgroup for help. In the matter of a day (pretty decent latency back then) I had the solution to my problem. Over the course of the next couple of weeks I posted more questions and received answers very quickly.

Community is an important part of a software product. It can serve as tech support and training. Show me a popular product and I’ll show you a strong community standing behind it.

I often get asked the question “if I’m not an expert how can I contribute to the community?” I think a lot of people feel this way. My answer to this is “if you are passionate about the product/technology then you can contribute a lot.” The key, in my book, is to approach it systematically. Here are the steps I recommend to anyone who wants to get involved:

Pick a community (UseNet newsgroups, MSDN forums, SQL Server Central forums, etc)
Pick a topic you are passionate about (PowerShell, T-SQL programming, query performance/tuning, SQL Server Agent, etc)
Pick a few questions that have already been answered and try to find the answer yourself – check your answer
Pick a few questions that haven’t been answered and answer them – this is probably going to take some time as you research the problem and answer.
Pick a few more questions and answer them
Expand to additional communities and answer questions
Collect the more interesting questions and blog about what’s interesting about them
After a few months write a short article on the topic incorporating what you’ve learned over the past few months
Develop a presentation for the article and submit it as a session to a conference
Repeat 5-9

My participation ebbs and flows a bit. When I’m in the game I set aside time each day, 15 minutes or so, answering questions in the forums. You should do the same. And remember, if you use a reference (such as a book) to answer a question site the reference. One other thing – try to use the same username in all of the forums you post and the blogs you write. This gives you name recognition over time. You can go with something dry, like dtjones (my alias @ MS) or something fun like SQL Batman (one of my favorites).

I ended up getting the search utility working and we got an ‘A’ on the project and in the class. If only I had the insight back then to recognize how important and valuable search would become…

Scripting DBA Actions

dtjones — Sun, 23 Nov 2008 20:54:18 GMT

Last Thursday morning @ the PASS Summit I participated in a panel discussion on automating DBA tasks. It was a great discussion and I was humbled by the other panel members. During the discussion I jotted down a few notes that I didn’t get to mention during the talk. The talk was recorded and will likely be available on Quest’s site in the next few days or so.

The first distinction to draw is the difference between scripting and automating tasks. Scripting tasks simply means there is some programmatic representation of the task you want to perform. The program can be in any language you choose: Python, PowerShell, C#, Perl, T-SQL, SSIS, etc. The script does all of the necessary work. Automating tasks simply means the script is automatically initiated by some action. The action could be a SQL Server Agent job, a Windows Scheduler task, an Extended Event (X-Event), a server/database trigger, a Service Broker event, etc. In other words, instead of the script being manually executed in an interactive way it’s automatically executed in an unattended manner.

During the discussion I made the statement that everything should be scripted but only the right things should be automated. This is one of those high-level statements that has a lot of room for interpretation. But that’s the point. You shouldn’t think about scripting something or not. If it’s a task you do more than once (in a day, week, hour, month, quarter, etc) you should script it. If it’s a task that others needs to also perform you should script it. But you should think if it should be automated or not. Only the right actions should be automated. Remember, you probably aren’t going to be there when something goes wrong. Also, if the task requires reasoning that’s not easy to capture in a script you don’t want to automate it. In any event I wanted to capture some best practices for scripting.

Most of the scripts I come across aren’t very good. Sure they perform the necessary task but that’s about it; venture a little off the expected path and everything goes wrong. The script author simply took the T-SQL script and stuck it in a BAT file that calls SQLCMD. Here are some bullet points (in no particular order) that you should consider when creating your scripts.

Header information: create a standard template for the header of your scripts. It should contain some simple information like:

Title
Description (what it does)
Execution Permissions: what permissions does the script need on the targets it runs against. The goal here is to identify the lowest level of permissions needed for the script to run successfully.
Inputs
Outputs
A simple change history: date changed, who changed it, what was changed

Variables: don’t hard code anything in your script. If you’re using a constant define it up front and use the variable in the body of the script. Don’t use any hardcoded values in your script. When I’m writing a script I force myself do to this up front rather than remembering to come back later. Doing this allows me to easily turn a constant into an input parameter.
Single vs. Multiple Targets: make sure your script can run against multiple targets. For example, you may write a script that runs against a single table. Shouldn’t it really be designed to run against multiple tables? The single table case will automatically be handled.
Error handling: what does your script do when it hits an unexpected case? If you have a lot of scripts it’s worth the time to come up with standard error handling routines that you use in all of your scripts.
Auditing: what standard information should the script output. In some situations it may be necessary to keep a log of exactly what the script did. Where should it store this information: a table, a text file, an XML output file?
Debug Switch: This is related to auditing but when the script is run in debug mode it outputs a greater amount of detail – that you need to debug problems but don’t need to see in normal operations.
Re-entrant: In some situations this is hard to do. The script should always check for pre-conditions (what is the expected/necessary state of the targets the script runs against). If the pre-conditions aren’t met the script should gracefully fail. What happens if the script is run 5 times in a row? What happens if the script hits an error, the error is corrected and script is rerun? You’re scripts need to handle these cases; they need to be re-entrant. This may mean it may need to perform a little clean-up at the beginning of the script – residue left over from a previous run.
Naming conventions: your scripts have a file name, variable names, method names, etc. Establish naming conventions so you can easily find the script you’re looking for (I like to use noun-verb or verb-noun – to follow PowerShell) and easily troubleshoot your scripts. Don’t use something like x1 as a variable name.
Location of your scripts: think about storing all your scripts in a standard location. I recently blogged about Windows Live Mesh. A folder that you meshify is a good candidate for your scripts. This will allow you to keep the scripts synchronized between several machines, a copy will be kept up on the web so you can get to it from just about anywhere, and you can share your scripts with other people – as long as they have a Windows Live Id. I’d also save a copy on a USB drive so I always have them in hand. Sometimes I need to do something on a server that can’t access the internet. So long as the USB ports haven’t been disabled I’ll be able to get to my scripts.

It’s very easy to ignore these items and end up with a bunch of .bat or .ps1 files that you have no idea what they do. If you spend a little time up front it’ll pay dividends. Your co-workers will come to you to borrow your scripts or for help on their own scripts. You’ll be know as the Script Guru! And many great things will come your way.

Okay, maybe those last two points are a bit over the top. In all seriousness though, we’re professionals and we should treat our scripts to a professional touch.

Windows Live Writer Update

dtjones — Fri, 07 Nov 2008 19:50:58 GMT

Back in July 2007 I started using Windows Live Writer as my exclusive blog writing tool. I’m not a heavy blogger but I do need a tool that’s easy to use and still helps me write more complicated postings when needed. I still LOVE Live Writer. It’s simple and intuitive. It doesn’t have a bunch of stupid features that get in the way of doing the mainstream stuff. My fear when I started using it was the team would muck it up over time by adding a bunch of useless features. Well that hasn’t happened. I just downloaded the latest beta. It’s great! They’ve stayed true to the usability of the app and have improved the usability of a few features. For example, there’s now edit, preview and sources tabs which allow you to switch between different views of your posting. You could do this in the older version but it was a little more cumbersome – you had to go up to the menu bar to select a view.

If you blog I encourage you to give Windows Live Writer a test drive. I’m glad I did.

Windows Live Mesh

dtjones — Wed, 05 Nov 2008 18:09:00 GMT

I recently started using Windows Live Mesh to synchronize files between multiple machines. This software is so cool and so useful I just can’t say enough good things about it. In addition to sharing files with yourself you can setup folders to share files with others. Sharing files on the web has been around for a long time but this is the cleanest implementation I’ve seen where I don’t even have to launch a browser – once I’ve installed the client. I can do everything from within Windows (or Mac). But, if I’m away from my machine I can still access my files from any browser. It does require that everyone you want to share with have a Windows Live Id – no big deal. I found the installation a snap and within just a few minutes I was sharing and synchronizing files between two machines. It also has remote desktop capabilities although I haven’t tried those yet. There’s also a 5GB space limit. So far that’s no biggie either.

I have zero patience for complicated and crappy software. Live Mesh passes both tests. It was very simple to get up and running and what it does it does very well. Kudos to the team that built-it! I just wish I had this stuff when I was doing my under-grad and graduate degrees. It would have made group projects so much easier. Oh I almost forgot, you can also access it from your mobile. I still use a dumb phone but this just may be the reason I upgrade to a smart phone.

Blogapoluzza

dtjones — Tue, 16 Sep 2008 04:59:10 GMT

The list of blogs run by the SQL Server product group keeps growing. Here I offer merely a snapshot in time of the current blogs. At the bottom there's also two links that list blogs by MS employees and SQL Server MVPs; these are not complete but offer a decent taste of what's available.

Microsoft SQL Server Team Blogs List:

· SQL Server Storage Engine Team blog: http://blogs.msdn.com/sqlserverstorageengine/

· PSS SQL Server Engineers blog: http://blogs.msdn.com/psssql/

· SQL Server Security: http://blogs.msdn.com/sqlsecurity/

· SQL Server Express WebLog: http://blogs.msdn.com/sqlexpress/

· The Data Platform Insider: Official insider news about Microsoft's Data Platform technologies: http://blogs.technet.com/dataplatforminsider/

· SQL Server Reporting Services Team Blog: http://blogs.msdn.com/sqlrsteamblog/

· Microsoft SQL ISV Program Management Team: http://blogs.msdn.com/mssqlisv/

· SQL Server: Service Broker Team Blog: http://blogs.msdn.com/sql_service_broker/

· SQL Server Manageability Team Blog: http://blogs.msdn.com/sqlrem/

· Policy-Based Management Blog: http://blogs.msdn.com/sqlpbm

· PERFGURU: Technical Blogs on All Kinds of Performance Issues: http://blogs.technet.com/perfguru/

· Data Development: http://blogs.msdn.com/data

· ADO.NET: http://blogs.msdn.com/adonet

· Astoria: http://blogs.msdn.com/astoriateam

· JDBC: http://blogs.msdn.com/jdbcteam

· SNAC: http://blogs.msdn.com/sqlnativeclient

· PHP: http://blogs.msdn.com/sqlphp

· EF Design: http://blogs.msdn.com/efdesign

· SQL Protocols: http://blogs.msdn.com/sql_protocols

· XML: http://blogs.msdn.com/xmlteam

· Velocity: http://blogs.msdn.com/velocity

· SQL Server Data Services (SSDS): http://blogs.msdn.com/ssds

· Compact Edition team: http://blogs.msdn.com/sqlservercompact/

· Performance team: http://blogs.msdn.com/sqlperf/

· Query Processor team: http://blogs.msdn.com/sqlqueryprocessing/

· Programmability & API Development team: http://blogs.msdn.com/sqlprogrammability/default.aspx

· CLR Integration team: http://blogs.msdn.com/sqlclr/default.aspx

· Synchronizer: http://blogs.msdn.com/synchronizer/default.aspx

· SSIS team: http://blogs.msdn.com/mattm/

· Samples Team: http://blogs.msdn.com/bonniefe

· SQLCAT (SQL Server Development Customer Advisory Team) team: http://blogs.msdn.com/sqlcat/ http://sqlcat.com

· SQL China Team blog: http://blogs.msdn.com/sqlcrd/

· SQL Japan Team blog: http://blogs.msdn.com/sqljapan

Microsoft Employee SQL Server Blogs List: http://technet.microsoft.com/en-us/sqlserver/bb671052.aspx

Microsoft Connect Resolution Reasons

dtjones — Wed, 20 Aug 2008 17:22:27 GMT

In SQL Server we use Visual Studio Team System to track all of our work. There is a back-end integration between the Microsoft Connect site and our VSTS database. When an item is submitted through the Connect site it eventually flows to our VSTS database. We, the product group, can manage the bug directly from within VSTS and certain data flow back to the item in the Connect database.

One of the properties which goes back is the resolution reason. Here are the resolution reasons along with a brief description. As with many attributes there are exceptions; this simply means that not everyone applies exactly the same precise definition and in some cases the wrong reason maybe selected. In other words, use this as a general guideline but not as a hammer.

Fixed: If the item is a defect (a bug in the system) this resolution means it was fixed. If the item was a feature suggestion it means it was added to the product. It may not have been added to the exact specification in the Connect item but the general spirit was implemented.
Won't Fix: If the item is a defect this generally means we've verified it is a problem but we have no plans of ever addressing it. If the item is a feature suggestion is too means we have no plans of ever addressing it.
By Design: This generally only applies to defects. It means that we've verified the reported behavior but we believe this behavior is expected and therefore is not a defect. For example, cannot install BIDS on IA64.
Not Repro: It means that we are unable to verify (reproduce) the reported behavior. I know this one can be extremely frustrating. The more detailed the defect report the better are the chances we'll be able to verify it. I blogged about this back in January. We cannot fix what we cannot reproduce. Depending on the criticality/severity of the defect we will spend varying degrees of time attempting to verify it. Defects that are more severe will get more attention. Just remember we're under constraints just like you.
Duplicate: This simply means the defect or feature request has already been submitted. Often I'll attempt to keep the one opened through Connect as the master so the community can track it. If multiple come through Connect I'll try paste the URL to the original when I close the duplicate.
External: This means the issue does not belong to SQL Server. It could be a Windows or Visual Studio problem. Unfortunately we don't have a robust system for moving bugs around. We have to close it in one VSTS database and open it another. This results in a broken link to Connect .

I hope this information helps you to decode the resolution of your submitted items. Remember, sometimes the person closing the item selects the wrong reason or doesn't provide a complete description explaining the resolution. We try hard to be thoughtful and communicative but sometimes stuff happens.

Automating DBA Processes

dtjones — Mon, 18 Aug 2008 02:37:12 GMT

This year @ TechEd I had the privilege of sharing the stage with Kevin Kline, Steve Jones, Buck Woody, and Allen White to discuss automating DBA tasks/processes. We discussed why automation is important and some of the technologies you can use to automate those tasks. Click here to launch the video. Or go to the TechEd Online Library where you will find it in WMV (Low & Hi), MP3 and MP4 formats.

Technology for the "Masses"

dtjones — Wed, 02 Jul 2008 19:14:19 GMT

I'm spending some vacation time with my family, my in-laws, and my wife's sister and her family. We're at my in-laws cabin in Clear Lake California. Clear Lake is a beautiful place with a interesting juxtaposition of multi-million dollar homes right near people living at the poverty line. I've been coming to Clear Lake with my wife since before she was my wife, almost twenty years. It's great here, blue skies, a big lake, and lots of good wine! I find that being here affords me the opportunity to clear my mind and let it wonder.

Over the past few days two interesting thoughts entered my mind. My father in-law just bought a previously-owned personal water craft from a guy up the street. Let's call him Hank. When we picked up the craft Hank invited us in for a beer, Miller High Life of course. Hank's a nice guy, he's in his 60's and a good guess says he's not married. Hank's house looks like it hasn't been redecorated since 1977. Thick brown shag carpet and wood paneling provide most of the character. I noticed about a dozen pocket watches sitting on his kitchen table. Hank goes around to garage and estate sales with a purpose of finding watches. It doesn't matter if they work or not, if he can get a good deal the sale is done. Hank has a friend, we'll call him Ed. Ed's in his 80's and was a watch repairman. None of Ed's children were interested in watches so he had no one to pass down the craft to. That is until Hank came along. Ed is teaching Hank how to fix watches. Some of the broken watches Hank buys are for repair parts for the ones that also don't work but are worth fixing. Out of the blue Hank mentioned he was not a technology guy. His impression is you have to spend too much time making sure the kids (for which I don't think he has any) aren't going to inappropriate places. My father-in-law proudly mentioned that I work for Microsoft, one of his sons works for IBM, his nephew works for Apple, and his other son works for a company contracted by Apple. The conversation didn't go anywhere, probably because Hank is not a technology guy.

This got me thinking though, what will we "technology guys" pass down? Our craft, unlike watch making, is constantly changing. We must continually revamp our skills lest we find ourselves obsolete. Working in an industry that's largely IP based with a skill set that must be remade every 3-5 years doesn't lend itself to passing down knowledge or a skill. I found this somewhat worrisome. I felt a little panic wash over me. What will I pass down to my kids or my grandchildren? This is something I'll likely ponder until I return to Clear Lake next year.

My in-laws don't have Internet access at the cabin. They do at their primary house just not at the cabin. Each morning I've been driving 10 minutes to Mary Lou's coffee shop in Lucerne with free Wi-Fi. The coffee shop has a computer sitting in the corner with a Linksys wireless router attached to it. The owner, Rob, mentioned the computer is his girl-friend's. He used to let people access their email from it but it got screwed up. So much so it cost him $250 to have someone come in and fix it (translated as re-install the OS). He was not happy about spending $250 to fix it. Now no one is allowed to touch the computer. It just sits there.

I get a medium (no Talls, Grandes, or Ventes here) Vanilla latte with nonfat milk. Tax included it comes to $3 even. It's a good coffee and is just what I need to get the engine started. I sit at a table on the patio that over looks the main highway. There's an interesting mix of people that come through the place. I sit next to the front door and great each patron with a "good morning". There's something refreshing about being friendly to strangers.

Yesterday one guy made a comment about me spending time in cyberspace. I hadn't heard that reference to the Internet in a long time. This got me thinking about what a different world we in technology live in. At Microsoft we often talk about building technology for the masses. Now I'm starting to believe there are more people in the world like Hank and the guy at the coffee shop than like us. This means we're building technology for the minority to benefit the majority. I like this characterization simply because I think it's purposeful to build something that benefits a tremendously large number of people in an indirect fashion; they won't spend a minute in their life thinking about it but it does change their life for the better.

As I was leaving the coffee shop yesterday morning the owner said I can come back any time and use the wireless. He said if he's closed to just sit on the patio - it's on all the time. You won't get that service at Starbuck's.

New Podcast for the Real-world DBA

dtjones — Sat, 01 Mar 2008 22:10:36 GMT

Buck Woody, a PM on my team, has launched a new weekly Podcast entitled "Real-World DBA". You can find out more information at his Blog. Here's a link to the first episode. I encourage you to take a listen and provide feedback. This is not a marketing driven Podcast!

Getting Your &amp;amp;quot;Favorite&amp;amp;quot; SQL Server Bug Fixed

dtjones — Sat, 12 Jan 2008 10:01:17 GMT

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.

MS Connect Feedback Part 2

dtjones — Fri, 06 Jul 2007 21:45:46 GMT

Thanks for the great comments. Great in that you took the time to provide them. Not great in what they say about Connect. I was surprised by the feedback - but maybe I shouldn't have been.

This prompted me take a very quick look at some SQL2K5 SP2 data. I'm reporting on the areas I own (Agent, DBMail, SQLCMD, SMO, part of Maintenance Plans, and part of Management Studio).

~9% of the bugs we fixed in SP2 were reported by customers through Connect (or the old MSDN site).

I'm satisfied with the 9% number. It could be higher but it's not bad. If we didn't have the Connect site this number would probably be less than 1%. I'd be happier with something closer to 15%. Why 15%? I don't have a good answer other than it "feels" like a better number than 9% and it feels reasonable.

Of all of the customer bugs closed but not fixed during SP2, 31% were closed as no repro. Other reasons for closure are by design, duplicate, external (meaning another team owns the issue), and won't fix.

The 31% number is an interesting number. I don't know if this is too high or too low. It would require more analysis to understand the details behind the number. I do know, based on the bugs I've triaged, many issues don't contain enough information to do a repro. When this happens we do one of two things: 1) leave the issue open for a period of time and request more information from the person who filed it. We then close it if we don't get a response or 2) Close it but ask the person to reopen it if they have more information. Our goal is to give people a chance to respond with more information.

I can't speak to the rest of SQL Server and the way their teams handle customer submitted bugs (in general I think SQL Server is very customer focused). For my team, we take everyone of them seriously and strive to have a meaningful dialog with the submitter. But you'd be amazed at the poor quality of some of the bugs submitted (you can probably do a search on Connect and find some of these). My advice is, if it's important to you and your going to spend the time to enter it, provide as much information and detail as you can. The more information and detail you provide the greater the probability we'll "get it" the first time we read the bug. The Repro steps are the most important. Make sure you can consistently repro the problem. If you can't then provide some data on how often you see it, is there a correlation to something else (e.g. It only happens when I have offline databases), etc.

Remember, if we can't repro it in house, we can't fix it.

Microsoft Connect Feedback

dtjones — Thu, 05 Jul 2007 17:48:08 GMT

Does the feedback mechanism on Microsoft Connect really work? By "work" I mean is customer feedback changing the product? From my perspective it's too early to make the call. In SQL2K5 SP2 we tried to address the top issues submitted through connect (based on the voting mechanism). I haven't run the analysis to see how successful we were - I should do that. Now we're in the middle of the dev cycle for SQL2K8 and I can tell you that feedback coming through Connect is playing a role in directing our work. This isn't to say that every item entered in Connect will be addressed, but it does mean your vote does count. After we ship SQL2K8 I'll go back and analyze the data to determine what percentage of all "bugs" fixed came through Connect.

Until then, keep posting your issues and voting active items.