Recent Articles:

From the Vault: TRY, CATCH, and Transactions

June 23, 2014 sql server 1 Comment

I’ll be in France and largely AFK for a few weeks this summer, so I’m posting some golden oldies. You can find the original article and comments here.

Src: T-SQL TRY/CATCH structure (“new” in SQL 2005!) is, as the professionals say, da bomb. It’s also underused and under-understood, so let’s talk about the basics. (Or, you can skip to the summary at the end.)

A group of Transact-SQL statements can be enclosed in a TRY block. If an error occurs in the TRY block, control is passed to another group of statements that is enclosed in a CATCH block. – MSDN, “TRY…CATCH (Transact-SQL)

… Continue Reading

From the Vault: The First Interview: What companies do that make me want to run far, far away

June 16, 2014 sql server No Comments

I’ll be in France and largely AFK for a few weeks this summer, so I’m posting some golden oldies. You can find the original article and comments here. 

I’ve recently been asked for some clarification about this statement (from my last blog post): “This is EXACTLY the kind of job I’m NOT looking for.”  Inquiring minds want to know: What turns you – meaning me – off of a job, especially in the first interview?

First, it’s important to understand that everyone will have their own turnoffs. I’m happy to list mine, but mine aren’t necessarily red flags for everyone. They’re just things I dislike.  But you know, generally speaking, I have pretty solid reasons for disliking these things.


These days, and if I’m looking for a long-term position, I don’t want to hire into a  place that’s dysfunctional, and/or badly in need of processes.  If you have an IT shop and you don’t have solid, documented, known, and followed processes for customer support, internal support, development, change control, quality assurance, and so on, you have a deeply ineffective IT team.  This kind of thing is generally very easy to find out in an interview, with a few questions and an experienced ear.

I can no longer stand to own a big piece of responsibility in a shop that will do nothing but work against me (while tendering all the lip service to project life-cycles and development methodologies).  It shouldn’t be the DBA’s job to set the entire IT shop on the road to solid development and support; we have the need, but we don’t have the authority or backing.

Red flags: Anything “Agile”, where they can’t explain exactly what “Agile” means beyond “flexible development processes” and “daily scrums”. I got that much off of Wikipedia, pal…it doesn’t make you an Agile shop.  Also, sideways looks when you ask about documentation, testing, code reviews, security, and that sort of thing.

The “exception”: I’m not saying a shop has to have every single duck in a row, and a perfect SQL setup. In fact, a very common scenario is the small shop that simply outgrows its IT staff.  In the beginning, they have one or two guys that can do everything, and that’s fine. After all, DBAs are expensive!  After a certain amount of growth, the shop realizes it has to get a pro in to see to the databases.   Or, it’s a big shop that thought it had a good DBA, or it had a DBA that slipped up, or was just midlevel. All of these places may have problems with the SQL Server side, but that doesn’t mean your entire org has to be slipshod and process-free.

Lame Interview

This isn’t as big of a deal, but I must say that I’m far more impressed by people that know how to interview well – or at least people who are excited about technology – than otherwise.  I’d really like to work with people that know what they’re doing. If you can’t be bothered to interview well – even if you don’t know my technology well – I may come to work with you, but I’ll be inclined to think more highly of myself than of you.

While it is flattering to go into an interview and skate by on my reputation as a speaker and an MVP, I don’t necessarily want to leave an interview feeling flattered. I’d like to leave feeling challenged and excited. Call me crazy.


A place that requires a certain mode of dress, strict 8 to 5 hours, no remote work, and other signs of formality will generally display other undesirable characteristics.  These don’t JUST show up at formal places, but a formal place will USUALLY have one or more of these issues:

  • Inflexibility – These are not the guys that will support your SQL Saturday habit. They’re certainly not interested in your work-life balance, and will often insist that you show up at 8am Monday after 17 hours of production work over the weekend.
  • Technology Superstition – “We can’t enable SQL Mail – there’s no telling what it will do to the system!!”  Ask me if I’m kidding about that one.  Prove that a thing is safe/good/industry wide best practice to these people, and they’ll still refuse because they have a bad feeling about it. Again, I’m not kidding.
  • Political Entrenchment – Oddly, this one shows up under the covers at extremely casual places, too. Maybe it’s everywhere, I don’t know, but it’s certainly prevalent at formal places. You WILL eventually have to circumvent or live with some absolutely idiotic technology non-decision because some business major upper-brassman puts in his or her two cents, and then cement them to the systems.

 A word more…

