In SQL Server Management Studio, I did the query below.
Unfortunately, I forgot to uncomment the WHERE
clause.
1647 rows were updated instead of 4.
Since you have a FULL backup, you can restore the backup to a different server as a database of the same name or to the same server with a different name.
Then you can just review the contents pre-update and write a SQL script to do the update.
If you already have a full backup from your database, fortunately, you have an option in SQL Management Studio. In this case, you can use the following steps:
Right click on database -> Tasks -> Restore -> Database.
In General tab, click on Timeline -> select Specific date and time option.
Move the timeline slider to before update command time -> click OK.
In the destination database name, type a new name.
In the Files tab, check in Reallocate all files to folder and then select a new path to save your recovered database.
In the options tab, check in Overwrite ... and remove Take tail-log... check option.
Finally, click on OK and wait until the recovery process is over.
I have used this method myself in an operational database and it was very useful.
Considering that you already have a full backup I’d just restore that backup into separate database and migrate the data from there.
If your data has changed after the latest backup then what you recover all data that way but you can try to recover that by reading transaction log.
If your database was in full recovery mode than transaction log has enough details to recover updates to your data after the latest backup.
You might want to try with DBCC LOG, fn_log functions or with third party log reader such as ApexSQL Log
Unfortunately there is no easy way to read transaction log because MS doesn’t provide documentation for this and stores the data in its proprietary format.
If you can catch this in time and you don't have the ability to ROLLBACK
or use the transaction log, you can take a backup immediately and use a tool like Redgate's SQL Data Compare to generate a script to "restore" the affected data. This worked like a charm for me. :)
A non-committed transaction can be reverted by issuing the command ROLLBACK
But if you are running in auto-commit mode there is nothing you can do....