Sometimes it happens that the site column that was provision from a custom feature has been changed via code or using UI. In that case the column will receive a new version and will be untied for the feature.
And if later on you try to update the field from feature definition it won't work.
So let's look how to fix that situation.
Very important thing to mention - the changes will be done directly in SharePoint Content Database. So BACK IT UP before proceeding with the steps.
- Ok, the first thing to do is to get the Site Collection id. For example, using Powershell:
- Next step is to open the Content Database related to the Site Collection in some IDE (most probably SQL Management Studio) and run the query listed below to check that the column was actually modified directly (not from feature):
WSS_Content should be replaced with the name of Content Database
FieldInternalName should be replaced with the field's internal name, and
site_guid should be replaced with the site guid
If there is a modification in the field it will be listed by this query
- Next step is to delete the Database entry:
- And the last step is to republish/reactivate your solution/feature
In most scenarios these modifications may live in your environment forever. But sometimes they can lead to unpredicted issues.
For example, I recently got in situation when I needed to update the definition for Lookup field and is later used in subsites. The Lookup is provisioned in site scoped feature and is used in list definition that is provisioned in web scoped feature and activated in subsites.
As soon as I changed the XML for my Field Definition in the feature and deployed it, I got an exception that I can't activate a feature on a subsite.
The exception was pretty general: Value doesn't fall within expected range.
The reason for that was that SharePoint was comparing XML from the feature and from Site Column. And Site Column was modified outside the feature. So, XMLs were not equal.
Proceeding with the steps listed above I was able to fix the issue.