2

I am having a dilemma. I have a table with a column called ID and it is the primary key. It is in automated increments so 1, 2, 3, and so forth and the table is 1-8.

A former programmer deleted row 7 and so now there is a gap between 6 and 8. I need to change the value of 8 to 7.

I have tried several things:

  • I can not edit ID 8 because it is an identity column

  • I have tried to query:

    set identity_insert mytable ON

then delete the row and re-add and edit the ID as other threads have recommended. However, the automated number kicked in, and now it is row 9 and I still can not edit the ID. I am not sure what I am doing wrong here. Is there a way to do this? Thanks in Advance.

javasocute
  • 648
  • 2
  • 11
  • 28
  • 4
    Is there a specific reason you can't have gaps in your ids? – PinnyM Jan 26 '12 at 22:32
  • 3
    The value of a primary key has **no meaning** whatsoever. It is absolutely useless to renumber it. Just leave it as it is. –  Jan 26 '12 at 22:35
  • you know I actually dont know if thats an issue. Would that potentially cause problems in code if the code was counting IDs? – javasocute Jan 26 '12 at 22:35
  • what sql statement were you running to do the insert with identit_insert on? – slapthelownote Jan 26 '12 at 22:35
  • 2
    @javasocute: If your code relies on gapless primary key values, then your code is wrong. –  Jan 26 '12 at 22:36
  • 1
    You really just need to get used to the idea that identity fields have gaps in them. Eventually they always do. If you need them to be absolutely consecutive for some strange reason you are using the wrong tool to do that. – JohnFx Jan 26 '12 at 22:55

5 Answers5

2

You probably need to ask why it matters that the numbers are sequential with no gaps: SQL's IDENTITY type isn't really for this sort of functionality as you're finding out.

That said, if you do need to fill the gaps in, you're nearly there -- the other thing you need to do is reseed the identity field with a new starting number. In SQL Server this is achieved with DBCC CHECKIDENT.

Don't though make this a programmatic thing to fire -- this should be a DBA task only when you need to clean the data up, and it would be fairly rare in practice (in ten years, I've only ever used it once. And that was on a dev database; it's never been used on live environments). If you find you're reseeding regularly then you need to rethink the behaviour of the application.

Chris J
  • 30,688
  • 6
  • 69
  • 111
1

No-one actually answered the question: "how to turn off autonumber in sql?"

PhpMyAmin shows the following SQL when i change an integer field to an autonum...

ALTER TABLE course CHANGE Test Test INT( 11 ) NOT NULL AUTO_INCREMENT

..and this when i remove the autonum...

ALTER TABLE course CHANGE Test Test INT( 11 ) NOT NULL

In MS ACCESS SQL i used

ALTER TABLE course ALTER Record_ID INTEGER; to turn off the auto number.

if you turn the autonumber back on you'll find it resumes a the last number you had. to reset the autonumber to 1, you need to re-seed it (and your table should be empty)

Maybe that will help the next person that lands here.

jcansell
  • 154
  • 6
0

There are valid cases (but poor/deficient DB design) where this is applicable.

E.g. a table with low rowcount but moves up through IDs extremely rapidly. You could hit the integer max +ve value.

Short term fix can be to rekey the IDs. Long term is to either prevent rapid ID seed movement or use a better key datatype.

Shiv
  • 1,274
  • 1
  • 19
  • 23
0

Try to find the missing gaps and insert using that ID. This could prove useful and is quite well explained http://www.codediesel.com/mysql/sequence-gaps-in-mysql/

Mike
  • 3,017
  • 1
  • 34
  • 47
0

I am not sure what I am doing wrong here.

You are using IDENTITY for something else than it was meant to be used.

As others said before me in the comments, the purpose of IDENTITY is to create unique numbers, not pretty-looking numbers.
If you need pretty numbers, an IDENTITY column is the wrong tool for that. You should create a second (non-identity) column and generate the pretty number with some other method.

In general, it's almost never a good idea to change the value of a primary key (no matter if it's an IDENTITY column or just a "regular" primary key).

Just think of these scenarios:

  • What do you do when there are other tables that reference the table you're changing?
    You'd have to find all other tables where the value is used and change it there as well.
    (think of a Products table with a ProductId, plus an Orders table which uses the same ProductId as well)

  • What do you do when there are already 100,000 records in the database and then someone deletes row 7? Change the values in row 8 to 100,000?

  • Then, imagine that row 7 of 100,000 is deleted and that column is referenced by other tables.

  • Do you really want to do this every time someone deletes a row?

You see, the guys at Microsoft had a reason when they decided not to allow editing IDENTITY values.
You do NOT want to do this...trust me!

Christian Specht
  • 35,843
  • 15
  • 128
  • 182