Hi Gail,

Thanks for your promptly answer.

I strongly agree with you about backup strategies, but as you also may have experienced many times in your career, a customer came to us with a damaged database and no backups available.

I've been working with SQL Server in the past 20 years and helped a lot of customers in different crash situations.

I was very explicit in my question, about two things:

* I'm talking about situations where everything else failed;

* I wasn't looking for warnings on risks (Yes, you're right: "Emergency mode repair is a last resort, it's not guaranteed to work, it should never be the first thing tried. " I knew that before asking and that's why I do thank you, but would like to reinforce that this kind of warning is not what I'm looking for).

About fixing metadata, I'm not discussing about the complexity of parsing the files and checking each page's content and I really don't want to go this way.

When I said simple logic, once you know the internal structures and have code to handle all that parsing, the high-level logic to accomplish that next step is simple.

Irreparable metadata is irreparable metadata, period. Again, I agree with you, but thank you !

Your database content may also have more reparable metadata, I would like to have a tool that continues after founding a critical error, because I agree to loose what is really IRREPARABLE.

A tool developed by one of the only "handful of people in the world capable of doing it though and it's extremely time consuming.", to make possible to repair a DB in some cases, such as damaged file or database header.

"In the case of a single row damaged in sysrscols, you would be able to query most of the database, only the table or index that is described by the damaged row would fail, so it would be possible, if tedious, to export all the other tables, possibly export some columns of the damaged table depending on indexes and then recreate the database. "

A software to do this tedious work for us.

If I can do it, or you can do it, then a software can be written to do it for us (remember that scripts shouldn't work in a smooth way, as SQL Server will disconnect your session, situations considered critical... so it's really, really tedious... But writing routines to connect, try to copy, reconnect and continue is not that complex.)

Right now, I want to pay for it, if someone else already spent time on that.

"Every time I've seen errors around the size of the file, it's been that the metadata is correct and the file has been truncated on disk. "

Maybe everytime you've seen errors around size of the file, the metadata was correct, but sometimes it's the opposite...

But even if you're completely right the user or the customer may agree to loose everything that was allocated after that point and save everything else.

Again, if someone would like to help, please answer what I'm asking for, I will really appreciate.

I'm not looking for miracles, neither for hot discussions on what is possible or not, what is the best practice or not, I know what is possible and what is not possible and also the best-practices.

I want to just receive answers from people who have actually used 3rd party recovery tools and the pros and cons they have experienced with this or that specific tool.

Internet is already full of discussions on what should be made before the problem happens and about what the books on-line states.

Please don't polute this thread with this kind of useless discussion.

Hex-Editors are good (as a last of last, last, last... resort, ok! everyone agrees, thank you!), someone knows good plug-ins able to parse MDF, NDF and LDF files ?

That kind of last resort, unsupported situations happens, unfortunatelly they are real and we need to provide full or partial solutions.

Right now, I have another customer on that situation and I'm looking for alternatives.

Answers strictly related to my questions are welcome.