There is no tool that can detect whether a transaction log backup contains log records that include corrupt data (e.g. an update of an already corrupt value). There are methods...

Your database is corrupt and cannot be repaired (DBCC CHECKDB won't run, so you can't run repair). I just demo'd these errors at TechEd in June.

Given that you have no...

Excuse me? Why should I change my picture?

The answer is 'it depends'. See the following for a full explanation:

http://www.sqlskills.com/blogs/paul/2007/11/15/CHECKDBFromEveryAngleHowLongWillCHECKDBTakeToRun.aspx

It will take at least as long as your CHECKDB usually takes without specifying repair. Why are you running...

Nope - as I said before, you need to re-setup replication as you've completely broken it by taking the publication database back in time. No-one will tell you any different.

Thanks

PS...

You've taken the publication database back in time and so the subscribers are further ahead. The Log Reader Agent is confused because suddenly the log records it is reading are...

PSS won't be able to do anything different.

One of the steps of emergency mode repair is to try forcing recovery with the equivalent of WITH CONTINUE_AFTER_ERROR - looks like in...

These errors look like they should be fixable, but without poking about in the database I can't tell why they're not being fixed. There are about 200 pages that look...

Did you manage to put the database into single-user mode?

If you did, there must be an unrepairable error somewhere in the list of errors - as the errors you've listed...

If you're really motivated, and you don't have a backup, this will be a long and tedious process. You need to analyze the full set of error messages that DBCC...

Btw - before running repair you should always take a backup - just in case something goes wrong - you'll at least have the corrupt database to fall back on.

Looks like you have a corrupt page (and CRC indicates hardware problems) in a leaf-level page of the clustered index of your table. The data on the page has been...

And how did it get detached?

Ah - oops - thought I'd blogged about re-attaching a suspect database. That'll be today or tomorrow.

Your main db is gone completely and unrecoverable.

For the audit databases, first thing is...

If you do find the deleted MDF you're going to have to hack it back into SQL Server as there's no way to get it to attach properly. See this...