My biggest dev blunder. I haven't told a single soul about this, until now.


So, I was working as a full stack dev at a small consulting company. By this time I had about 3 years of experience and started to get pretty comfortable with my tools and the systems I worked with.

I was the person in charge of a system dealing with interactions between people in different roles. Some of this data could be sensitive in nature and users had a legal right to have data permanently removed from our system. In this case it meant remoting into the production database server and manually issuing DELETE statements against the db. Ugh.

As soon as my brain finishes processing the request to venture into that binary minefield and perform rocket surgery on that cursed database my sympathetic nervous system goes into high alert, palms sweaty. Mom's spaghetti.

Alright. Let's do this the safe way. I write the statements needed and do a test run on my machine. Works like a charm 😎

Time to get this over with. I remote into the server. I paste the code into Microsoft SQL Server Management Studio. I read through the code again and again and again. It's solid. I hit run.


Wait. I ran it?


With the IDs from my local run?


I stare at the confirmation message: "Nice job dude, you just deleted some stuff. Cool. See ya. - Your old pal SQL Server".

What did I just delete? What ramifications will this have? Am I sweating? My life is over. Fuck! Think, think, think.

You're a professional. Handle it like one, goddammit.

I think about doing a rollback but the server dudes are even more incompetent than me and we'd lose all the transactions that occurred after my little slip. No, that won't fly.

I do the only sensible thing: I run the statements again with the correct IDs, disconnect my remote session, and BOTTLE THAT SHIT UP FOREVER.

I tell no one. The next few days I await some kind of bug report or maybe a SWAT team. Days pass. Nothing. My anxiety slowly dissipates. That fateful day fades into oblivion and I feel confident my secret will die with me. Cool ¯\_(ツ)_/¯

  • 16
    A newb question, but when I was learning SQL with mysql, I always ran the SQL, checked the results, and only then I committed it. Is this not the case with MS-SQL?
  • 17
    @piehole That's the smart thing to do! Commits are implicit in SQL Server Management Studio, so all executed statements are committed automatically. I could have used an explicit transaction and checked the results. The error was staring me in the face the whole time though :/
  • 16
    Ouch ouch ouch.

    I would have gotten the data from a backup and re-inserted it. But it sounds like the data ended up not being necessary. Lucky!
  • 13
    Hehe, I think more devs have done this then they would care to admit 😉

    Anyhow, when dealing with delete (and not using transactions) i would always run SELECT counter part of DELETE statement I'm about to run. That way you see exactly what data is being deleted and it has no side effects. Saved my ass more than once where I forgot to add "WHERE id = xyz" 🙄
  • 2
    @LordPeeve Yeah, that's an awesome trick! A colleague of mine was going to update an order row and - yep - forgot the WHERE clause. That's one way to get all the orders delivered, haha. Db needed a restore after that incident. For a junior dev that was really memorable, that's when I learned the SELECT trick. I'm not sure why that didn't save my ass that day.

    Nowadays I would have set up an identical scenario and do test runs on that or make the necessary transformations automated. Manual processes inevitably lead to human errors, that's for sure.
  • 3
    @Root That would have been the mature thing to do 🙄 It was mostly me being afraid to admit my error (I'm a recovering perfectionist, heh) plus a sprinkle of not wanting to deal with the database admins. I didn't know that inserting part of the data was possible, but had I tried solving the problem for real I'm sure a colleague or Google would have told me that it was an valid option.
  • 4
    @ihatecomputers well I've changed everyone's password to the same in a payroll/hr system. Smh...had to secretly restore what I could from day before and then just let the system take the blame for those that fall through the cracks 😂.

    Not because I didn't put a where clause or check it with a select first, it was all written perfectly....Then I highlighted everything but the where clause fml.

    This was when I had been learning SQL like 2 months, no one found out tho, I'm used to covering up fuck ups 😎
  • 3
    @CodeBane lmao, you sneaky bastard 😏
  • 3
    SQLserver has temporal tables now that work like oracles flashback query and that has got us out the shit on more than one occasion
  • 2
    "and I feel confident my secret will die with me." well, not anymore...
  • 4
    That Eminem reference, though! 👌
  • 0
    @gruff we used to create our own trigger and insert every changes into an audit table. It works like a charm 🍌
Add Comment