Just rollback the transaction. Wait, you were running under a transaction right...
Transactions are for people that make mistakes.
Dropping 250,000 rows from a production database and having to call the senior after hours, in tears, is a right-of-passage that everyone goes through. Right? ...right?
Tables? TABLES?
The ol' forgotten 'WHERE', I know it well. Gonna find out a lot about the Backup strategy. First of all if there is one.
I call this the unplanned disaster recovery drill.
I did that before. Logged in as read only access. 80k rows updated... Uhhh shit what? Run an update script to change admin accounts email address, it runs. Change it back. So the read only access was actually full access for some reason on that server. I don't know, I don't have permission to setup the accounts.
Still don't know what those records were that got updated. It was a massive stored procedure that I had never seen before and wanted to test chunks of it. We may never know. To this day that customer often comes up with obscure issues.
One time I made a bulk change (thousands of records) and each and every one sent at email to the record owner. That was fun.
In fairness, that sort of trigger is a horrible half-assed solution that should never have been implemented. No blame at your feet (unless you put it in place).
Oh it was all me start to finish.
