tags:

views:

132

answers:

5

Hi,

I have made an update statement in a table in SQL 2008 which updated the table with some wrong data.

I didn't have a backup for the DB.

It's some important dates which got updated.

Is there anyway where i can recover the old data from the table.

Thanks

SNA

+5  A: 

Basically no unless you want to use a commercial log reader and try go through it with a fine tooth comb. No backup of the database can be an 'update resume, leave town' scenario - harsh but it just should not happen.

Andrew
don't forget the where clause or you might update *everybody's* resume :O
David Hedlund
+4  A: 

Andrew basically has called it. I just want to add a few ideas you can consider if you are desperate:

  1. Are there any reports or printouts lying around? Perhaps you can reconstruct the data from there.
  2. Was this data entered via a web application? If so, there is a remote chance you can find the original data in the web server logs, depending upon how the app was constructed, etc.
  3. Does this app interface (pass data to) any other applications? They may have a buffered copy of data...
  4. Can the data be derived from any other existing data? Is there an audit log table, or another date in your schema based on this one, from which you can reconstruct the original date?

Edit:

Some commenters are mentioning that is is a good idea to test your update/delete statements before running them. For this to become habit, it helps if you have an easy method. I usually create my DELETE statements like this:

--delete --select * 
from [User]
where UserID=27

To run the select in order to test your query, highlight everything from select onwards. To then run the delete if you are satisfied with the filter criteria, highlight everything from delete onwards. The two dashes in front of delete are so that if the query accidentally gets run, it will just crash due to invalid syntax.

You can use a similar construct for UPDATE statements, although it is not quite as clean.

RedFilter
+1 for using the -- comment tag in sql. This is embedded in my dna.
Chris Lively
A: 

Always take a backup before major UPDATE statements, even if it's not used, there's the peace of mind

Especially with Red Gate's Object Level Restore, one can restore individual table/row now given a backup file

Good luck, I'd suggest finding an old copy elsewhere (DEV/QA) etc...

jerryhung
A: 

Isn't it possible to do a rollback on an UPDATE statement?

sheepsimulator
Only if you were within a transaction and had not committed it.
Andrew
Ie, so he probably didn't? I guess this is a chalk-it-up-to-experience item. Most of the DB guys I used to talk to always wrapped up all admin/maintenance operations in a txn.
sheepsimulator
Perhaps another valid point from "Andrew", always begin update st't with a transaction and verify it, commit it.
Guru
+1  A: 

Thanks for all the responses.

The problem was actually accidentally ---i missed to select the where condition in the update statement.---Rest !.

It was a quick 5 minutes task --Like just changing the date to test for one customer data--so we didn't think of taking a backup.

Yes of course you are true ..This is a lesson.

Now onwards i will be careful to write "my update statements in a transaction." or "test my update statements"

Thanks once again--for spending your time to give some insight rather ignoring the question since the only answer is "NO".

Thanks

SNA

swapna
+1. For accepting the mistake and learning the lesson. Also, the DB here is of some constraint. If it is Oracle, you can use FLASHBACK option which will work just fine.
Guru