The First Annual Scary, Spooky SQL Stories Contest

Welcome to my first annual "Scary, Spooky SQL Stories" contest. My kids are getting excited about Halloween and having fun telling ghost stories. It occurred to me that although we don't have to worry about ghosts, ghouls, and other unspeakable monsters, we all have truly horrible and frightening stories from work that we can tell around the proverbial campfire. I remember back to one of my earliest jobs when I was playing the role of the "development team DBA" and needed to recover a very important backup when the developers realized that they had somehow corrupted the integrity of the code base for an incredibly important project. Fortunately, the development team said it would be easy to fix because everyone agreed that "X weeks ago" there was a known clean baseline and all the developers had the ability to make the changes to their sections of code that had been made over the last few weeks. I strolled down to where the operations team hung out, explained what I needed, and the administrators looked at each other and said "he backs up that server." They all got a pretty scary look on their face. I've been in the database space for 17 years now and, needless to say, I've heard and seen tales that would strike fear in the heart of the most fiendish beasts that your imagination can conjure up.

I thought it would be fun to invite our readers to submit their best scary, spooky SQL Server stories. I'll pick a few winners using a completely arbitrary, non-scientific, and non-auditable set of parameters that I haven't quite decided on. These stories shouldn't be Sarbanes-Oxley (SOX) compliant. I'll award points for the most outlandish stories, but please keep them true. I can't promise a prize, but I'll see if I can finagle something fun from "SQL Server Magazine." Here's one more rule. Don't send me a story unless you're OK with me printing it. I won't print the name of anyone who submits an entry, and I reserve the right to redact portions of your entry (e.g., specific company names, names of colleagues, or truly identifying information about the company or person) if I feel that printing "as is" could get the magazine or me sued. That would be way too scary for me.

I hope this exercise will produce some fun reading, but there's a sneaky educational component hidden in this otherwise tabloid sensationalism. I started talking about "worst practices" a long time ago. My thinking is that there are so many best practices that it's easy to ignore many of them, and a case can be made that missing a best practice here and there isn't the end of the world if the omission doesn't cause material or noticeable problems. Worst practices are the mistakes that you really don't want to make, such as my scary, spooky SQL Server story. The administrators I referenced in my story probably missed a few best practices throughout the remainder of their careers, but I suspect they never again committed the worst practice of assuming their coworker was backing up a server. It's more fun to tell scary stories than live them, right? So, let's have fun telling some hair-raising stories, and hope that we can keep them from becoming real for someone else.

I wish I had thought of this contest a few weeks ago. I'll be better prepared next year if readers seem to enjoy our fiendish fun. Please send me your scary, spooky SQL Server stories ASAP. I'll print some of the best ones the week after Halloween, and I'll keep the submission deadline open until November 8. I'll award the prizes shortly thereafter.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.