In almost everything you do, you can think of two distinct parts of a process. Choosing what to do, and actually doing it. Mistakes of choice are where you chose to do the wrong thing. Mistakes of accident involve not following that choice.

Like a basketball player with the basketball. There are the right times to choose to shoot. For example if being defended closely by someone twice your height, that is the wrong time. But even if they are alone on the court, they still have to push that ball through the air into the hoop. My mistake will be firmly in the physical arena.

The recaps

Well, here we go, in reverse order that I got the alert from them. Sorry Rob Farley, you get to go last! (As I am doing my final edit, I must say it was a great choice because he tied it all together nicely.)

The funny thing is that most of these (including mine) include a line similar to: “You can probably guess what happened next.” If only we could have seen that just before we made our mistakes :).

Pat Wright

“You do not learn from success in life; you learn from failure.  I hope you are making lots of mistakes so that you can learn!” 

Pat’s mistake was when he was a newbie, and involved everyone’s favorite SQL Server topic “triggers” and that, while they fire on an update to a row (or more than one row), the statements in the trigger can affect any row in the database.

Key Lessons were that you should “Test Everything!” and that is a lesson we all learn the hard way at least once, and sometimes when we are “fixing something on the fly.” The other one I will highlight is to enjoy your time when you are new, and probably working at a small company. You can learn so much in typically lower pressure situations during those times.

I expect the last one: “learn from others” isn’t hard to grasp if you are reading this and other blogs.

Vlad Drumea

This was Vlad’s first T-SQL Tuesday contribution and Vlad’s mistake is one that is very common with DBAs making changes to important data in a tool like SQL Server Management Studio (SSMS). Executing code that starts out UPDATE Table and should have ended WHERE, but WHERE was nowhere to be found.

Luckily there was a backup and other ways to recover some of the data, but lessons learned here is to make sure there are backups available when making changes to important data, along with making sure that your scripts are safe as you write them.

Andy Brownsword

Andy’s shared mistake is one of mistakes of choice that can hurt so much. Choosing to use a value like a surrogate key/identity value to have meaning. And as is so true of most choices, the lesson learned is to do it the correct way.

A system generated value is good for identifying a row, but create specific columns if you want to use them for user ordering or searching.

Steve Jones

Steve’s mistake is the kind of mistake a lot of people make when working with an OUTER JOIN. Where to put filtering to make sure that it works.

The lesson learned is likely one of the more complex ones to implement, but at the same time, one that is really useful. Using an LLM to help you understand your statement, and a testing framework to create tests to make sure you are correct in your assumptions.

Deborah Melkin

Deborah (whose site it Deb the DBA :)), is one of the entries that came up with a fun title. “Bad mistakes, I’ve made a few.” Ok, Queen actually inspired the title, but still.

Deb recalls one of those annoying errors that you didn’t (and perhaps couldn’t) catch when you are doing your testing before you do a release. They had a multi-step process that was failing, and couldn’t diagnose how it was failing.

In the end, the thing they learned was to make sure and have logging tables for multi-step processes.

Note that there are several other blogs about mistakes and lessons learned linked in her reply,


Chad Callihan

Chad’s mistake was similar to one that I make too often. Too many copies of scripts floating around, and you end up using the wrong copy

The lesson learned here is something that a lot of us take for granted these days, keep all your code, even scripts, in some form of Source Control. Having (and using) the best version of scripts available when you need them is invaluable. Oh yeah, and don’t forget to get latest when you use that script!

Greg Moore

Greg, like Deborah Melkin, came up with an interesting title: “Why I Don’t Take CRaP from Anyone”. He also has a quote that is great too.

“We were young, fast, and nimble. And sometimes had no clue what we were doing.”

He had a few mistakes, one being very similar to Vlad Drumea’s with the lack of a WHERE clause on an UPDATE statement.

The second mistake was one of those big learning mistakes, using a UI to make changes to a server that didn’t have proper backups (also similar to Vlad’s example!). That lead to one of the best named documents ever: CRAP. Change, Review, Analysis, Plan. (The A was apparently dropped but no way you lose that acronym once it was established.)

The basics of that document was something everyone should realize. You don’t need to only plan not to make mistakes, but to know that, as Elvis Costello often croons, Accidents Will Happen. (I am pretty sure that song wasn’t about misplacing a clause in a SQL statement, but it was rattling around in my head as I typed the words.)

My Reply

Before I get to my last entry, let me do mine. The last entry makes such a great finale that it was too perfect not to leave it to then.

My mistake was very similar to a few of the others, but different. I had been working on a script to drop and recreate databases as I worked out issues pulling databases from source control. There were some dependency errors that I needed to work through, so it made sense to drop and recreate the database so I could document the process.

The mistake, well, I may have not been on the right server one time, because I had some other work to do on this other server earlier in the day. Needless to say that was not a good thing (it wasn’t production bad thankfully, but the database could not be restored without causing other people to get involved…from other departments).

So my process takeaway were to make sure and program extra-defensively when a script you run could do damage to a production server. Even if you are really really sure you wouldn’t do something that dumb, all it takes is once (and it is easy enough to include code to make sure of the server you are on when running destructive code. Plus make sure that any shared resource you work in has indicators in your tooling that you need to be extra careful. (A lot of my work is now done in various shades of red, from “be careful light red” to “be really really careful so you don’t have any more examples of mistakes to share crimson.”

And of course always be aware of your system context before you get really head’s down focused on solving a problem.

Rob Farley

Rob is a very good friend of mine, and he was the first person to post. (He is also in Australia where I believe it might have been Tuesday when it was still Sunday at my house…I have no idea how time works on the southern hemisphere.) I didn’t notice until now as I finish up this post that he titled his post: “Mistakes, Really Louis? :)”

To be fair I expected more of that sort of reply because I was concerned people might not want to divulge their lesser awesome times. And to be fair, I probably should have expected him to dredge up the fact that I had him confused with Arnie Rowland for quite a while (about the only they they share in common that I know of is that they are/were both amazing folks in the SQL community.)

I love this quote from his post:

“I’d rather learn through near misses. ‘Oh, that could’ve been bad, let me code up something so that doesn’t happen’ is a better experience than having to learn when a disaster has actually happened.”

I love the thought process here, but I also know that near misses never seem to quite have the same bite as an actual mistake for some reason (even though they really should!)

Rob doesn’t name any specific mistake other than the mistake of reliving our mistakes. Which is one of the biggest mistakes of all and something I am super glad Rob mentioned, I will mention again in a few paragraphs.

Thank you all for the replies

I think every one of these blogs I read understood the brief (except Rob and I am really glad of that!) Share a mistake and what you learned from it. Show the readers that you are human. As writers and speakers we regularly share the good things we do, but how often do we share the stupid things we do?

But my goal was not only to say we are writers and teachers who make mistakes, but to reinforce the fact that we learned something from those mistakes. If we are lucky we learn enough from mistakes when trying things in lab/dev/test environments, and we try as hard as we can not to make the same mistakes again by using everything from creating coded guard rails, and just slowing down and paying attention.

Listen to Rob’s advice too

Don’t wallow, dwell, obsess, or feel bad about past mistakes that you can move past. Sure, you are going to feel bad when you make a mistake that causes data loss or others to have to do work to clean up after your mistake.

But unless you have been warned not to make this same mistake again and again, take the lumps and learn something. Use that knowledge and make your processes better to protect yourself and your team in the future.

But do what you can to not relive them in a bad light or you will become timid. If you are better than you were when you made all of your mistakes, use the energy you spend reliving your mistakes and learn something new. It is far more valuable.