When troubleshooting a problem, it's important to ask the right questions

Know what you should ask users before troubleshooting -- it'll save you a lot of time

This is going to be kind of short, and I'll extend it a bit later, but I just wanted to get this down now while I'm thinking about it.

I recently had a junior DBA working on a database access issue with a user, and he had problems discovering the problem. I would have solved it for him, but I like to give people the room to discover things on their own.

[ Keep up on the day's tech news headlines with InfoWorld's Today's Headlines: First Look newsletter and InfoWorld Daily podcast. ]

After a couple days, when he came to me for advice, I asked him what he'd done already. It all boiled down to the fact that he had been floundering around in the middle of the problem instead of working his way through it.

I've said this time and time again, and I'll say it yet again: When you're troubleshooting a problem, start at one end of the scenario and work your way to the other end.

This is very important because it keeps you from forgetting little things, and it cuts your time tremendously because you eliminate things in a logical fashion.

I'm not going to get into all that today as much as I'm going to give you some initial questions to ask your user before you start digging into the problem. These are things you need to know before you begin, and I'll get into the rest of the stuff later. I'm making a flowchart for troubleshooting access; I hope to maybe have it finished by the end of the week.

But here are the questions you need to ask your users when they come to you with access problems. This is mainly for the database, but I suppose it works for any access-type issue:

  1. Have you connected to this server before?
  2. Are you connecting from home or the office?
  3. Have you connected from this location before?
  4. When was the last time you connected from this location?
  5. Are you connecting to the same database you always connect to?
  6. Are you using the same client you always do?
  7. Are you using Windows or SQL auth?
  8. Can others around you connect?
  9. Has anything changed on your box since the last time you connected? For example, do you have a new version of a client or have you reverted to an older version?

Depending on the answers to these questions, you'll start your investigation at the appropriate place. If they can get to DB1 but not DB2, there's no reason to troubleshoot firewall or other network issues. You know that the problem lies in database access on the server. In the same way, if they've never connected before and you know there's a process for getting access, then they're probably not even set up in the database, so there's nothing to troubleshoot. The process is working as it should.

This actually happened to me a while back, and it's the main reason for this post. A user contacted me and said he couldn't get to the DW, so I asked him my questions. He said that he had never connected before, but the guy that sits by him connects all the time, so he just wanted to get in and poke around to see what was there. Um, no dude. But you see I saved myself quite a bit of effort up front by establishing right away that he wasn't supposed to have access and that's why he couldn't connect.

And that's what I'm really talking about here. Make it easy on everyone and learn to ask the right questions up front so that you know what you're dealing with before you even start.

I'll get that flowchart done soon, and I'm working on a video for this. I'll let you know when that's done too.


Copyright © 2009 IDG Communications, Inc.

How to choose a low-code development platform