Disclaimer: Approach used in this blog post is risky and not recommended. The idea of this post is to just understand the insight and sharing my experience with my blog readers. If still you want to try this for any situation then please do this at your own risk.
We earlier created a custom list using list definitions feature in our site. After one month, we decided that the list definition responsible for list creation had to move to another feature to make the feature as the group of alike lists.
After deployment, we found that list was not being opened and was throwing error. So after digging in to log file, I came to know that list was still pointing to previous feature and now that feature didn’t have the reference for the list schema (As we had already moved the reference to the new feature). I was not ready to take risk of deleting the existing list as it was already contained thousands of referenced items. Deleting the list means to do lots of manual work to fix the functionality and to waste the time and effort.
Now there was only one way that if somehow I could change the reference of existing feature id of list to new feature id. But how that was possible??
I couldn’t found a direct way by using code or Power Shell script to change the feature reference of existing list. So I started analyzing and thought that at least there must be some place where SharePoint keeps this configuration and my mind said content database. Now as you know that SharePoint content database is not a piece of cake to understand and it’s very complex to understand. Everything is based on GUID and referencing is too complex to understand. Due to this complexity, Microsoft doesn’t recommend to touch the content database. But for me there was no other way. So below is how I fixed this issue.
- In site content database, there is a table (AllLists) that has all such references. This table keeps the relation information of a custom list and feature related with the list.
- ‘tp_Title‘ column has the name of list(s) and ‘tp_FeatureId‘ column keeps the feature id related to the specific list.
- My list name was ‘AnnouncementCategory’ and first I perform the below command.
SELECT * FROM [AllLists] where tp_Title like ‘%Announce%’
This query gave me all related lists result set. After analyzing the result set I came to know that all other related lists are pointing to same feature id but the problematic list was pointing to different feature id (The previous feature).
- Now I decided to update the feature id value to see the difference. I noted down the current feature-id value at notepad (In case to revert back the changes) and execute below mentioned update command to update the feature id.
update AllLists set tp_FeatureId=’xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx’ where tp_ID like ‘%xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx%’
tp_FeatureId : This is the feature id of new feature that contains the reference of the existing list. You can get this from your code file (Feature.xml) or from 14 hive (C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\FEATURES).
tp_ID : This is the unique id column in the AllLists table to identify a specific record.
- After running this command, when I tried to open the problematic list then to my surprise it opened without any error. After that I performed some testing on the list to verify that whether everything is working fine or not.
- Testing included adding/updating/deleting/content migration and lookup references of list.
For me after spending a couple of hours, it was like bingo. Happy Share Pointing 🙂