Lookup field issues in SharePoint 2010

Posted: February 24, 2012 in SharePoint 2010, Uncategorized

Lookup field issues in SharePoint 2010

SPS version: SharePoint 2010 Enterprise – CU Dec 2011   

Lookup fields are great but they have some serious limitations sometimes. Through the UI you can set them to a link a field in one list to another list on the same web. This allows to say set values that would be shown in a dropdown similar to how you would do it with term sets in the Managed Metadata service. The plus with the lookup fields is that you can assign a non-techie to administer that single list values.  They are also good if your lookup values are not to be available globally to any web app in a proxy group.

Now, when you want your lookup field to exist on a different web than the current web. Then you will need to turn to code. This is something, that is readily done using a custom content type and the list schema field element (http://msdn.microsoft.com/en-us/library/aa979575.aspx).

<Field Type=”Lookup” DisplayName=”Something” Required=”TRUE” ShowField=”Lookupfieldname” UnlimitedLengthInDocumentLibrary=”FALSE” Group=”Real cool code group” ID=”{fe685707-c198-45db-baf3-d8cd92a9f4f6}” SourceID=”http://schemas.microsoft.com/sharepoint/v3&#8243; StaticName=”LookupFieldStaticName” Name=” LookupFieldName” Customization=”” ColName=”int1″ RowOrdinal=”0″ />

The idea being you can set this on a base content type, and from that point forward the inheritance chain takes care of it.

In my scenario, I had a set of 3 lists on a root site collection that served as lookup source for a set of 4 libraries that appeared on dozens of subwebs, each library with half a dozen custom content types assigned to it. The libraries were all created by a custom feature that was activated when the sub webs were created. They were generated using a custom list def (Schema.xml) and a list instance built into the feature.

In MOSS 2007, this worked like a charm on a number of deployment I did. In 2010 for some reason, I followed the same methodology and found my lookups were all broken. It took some troubleshooting but what I found was that the content type inheritance was broken. I had a base content type, another set that inherited from that type, and a 3rd level that was used at the lists (Company base CT à Project base CT à SpecificList CT). The lookup settings were kept all the way through these content types. When you create the list and assign the content type there is a new content type that is a copy of the “SpecificListCT”. I found that when SPS 2010 created that copy, it discarded the lookup field list settings. No matter how I set it up, this continued to happen.

A bit of a pain, and from what I could tell a flaw in SPS 2010. I was finally able to overcome this by removing the lookup from the List schema.xml file and in the event receiver for the FeatureActivated event, going in and adding the lookup fields using “SPList.Fields.AddLookup(LISTCOLNAME, SourceLookuplistID, false” (http://msdn.microsoft.com/en-us/library/ms436747.aspx ).

With that code in place the Lookup fields all started working and life was bliss once again. As with the custom Display/Edit/Add controls, this is a fairly easy way to get this capability into your farm, but it SHOULD be much easier.

  1. Thanks for good info. Refer to resolve lookup fields issue through coding by refer below post.


  2. I blog often and I truly appreciate your information.

    This great article has truly peaked my interest. I will bookmark
    your site and keep checking for new information about once
    per week. I opted in for your Feed too.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s