Fixing Your Identity
I used identity fields quite a bit in my schemas. Whether or not this is a good idea, I won't debate
in this article, but I often find the need to generate some artificial id for a table that doesn't have
any apparent primary key.
One of the things that we occassionaly find is that developers have a need to hard code an identity
value for particular code triggers. They do this for various reasons, but it usually means that we need
to ensure that the identity values in development and production evironments remain in synch.
Occassionally, our testing gets a little out of synch with the release of new code to the live encivironment
and the identity values are not the same. When this happens, I have to "reset" the identity value to
synch back up the two databases. If anyone else out there uses identity values, you have probably
run into the need to change the functionality of the identity property.
I was expecting that I would have to manually hack some system tables to fix my systems, but was
pleasantly surprised. After a little research in Books Online, I discovered that the SQL Server development team anticipated this
and provided a utility to handle these situations. There is a DBCC utility that takes the following
dbcc checkident('<table>, <NORESEED | RESEED>, <value>)
whose parameters are defined as follows:
- table - This is the name of the table that has the identity column. This name must be
quoted or listed like any other identifier.
- NORESEED - This flag implues that the identity value should not be changed.
- RESEED - This flag implues that the identity value should be changed. Kind of obvious, but that's
what's in BOL.
- value - This is an optional value that can be included and the table will take this as the new
identity value. This means the next row will use this value if there ARE NOT ROWS in the table. Otherwise
the next row will use this value + 1.
Using this utility, you can find out information about the next value that will be used or reset the
value to a new value. For my situation, I needed to delete data rows, reset the identity value to a lower
seed, and then reinsert these values in the correct order. I deleted the data and then ran
DBCC CHECKIDENT (marketing, RESEED, 55)
Working with identity values is like most operations in SQL Server, there are positive and negative
points and you must make an intelligent decision based on the situation. I hope this article has
shown that there is some control when using identity values. While you should not use this too extensively,
IMHO, to manage the values that the server generates, this allows you to correct mistakes or manage the
value if you have the need. Be sure if you use this that you understand the next value that will be used.
As always I welcome feedback on this article using the "Your Opinion" button below. Please also
rate this article. Please don't comment on whether identity values are good or bad in this space as
this article is merely concerned with altering identity values that do exist.
©dkRanch.net November 2001
Return to Steve Jones Home