This part of the article below has me the tiniest bit flustered as I believe it can take newbie’s down the wrong road.
Author-- "As TRUNCATE resets the identity column counter, in the case where you want to retain the identity counter, use DELETE instead of TRUNCATE."
I don't think people should be basing their choice on which method to use based solely on the identity counter being reset. I mean if you have a multiple gigabit table and utilize a delete with no where clause statement. You have a situation where delete will take forever (mins- hours) and if this is prod most likely the effected extents will be shared by other tables (yes it happens) so now you have a scenario where your exclusive locks could be slowing down other tables access to those extents as they are being updated . On top of that the CPU will also get pegged as the lock manager enforces concurrency on the deletes, so performance there will also suffer. Overall a poor choice in my opinion.
All of this when you could simply truncate the table then issue the statement below to reset the identity.
--Like most good things this example was taken from BOL
DBCC CHECKIDENT ('HumanResources.Employee', RESEED, 30)
I mean if your supper nervous wrap the two commands in a transaction and check for failure on truncate with @@ERRROR and enforce rollback if needed wrap in a SPROC and you'll become a SQL Hero!
The rest of the article was stuff most of us I think have learned from experience I did like the detail on the "minimal logging" of truncate I have inferred that has always been the process (deallocate from datafile but not erase) but that is the first time I have seen someone put it in print. Thanks author!