There are certainly other things that are a turnoff in the interview, but I think we’ve covered some good ground today.

Also understand that right now I’m pretty much in love with short-term contracts, and that’s a whole other ball of wax. I come in, I fix things, I set up sustainable processes, and I ride off into the sunset…it’s fun to be a cowgirl.  For these interviews, all bets are off!  If your shop is dysfunctional, not that knowledgeable, or extremely formal, it’s fine…after all, I’m there to fix as many problems as you like, and at the end of the day I don’t own the processes.

It’s the difference between being a parent, and being a babysitter.  The parent has to think very long-term about the kids’ development, about their continuing relationship, and also deal with the constant responsibility. There are huge paybacks, of course – you absolutely can’t put a price on having kids! But I guarantee you that the babysitter has way less stress, and can often be more effective with less effort simply because of the difference in his/her position.

Plus, contractors and babysitters are paid by the hour.

Happy days,
Jen McCown

Have SQL Server issues? Like the cut of my gib? Email me at and let’s talk about your consultant needs.


June 9, 2014 sql server No Comments

I’ll be in France and largely AFK for a few weeks this summer, so I’m posting some golden oldies. You can find the original article and comments here

As we’ve seen in recent DBARant-able tales, not everyone is completely familiar with methods of restoring SQL backup files to new filepaths. The answer, in short, is: RESTORE FILELISTONLY/ RESTORE WITH MOVE.

Let’s say that you backed up the database ImportantDB from your production server, and you want to restore it to a test server. The only problem is, the data and log files on prod reside on the D: and E: drives , while the test box doesn’t HAVE D: and E: drives…only F: and G: drives.  Here’s what you do:

  • Use RESTORE FILELISTONLY to get the logical names of the data files in the backup. This is especially useful when you’re working with an unfamiliar backup file.

FROM DISK = \\srv1\sql\ImportantDB.bak’

  • Use RESTORE WITH MOVE to move and/or rename database files to a new path.

FROM DISK = \\srv1\sql\ImportantDB.bak’
WITH MOVE ‘ImportantDB’ TO ‘F:\SQL\ImportantDB.mdf’,
MOVE ‘ImportantDB_log’ TO ‘G:\SQL\ImportantDB_log.LDF’

As they say on TV, it’s just that easy.

And yes, I realize that I wrote about this last year…but I’m gonna take the hit on this one. It’s useful, it’s important, and it’s overlooked.

Happy days,

Jen McCown

MidnightSQL Consulting

Need help? Got an emergency? Write us at!

We can schedule time to help with your backup/restore issues, high availability and disaster recovery setup, performance problems, and a great deal more. Very often, we're even available on the moment for downtime issues and emergencies.

For more information about MidnightSQL consulting, email us or check out Happy days!

Where are We?

Blog Posts by Category


How to Eat Pop-tarts
Watch DBAs@Midnight live on Fridays,m 11pm Central time

The best database career advice you’ve never heard!

The DBA Roadmap Seminar is 7 MP3 tracks (over 5 hours!) of insider guidance on your database career. We'll teach you how and what to study as a DBA, weigh in on controversial resume debates, teach you to recognize a worthy recruiter, and discuss the new professionalism of interviews. Also some bonus materials, PDF companion guides, and really spiffy intro music!

Once your $99 PayPal payment is submitted, you'll get the download link in e-mail! (Download is a 370Mb ZIP file.)

Become a DBA. Become a BETTER DBA. Use the Roadmap.

Visit for info, forums, and more!

Add to Cart View Cart

Cunningham’s Law

"The best way to get the right answer on the Internet is not to ask a question, it's to post the wrong answer."