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.

When cleaning up a number of older databases in a QA/Staging environment (databases dating back to 2003), we managed to delete the default database for the SharePoint database system account. After deleting the database, the user will longer be able to perform actions on the SQL instance (login, view databases, etc.) when logging on through Management Studio.  To fix this error, log on to your SQL server as another administrative user (like the “sa” account), and execute the following:

sp_defaultdb 'SQLSERVER\dbuser', <DEFAULT DB>

Replacing with the new default database name.

There are times when servers are physically removed from your farm environment before they are removed from the SharePoint farm instance.  When this happens, SharePoint can have orphaned data remaining in its database making it impossible to remove the server through Central Administration without some manual intervention.

Note:  It is important to remove these orphaned servers as SharePoint will attempt to deploy sites (if configured as a Web Application Server) and other packages (such as contents of a solution package) to the orphaned server and permanently error out making the administration of your farm more difficult as you continue to add functionality.

When you attempt to remove the orphaned server, you will receive an error similar to the following:

Remove failed: An object in the SharePoint administrative framework depends on other objects which do not exist. Ensure that all of the objects dependencies are created and retry this operation.

(Remove failed: Operation aborted (Exception from HRESULT: 0×80000007):

The conflict occurred in database “SharePoint_Config”, table “dbo.Objects”, column ‘ParentId’. An object in the SharePoint administrative framework depends on other objects which do not exist.

This error is usually due to an orphaned reference to the Single Sign-On Service.  To fix this problem, you can do the following:

Note: This requires manual editing of the SharePoint configuration database.  Any manual changes made to this database that result in an error will NOT be supported by Microsoft.

select * from objects where Name like '%<SERVER NAME>%'

Use the output of that statement to obtain the ID (GUID) of the orphaned server.

select * from dependencies where objectid = '<GUID>'

The row returned will allow you to see the relationship (Object –> Dependency) that is preventing the removal of the orphaned server. It is most likely that if you look up the Dependent ID in the Objects table, you will see that it is a reference to the “SSOSRV” service (Single Sign-On Service).

After making sure you have found the correct entry, delete the item from the Dependencies table.

delete from dependencies where objectid = '<GUID>'

At this point, you will be able to remove your orphaned server from your farm (no IISRESET required).