Fixing Your Identity

Introduction

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

form:

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)

Conclusions

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.

Steve Jones

©dkRanch.net November 2001

Return to Steve Jones Home