I was very excited to learn about the new enhancements in SharePoint Server 2010. The most anticipated feature was Business Connectivity Services that provided scope for integrating external data sources into SharePoint along with the support for updating, deleting and inserting data into those sources. Another major development was made to the SharePoint designer that can now effectively package and reuse changes made through the designer. Improvements were also made in the area of Business Intelligence and Workflow management. To enjoy these benefits, I decided to install SharePoint Server 2010 on a single server farm and created the first site collection.
I then created a site column and declared its Content Type. While trying to access the site columns using SharePoint 2010′s UI, I came across the following error on my screen:
“Field type xxx is not installed properly. Go to the list settings page to delete this field”
It could be because that particular site column is corrupt. On using the SharePoint’s UI and SharePoint Designer to delete the column, I received a message that the Site Column object cannot be instantiated.
Now, I ran the below commands from inside the Powershell:
PS> $web = Get-SPweb http://demo1/sites/sponline
PS> $fields = $web.Fields
PS> foreach($field in $fields) { write-host $field.Id}
The output showed that the column was present, but was damaged or corrupt. I used the following command to remove the column:
PS> $web.Fields.Delete <”ContractStatus”>
This threw an exception and the column was not removed.
Now, I was screwed. I thought of making changes in the database itself using T-SQL. The primary task was to find the offending column causing this problem. I did that using Powershell again. I took the following steps to make the required changes in the content database:
- Looked for the Content Type of the offending column in the ‘field.text’ file.
- With the help of Central Administration, searched the content database storing this Site Column.
- Started the Microsoft SQL Server Management Studio and ran a query for finding the corrupt record as follows:
“SELECT * FROM [Demo_PortalDB].[dbo].[ContentTypes] WHERE Definition LIKE (‘%332B55548E6C%’)”
- Issued another query to delete the damaged record:
“DELETE FROM [Demo_PortalDB].[dbo].[ContentTypes] WHERE Definition LIKE (‘%332B55548E6C%’)”
This time I ran across multiple errors while trying to access data in other fields too. The only resort left was to perform SharePoint recovery using commercial third-party tools. I tried out the demo versions of these utilities and the results were positive. They enabled me to easily and effortlessly recover SharePoint documents along with other site content including uploaded articles, blogs, wikis, etc. With the help of these tools, I got all my data back within a few minutes.