Murphy's Law can apply anywhere anytime and my recent re-installation of SharePoint is certainly no exception to the rules.
Soon after I finished recreating our SharePoint intranet, I stared sharing it with my immediate colleagues. While I was not really expecting some "Oh!" and "Aaah!" cheerful comments, I was still hoping for some kind of "Cool, it's back, thanks for the tool.".
But no, even that was expecting too much. The very first comment I received was an assassin comment like: "And I suppose you managed to retrieve all files stored in the previous SharePoint database ?". That comment triggered a machine-gun like stare from me to my colleague. No, I did not manage so far to retrieve these files and yes I had tried already. SQL Management Studio did not really help me by the way.
I had been cornered and really had to find a solution this time. So I returned to the web, googling frantically, trying various unsuccessful solutions until finally my patience and stubbornness got rewarded. I found found a great article from Keith Richie describing how to export the site content from a SharePoint Database for recovery purpose.
His article include a small source code and instruction to compile and run the program. It worked almost like a charm from the first run. Yet, as some of the recovered files were quite large, I had to boost the buffer size (as I worked locally this was not a problem) and even tweak the SQL query to work on a per directory basis to limit the execution run time. Happily this time SQL Server Management Studio was of great help to test and fine-tune the queries. Within 30 minutes from the moment I read Keith's post I had recovered all files I needed.
Today all files are imported in the new SharePoint and I preciously kept the program source and instruction ... just in case one day I need to recover files from another SharePoint database.