mylifeinaminute.com

Microsoft has completely removed the BACKUP LOG WITH TRUNCATE_ONLY capability completely from SQL Server 2008. If you try to attempt to execute the following command:

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)

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.