Back when I was working at The Farm we needed to do some sweeping changes to an existing Umbraco site.
To make sure the new content you upload does not conflict with additions the client makes during the development time, you must do the following... Take a back up of the live db for development, then reseed the tables of your new development db to a number much much higher. This allows you to synch up the database changes when it comes to deploy time. We reseeded the primary keys of some key tables to 500,000. (see http://www.farmcode.org/post/2009/09/09/How-to-sync-data-across-multiple-Umbraco-environments.aspx).
The issue we had though was that the time between reseeding and deployment turned out to be 3 months and the reseeding was no longer high enough. We learned this the hard way.
Today I'm about to begin the whole process on another existing Umbraco site, so I decided to check the current seeds.
Here is the script I used:
SELECT IDENT_SEED(TABLE_NAME) AS Seed,
IDENT_INCR(TABLE_NAME) AS Increment,
IDENT_CURRENT(TABLE_NAME) AS Current_Identity,
WHERE OBJECTPROPERTY(OBJECT_ID(TABLE_NAME), 'TableHasIdentity') = 1
AND TABLE_TYPE = 'BASE TABLE'
It turns out that in just over 2 months, the cmsPropertyData and umbracoLog tables had current seeds of 306208 and 145973 (respectfully).
Final deliverables for this site are not until March 2011. So it seems that a reseed of even 1,000,000 might not be enough.
So I've decided to reseed to 10,000,000
Here is all I needed to run:
DBCC CHECKIDENT (cmsContent, reseed, 10000000)
DBCC CHECKIDENT (cmsContentVersion, reseed, 10000000)
DBCC CHECKIDENT (cmsPropertyData, reseed, 10000000)
DBCC CHECKIDENT (umbracoNode, reseed, 10000000)
DBCC CHECKIDENT (umbracoLog, reseed, 10000000)