You can restore from a backup to another location, then move just that table from the restore back to your primary server. It sounds like SQL Server 2005 has a really nice feature to selectively restore tables which sounds really cool. (As I've been in the same situation before when a senior developer deleted half of the data in our primary patient table thinking he was in the test environment.)
Uh, isn't this dangerous? I know from DB/2 that they have things like 'on delete cascade' and though I don't know it I'd guess that SQL Server has something alike. So if one restores a single table I'd expect that one might lose data integrity. Wouldn't it be better (safer) to restore and roll forward?
If the table has not relations, you can restore from backup. Luis Martin Moderator SQL-Server-Performance.com One of the symptoms of an approaching nervous breakdown is the belief that one's work is terribly important Bertrand Russell All postings are provided “AS IS†with no warranties for accuracy.
I think tools like Log Explorer have also the ability to recover dropped tables. That of course implies, that they need to be installed on the system before the DROP happens. They are pretty much useless after the fact has occured. This might also be a good moment to think about your security and disaster recovery strategy. SQL Server also implements referential integrity, for example, via ON DELETE CASCADE. So, if you restore from a backup in a heavily used system, I would suspect you manually need to look for data integrity issues that are likely to be there. -- Frank Kalis Microsoft SQL Server MVP http://www.insidesql.de Heute schon gebloggt?http://www.insidesql.de/blogs Ich unterstütze PASS Deutschland e.V. http://www.sqlpass.de)
If you think the data of particular table is more important then you can write Trigger so that the deleted records are stored in some audit tables Madhivanan Failing to plan is Planning to fail