Blog Post

Work requests: It’s broke. Fix it.

,

Many years ago I was given a work request that literally just said:

It’s broke. Fix it.

I’m sure you can see how that is supremely unhelpful. And this isn’t the only time I’ve gotten such great requests.

I need full access.

Please run this script.

(I’ve even gotten this one without an attached script.)

Job abcdef failed.

Now, because a post that does nothing but complain is equally unhelpful here are a few things you should always include in a request to a DBA.

  • What do you need? In detail please.
  • The SQL Server instance. And the actual name, not some random alias that your team uses. If there is more than one give me a list.
  • Database(s). Same thing as above. I don’t necessarily know what database you are working with today.
  • If it’s not going to be dbo then I need to know what schema(s) you are working with.
  • If you want access then I need to know what access you need. In detail. Read, Write, Create Objects, etc. And if you just put admin and no details as to why then the answer is just No. Give me details.
  • If I’m running a script then make sure the script is available. Make sure you tell me what instances/databases to run it under. I’m aware that some scripts are going to have a USE statement at the top. If so, and it doesn’t match what you tell me here then be prepared for questions.
  • If there is an error then I need the actual error not your interpretation of it. Believe it or not I’ve seen a SQL Server error where the easiest way to track down what’s going on is because of the typo in the error. A screen shot will work but I’d prefer the text.

I should point out that my company has thousands of instances. If your company only has one instance and one database then you may not need all of this, but until you know otherwise, this is a good starting point.

On my end of things I’ve started making notes on the request as I finish them. I used to put in:

Request Complete

Or something like that. Which is also pretty useless as these things go. I’ve started doing something like this:

Output for scriptfile.sql on InstanceName.Database

(1 row affected)

(1 row affected)

Completion time: 2021-07-30T19:19:30.7623730-05:00

This way I have proof that the request was completed, when it was complete, what file I ran, what instance I ran them on, etc. This comes in really handy when I’m using the same request to hit test, model, and prod instances since I at least know what I did last.

I’m guessing this is going to fit most IT requests but I’m equally sure I’m going to have missed things. Feel free to add anything I’ve missed in the comments.

On a related note here is a great link on what you need to include in a forum question to help people answer your question more easily.

As I’m sure you can tell, the moral of this story is when asking for something, be specific, be detailed. Even if it seems obvious to you the person receiving your request is probably not on your team so what you think is obvious they may not. I mean while you may only work on 2 or 3 applications, they may be supporting the developers for dozens of teams, each with their own 2 or 3 applications, each with their own database(s), each with their own SDLC stack.

Original post (opens in new tab)
View comments in original post (opens in new tab)

Rate

5 (2)

Share

Share

Rate

5 (2)