Task list field database location changed from 2007 to 2010

Question

What I've witnessed

I've just noticed something rather annoying with SharePoint following an upgrade from 2007 to 2010.

The task list schema in SharePoint 2007 had the 'Assigned To' field first. This basically meant that the 'Assigned To' field went into the 'int1' field at the database level.

In SharePoint 2010 the task list schema has Predecessor first. Guess what that means for new lists? The Predecessor columns goes into the 'int1' field at the database level and 'Assigned To' falls into 'int2'.

Changing the field ordering on the task content type only helps if using a 'blank custom list' and adding the content type directly. Doing so will order the fields in the list schema in-line with what 2007 looked like! However the 'task list definition' ignores that and uses its own schema as the starting point. To get a task list using the same underlying data fields as SharePoint 2007 did, you basically need to rework (remove and add) the content types/fields on the list resulting in resetting the schema with that of the reordered content type.

Why does this matter?

A lot of you maybe wondering why I even care about the SQL fields since I shouldn't be touching them etc. Well to be honest I shouldn't have to care but Microsoft has made me!!!

We use a DataFormWebPart to roll up incomplete tasks from all sites. Created using SharePoint Designer. Various options are set for the cross site recursive bits but the main of it is the CAML query and this part is causing the headache.

<Eq>
    <FieldRef Name="AssignedTo" />
    <Value Type="Integer"><UserID Type="Integer"/></Value>
</Eq>

The above is known to filter based on [me], and it works, that is for all sites created in 2007! Tasks in any new lists do not! ...and I now know that's because the underlying SQL being generated is doing:

int1 = [id]

...and not:

int1 = [id] or int2 = [id]

I'm not sure (yet) how SharePoint internally builds the SQL but I may look into it at some point because it obviously has to turn the CAML into SQL and in doing so uses a source to lookup the associated field mappings. Either way the source is going to be different based on old lists or new lists. Turns out this time for whatever reason it uses the old BUT either way it means tasks assigned to me are now being left out. Can only see three options currently

1. Create a script to update all current task lists to reflect the new task list definition. Not ideal, and no small task.
2. Going forward make sure all lists created using the task list template are modified as previously discussed (removing/adding ct's and fields).
3. Put the filter in XSLT and suffer performance!

I realise number 2 could be templated but the original template would still remains and moving away from the MS template probably is susceptible to issues in the future!!

Has this been witnessed by anyone? I post knowing there truly isn't an answer to it. Just suggestions/opinions.

Answer 1

Well following spending lots of time witnessing the above. Turns out simply putting the 'AssignedTo' in the ViewFields part of the query fixed the issue!

Even though I'm not using the field for display the issue was fixed by adding it. The underlying fields are still different but SharePoint DOES KNOW THIS after all and the huge query produced references the correct fields per web/list.

Sweeeeet.