mylifeinaminute.com

I’ve found that working with InfoPath is becoming more and more of a chore.  A form I’ve been working on has had its promoted columns changed a number of times (Side note: I would just love to have a defined specification).

Today when I attempted to completely retract my form (inlcuding manually deleting the content type associated with the form), I was presented with the always helpful error “The content type is in use“.  This is by far one of the more helpful errors you will ever see from SharePoint.  Unfortunately it isn’t clear how to discover where the content type is actually in use.  A quick trip to the content database for the site collection you are working in can show us:

DECLARE @ContentTypeName nvarchar(128)

SET @ContentTypeName='Content Type Name Here'

SELECT w.Title AS [Web Site], w.FullUrl AS [Web Url], al.tp_Title AS [List Title],
	ct2.*
FROM ContentTypes ct1
	JOIN ContentTypes ct2 ON LEFT(ct2.ContentTypeId, Len(ct1.ContentTypeId))=ct1.ContentTypeId
	LEFT OUTER JOIN dbo.ContentTypeUsage ctu ON LEFT(ctu.ContentTypeId, Len(ct2.ContentTypeId)) = ct2.ContentTypeId
	LEFT OUTER JOIN dbo.AllLists al ON ctu.ListId = al.tp_Id AND ctu.WebId=al.tp_WebId
	LEFT OUTER JOIN dbo.Webs w ON al.tp_WebId = w.Id WHERE ct1.ResourceDir=@ContentTypeName

[Credit to Curtis Ruppe]

Once we know where the content type is in use, deleting it through the GUI is a trivial matter.

Recently, we came across a need to migrate an existing (SharePoint 2007) RTM content database to a new farm, which had SP1 pre-installed.  After taking a full backup of the existing database (through SQL Server), the backup was restored in the new farm.

Note: I should also mention that the database was migrating from SQL Server 2000 to SQL Server 2005.

After resetting the SharePoint servers, browsing to the site in question brought the following error:

Server error: http://go.microsoft.com/fwlink?LinkID=96177

At this point, we detached the content database in question (Central Administration » Application Management » Content databases). Once the database was successfully detached from the farm, it was reattached using the following STSADM command:

stsadm -o addcontentdb -url ‹URL› -databasename ‹DBNAME›

Reattaching the content database with the above command completely successfully, and as an added benefit performed an inplace upgrade, bringing the database schema up to SP1.  This might prove to be a helping hand when it comes to migrating to MOSS 2007 SP1 if your wish is to start with a new farm, but retain your original content.