We had a fun internal debate this week on a new tool developed in France. If you can read French, it’s documented here; the download link for the executable (whose UI is in English) is here. The tool grabs deleted documents from the database and saves them to your local hard drive.
I’m far more in favor of undelete techniques that are user-accessible and use our object model to do what they do. Commercial products like SmartLibrary (to name one of several) or roll-your-own code examples are available. But this tool is (a) free, (b) only reads from the database — the only writing it does is to your hard drive, (c) is only really usable by an administrator. In an emergency, it may be a good last-resort tool. I haven’t used it myself, so I can’t really comment on whether it will work or not.
I’d be tempted to say it at least can’t hurt, but one of our developers reminded me that even reading from the database can indeed have negative effects on performance and stability. Just to name two such effects, I’ll paraphrase his comments:
Hopefully I don’t need to remind anyone of the dangers of writing to our database, but those risks should be far more obvious.
And it’s not that, if you wind up writing code that communicates with our database, I’m going to hate you. It’s that (and Microsoft) won’t be able to help you. It’s that you will run the risk of breaking or degrading the performance/stability of technology we built to be fast and robust. The odds of a database change in our next Service Pack aren’t small. It’s that you’ll on your own if anything goes wrong. Consider this carefully.
Our object model is a contract with you. We’ve gone to a lot of trouble to ensure that using the OM results in stable and performant database interactions. If anything’s amiss, we’re honor-bound to fix it. Please, please use it.