With the December 2007 release of SP1, a new stsadm command was introduced: mergecontentdbs. I had the opportunity to use this wonderful new command just a few weeks ago (saving my bacon from a rogue site collection which caused upgrade failure--fortunately I had the October 9, 2007, Security Update which gave me the mergecontentdbs command--SP1 upgrade would fail without getting rid of the rogue). Sadly, I learned a week after using the command in our production environment that it ever so conveniently deletes all content from lookup fields with multiple selections. Not even the versioning information is kept; the field only has to allow multiple selections; and, it even affects user/group fields! Talk about get egg on my face when Iasked one of our groups where their data had gone!Turns out, this specific problem is documented and corrected in the April 2009 CU (KB968857). Ironically, the KB was last updated just three days after I used mergecontentdbs and lost our data. Sure do wish something had been discovered sooner than a year and half after initial release. We are now scrambling to avoid insecurity in the stability of the SharePoint product amongst it's users and administrators.To head off any further conflicts with our users, I would like to scan all of our site collections for any lookup fields which allow multiple selections. Short of writing an application to load and scan the schemas of every list of every site of every collection, anyone got any ideas of how I can find these fields? Fortunately, if I can find them, I can restore their data from a backup made right before running mergecontentdbs.

FYI to anyone who runs across this question in the future... I hesitantly tried mergecontentdbs again a few weeks ago. Really, I had no other option. We're now running SP2 with the Dec 2009 CU and the security patch (KB 983444 and KB 979445). The operation ran successfully and we have found no "gotchas". Phew!