Work requests: It’s broke. Fix it.


August 12, 2021 by Kenneth Fisher

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.

4 thoughts on “Work requests: It’s broke. Fix it.

  1. paschott says:

    I get quite a few of those “need access to this database” (followed by just giving me a server name, if that). However when the ticket is done, I’ll admit to just putting in “access granted” or “request complete” after adding whatever detail is appropriate – mostly because it’s already in the ticket. I’ll include more detail where it’s warranted – like if there were some warning/exception along the way. Most times the users don’t care all that much. 🙂

  2. […] done more than a few rants in my time blogging. One more should be a piece of cake. Interestingly the day I read the […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 3,755 other subscribers

Follow me on Twitter

ToadWorld Pro of the Month November 2013
%d bloggers like this: