ALTER PROCEDURE [dbo].[GenerateObfuscatedText]
	-- Add the parameters for the stored procedure here
	@inputText nvarchar(max) = '',
	@outputText nvarchar(max) output
AS
BEGIN
	-- SET NOCOUNT ON added to prevent extra result sets from
	-- interfering with SELECT statements.
	SET NOCOUNT ON;

	declare @intcounter int;
	declare @intstringlength int;
	declare @mynewstring nvarchar(max);

	select @intstringlength = len(@inputText);

	set @outputText = '';
	set @intcounter = 0;

	while @intcounter <= @intstringlength
	begin
		if ascii(substring(@inputText, @intcounter, 1)) between 65 and 90
			set @outputText = @outputText + nchar((cast(rand()*1000 as
int)%26)+65); -- A-Z
		else if ascii(substring(@inputText, @intcounter, 1)) between 97 and 122
			set @outputText = @outputText + nchar((cast(rand()*1000 as
int)%26)+97); -- a-z
		else
			set @outputText = @outputText + substring(@inputText, @intcounter, 1);

		set @intcounter = @intcounter + 1;
	end

	select @outputText;
END

BACKUP LOG AdventureWorks WITH TRUNCATE_ONLY

This is the result:

'TRUNCATE_ONLY' IS not a recognized BACKUP OPTION.

To circumvent this error in a DEVELOPMENT environment (not Production), use the following commands:

USE AdventureWorks
GO
ALTER DATABASE AdventureWorks SET RECOVERY SIMPLE
DBCC SHRINKFILE(N'AdventureWorks_log', 1)
ALTER DATABASE AdventureWorks SET RECOVERY FULL
GO

One should never execute the above commands in a Production environment unless you wish to lose all of your prior transaction log backups and the ability to restore to a given point in time based on those backups.

Reference

• DBCC SHRINKFILE (Technet)

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.

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.

sp_defaultdb 'SQLSERVER\dbuser', <DEFAULT DB>

Replacing with the new default database name.

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).