You might have noticed in my previous post that I was using CAML.NET to build up SharePoint CAML queries specifically for an SPSiteDataQuery object. I want to be clear that I was unsuccessful at leveraging SPSiteDataQuery to retrieve that data I needed from SharePoint 2010.
I was so excited to be cruising along with intellisense using the CAML seamlessly with an SPQuery object that at first I didn’t notice that the SPSiteDataQuery was returning corrupted data.
Don’t misunderstand, I’m not anti-SPSiteDataQuery now. 
After all, SPSiteDataQuery won’t be broken forever and it could already be patched in a CU that I’m not running yet. However, I’m not a “bleeding edge” or “just patched” kind of guy when it comes to creating solutions I expect to reuse and not constantly maintain. It is also worth noting that in my searches there are subtle reports where people have hit the same issue, but failed to follow up on reporting it. Plus, in my use case, switching to list enumeration instead has zero effect on my overall solution’s performance… Honestly, I just thought it would cool to use SPSiteDataQuery.
Here’s the skinny and some pretty pictures:
1) No single quotes: Everywhere I look folks are using syntax like attribute=’value’ instead of attribute=”value” with SPQuery. I love this because it makes the CAML easier to read in code without all of the escape characters. However, using single quotes in my syntax caused SPSiteDataQuery to not return any results, so if you are going to brave it, use syntax like this: 
2) Field values corrupted: Yes, really. It’s a little unnerving that once you get a query returning the right items, some of the properties will be truncated. After all “/” is a poor substitute for a ServerUrl. EncodedAbsUrl returned more than just “/”, but still not the expected value:
EncodedAbsUrl from SPQuery: 
EncodedAbsUrl from SPSiteDataQuery: 
Here is my Application Page’s class file, just in case you are morbidly curious 