Hi,
I have a corrupt mdf file.
Error: 824, Severity: 24, State: 2.
The corrupt page is (1:1149)
DBCC CheckDB ('MyDb', REPAIR_ALLOW_DATA_LOSS) couldn't fix it. I tried all possible options.
The db is not in production but it is fully operational, despite the corrupt page.
I ran DBCC CheckTable on all the tables and identified the culprit table. It is an insignificant helper table with no important data and no dependencies on it. That is why the error has lasted for a while and propagated into the backup too. So I have no
clean backup to restore from.
I just upgraded to SS2012 Express and the db could not upgrade beyond version 691, then the mdf file size swelled from 40MB to over 1GB. and kept appearing as recovery pending in SSMS object explorer. After 24h I gave up and re-attached a backed up copy to the 2008 R2 environment on another machine and tried to export the v665 db and then upgrade the version to v706 - no go;
I could not script the entire db to migrate it. It throws an error at the preliminary enumeration of objects to be scripted. Even if I skip the culprit table by unchecking it, the scripting utility goes through the same list of table objects and chokes anyway when it hits the bad page. I did manage to script out all views, udf, and usp objects - all but the tables. Funny, I can script out in SSMS all tables but the culprit one, but the scripting wizard iterates the list of objects and fails no matter which tables I have selected good, bad or any combination thereof.
SELECT INTO across all tables is not a good option as it does not migrate keys, indexes, constraints, calculated columns etc.
I tried the demo of Stellar Phoenix mdf recovery tool which previewed the mdf file just fine, but so does SSMS. So does the client app too with no probs except when querying the bad table (Since the table was legacy I had to write code to query it - no surprise there, it is bad for sure).
What I need is a way to "copy" the good tables and data w/out the bad table into a new db and then migrate it. I am trying not to do all this scripting work table by table over hundreds of tables. Is there a better way?
Working with SMO may be a way to skip the bad object in a try-catch but it seems almost as much work as to script the SQL stmts.
Please help.
Thanks