existentia

There are plenty of other blog posts out there covering this same issue, but I’d like to add this “me too!” post anyway. As I like to think that the more people complain about something then the likelier it might get resolved. Well, I can hope anyway!

The Problem

So we’ve got this custom SharePoint timed job that performs a Collaborative Application Mark-up Language (CAML) query across a SharePoint site collection using the SPSiteDataQuery class in the SharePoint API. The query looks across document libraries only and checks to see if any documents, within any of these document libraries, within any of the SharePoint sites in the collection, has a custom property set to “1”. It then does a bunch of stuff with the documents returned by the query.

The problem we saw is where some documents that had this custom property set were not being dealt with by our custom SharePoint job. Upon further investigation we discovered that the CAML query used by our job was not returning all the results we were expecting. In fact, it wasn’t returning documents held in any other document libraries but for the first document library it came across. So what was the problem?

The Workaround

It transpires that this is a known problem with both Windows SharePoint Services 3.0 and Microsoft SharePoint Office Server 2007 and there is no fix (as yet). For our scenario we used Method #1 as discussed in the following Microsoft KB Article, which also describes the cause of this problem: http://support.microsoft.com/kb/946484

We re-configured the relevant document libraries so that the columns (both standard and custom) on each where completely identical and created in the same order. This then got the CAML query returning all the expected results.

Will this be fixed in the forthcoming Service Pack 2 for WSS & MOSS? I doubt it, as this to me sounds like a SharePoint design problem to me. Hopefully I’ll be proved wrong though.