Michael: "I must've put a decimal point in the wrong place or something. ----, I always do that. I always mess up some mundane detail."

Peter: "Oh! Well, this is not a mundane detail, Michael!"

Michael: "Hey, quit getting pissed at me. Alright? This was all your idea, ---hole!"

Peter: "Alright, okay, alright, let's try not to get pissed off at each other. Alright? Let's just calm down, let's try to figure this thing out together."

Pretty sure you can say "fuck" and "asshole" on the Internet.

Pretty sure I don't care to do that.

Anyway, downvoters, the quotes were an actual answer. It was probably some very minor detail that escaped notice until downstream effects (low price cap) made it evident. Without more information it's a waste of time to try guessing what that minor detail may have been.

An UPDATE sql statement with a forgotten WHERE clause

It does annoy me that the WHERE clause has to go at the end. I usually end up typing the WHERE clause first when working live on something important.

Same with rm -Rf /foo/bar. There's a moment when pressing enter will do the wrong thing. I usually use relative paths to avoid this, but I have had to repair the damage for someone who actually managed to rm -Rf / by accident due to this.

That is why I run a ls command before doing rm. (been bitten but accidentally hitting Return key instead of Shift on laptop :()

Also for Update/Delete query I run the equivalent select (rows or count(*) ) query first, just to make sure.

also make sure to write where predicate before completing the whole sql. (The sql does not go through by accidentally hitting enter, before the whole statement is written)

tl;dr - Run read operation before doing write/update/delete operations.

Doubt it, I'm really careful with updates and usually I only have a few hours work between me and fixing a mistake like that, not a million dollars. Maybe a certain discount was applying to everything, more likely that every actual price being changed in the db.

Wild guess would be they were using price limits to categorize. In other words, using "under $50" for various product or promotional listings.

It's hard to imagine how that would end up repricing items though. Without a total blanking out moment in the programmer's head, anyway, which I'm sure we've all been guilty of.

I really don't wanna be that developer or DBA whose lack of attention caused this. I work for an online retailer and obviously we live in fear of self-inflicted downtime. (That said, no business likes downtime)

Something along the lines of this, abstracted away a few layers, would be my guess.

    def build_query()
      "UPDATE prices SET price=4995 #{where_clause}"
    end
    def where_clause() # only set prices on products in our group of stuff to sell
      return "oops, I'm accidentally an empty string"
    end

Unfortunate bug causes method to fail silently, program does not crash, instead performs unfortunately incorrect query.

Perhaps they meant to cap prices at 5 thousand dollars but it turned out to be 5 thousand cents instead?

Excellent job, you've satisfied the narrow confines of the literal request while offering no insight into the actual thought processes or features that might lead to the bug.

And surprisingly, this is exactly how most bugs happen.