I am using Sql server 2012(Amazon RDS). I have a table which has an identity column in it.At the beginning Identity column starts from 1,2 and so on and adding identity smoothly, but suddenly it jumps from 17018 to 27011. What could be the reason. Please assist.
thanks,
Sella
Restarting server instance may cause this.
See this
Any of these things can cause a jump in the identity column:
An insert into the table that is later rolled back
An error when inserting into the table (like unique constraint violation)
A delete from the table
Someone use IDENTITY INSERT ON to set a value for the identity column. If that value is bigger than the current value, the sequence will resume at that.
A server restart
In general, you shouldn't expect identity columns to increment by 1. Treat the value as random. The only difference between identity and a true random is that it's guaranteed to be increasing in value.
Related
SQL Server
Version: 12.0.5556.0
Problem: SQL Server genereated an unexpected identity or did a reset on the auto-identity value
Information: I have a customer system which is running SQL Server 12.0.556.0 where, while testing phase I generated some test data which was deleted when the system was going live. So the identity value on this table startet at ~34.000 when the system was going into production in 2018.
Now after 2 years the identity value is at ~90.000, but a few days ago an entry with the identity 1 was created. When i query the table with select IDENT_CURRENT('MyTable') it is showing a value of 90182.
Now to my question, is there any reason why SQL Server would suddenly change the identity value to 1 and then jump back to the current identity value of ~90.000?
One possibility is that someone set identity_insert to ON for the table and inserted the row.
Otherwise, you cannot insert an explicit value for an identity column.
And, identity is guaranteed to be an increasing value (although there may be gaps) when generated automatically.
I am inserting data into a table with an identity column called unique_id. I am leaving the unique_id column out of the insert, assuming that the value will then be seeded from the identity configuration on the column.
Insert statement:
INSERT INTO table_name (column_1, column_2, column_3, processed_dt)
VALUES ('A', 'B', 'C', GETDATE());
Error:
Cannot insert the value NULL into column 'unique_id', table 'db.dbo.table_name'; column does not allow nulls. INSERT fails.
When I double click on the unique_id column in SQL Server Management Studio, I see that the following values are set:
Identity: true
Identity Seed: 1
Identity Increment: 1
What other configuration may be wrong to cause the identity seed to not be used automatically?
UPDATE:
Based on some of the recommendations I am seeing, I want to add that this schema was converted by our vendor from Oracle into SQL Server. I'm guessing that part of that process must of included converting Oracle Sequences into SQL Server Identity columns. Something being "broken" with the identity column is certainly a possibility.
I'm definitely on the correct database, table, and column. The Identity on this column was not created today, it was created weeks ago.
Is there any configuration the vendor could have put in place that would disable the auto assignment of the seed value and force the developer to "fetch" the next seed value manually?
SQL Server stores the seed/nextID value to be used. I'm wondering if the conversion from Oracle neglected to set that value. Try using the the following command on that table to check what it's seed value is:
DBCC CHECKIDENT ( table_name, NORESEED )
Maybe it actually is null, which is causing the error. Then you can use a variation of the same command to 'reseed' or set the next value to be used.
For more information and options:
http://msdn.microsoft.com/en-us/library/ms176057(v=sql.110).aspx
This is a pretty old question, but I was lead here when one of my developers had this very issue and wanted to share what caused/fixed it for us.
Basically, on another tab in SQL server "Edit Top 200 Rows" was open for the specified table.
Once this tab was closed, the insert worked without issue.
Hope this helps someone!
I got question about IDENTITY_INSERT. When you change it to ON, SQL Server automatically changes AUTOINC_NEXT value to the last inserted value as identity.
So if you got only one row with ID = 1 and insert row with ID = 100 while IDENTITY_INSERT is ON then next inserting row will have ID = 101. I'd like it to be 2 without need to reseed.
Such behaviour already exists in SQL Server Compact 3.5. Is it possible to force SQL Server 2008 to not change AUTOINC_NEXT value while doing insert with IDENTITY_INSERT = ON ?
I'm not aware of any way to prevent this behavior - after all, it's a prudent thing to do, anyway! If you've already set a value x (whatever that value might be), you shouldn't leave your seed value lower than x since otherwise, you're bound to run into getting a value in your IDENTITY column that's already there - not a good place to be!
But if you must, you can re-seed your IDENTITY column after you're done with your inserts using:
DBCC CHECKIDENT ('YourTableName', RESEED, 300);
where you can set any arbitrary value as your new seed value (here: 300). Of course, you need to be extra careful not to create any duplicates by setting the reseed value too low.
Additionally, if you do a reseed and your identity column is also a primary key, when you get back to the originally inserted value when IDENTITY_INSERT tablename ON was set you will get a PK violation. Another thing to think about.
Why would you want to do that? In the first place, there should be almost no occasions where you set identity insert to ON in a production system. And what difference would it make if you skip some? You can't count on identities not skipping in any event since it will skip if you do a rollback.
I have never seen this before, the rows will be sequential but I have noticed that it skipped over a particular "ID".... 1 2 3 4 6 7 8... missing 5...
There are no transactions in the INSERT stored procedure so nothing to roll back
We do not allow the deletion of records.
What else can be the case?
Probably a failed insert due to some other unique constraint on the table or a foreign key reference in the table and you try to insert an invalid fk value.
The insert doesn't have to be in a transaction.
The identity value increments even on a failed insert.
Igor mentions an important point about identities and transactions. From the docs:
Failed statements and transactions can
change the current identity for a
table and create gaps in the identity
column values. The identity value is
never rolled back even though the
transaction that tried to insert the
value into the table is not committed.
For example, if an INSERT statement
fails because of an IGNORE_DUP_KEY
violation, the current identity value
for the table is still incremented.
Any way, identity counter does not restore your value (if you have executed with transaction or without it). The same behavior has oracle (sequences).
Identity is not transactional.
You may use your own primary key counter and control access to it.
Failed attempts generates an identity value even though it is not inserted into the data table. Then, this results to the lost of an identity (it's a shame I can no longer find the post where I have learned it!).
I had an unusual problem yesterday where I was suddenly unable to insert records into a table with an identity column.
A simple insert like this: INSERT INTO MyTable (Column1, Column2) VALUES ('text', 236764)
Started throwing a primary key constraint violation.
I ran DBCC CHECKIDENT on the table, and realized that SQL Server had stopped updating the last used value, so that when it was inserting it was incrementing using the old value and the new identity value usually already existed in the table, hence the violation errors.
Resolving the problem wasn't an issue, I just reseeded the table for the next highest sequence number, but I've never seen this happen before!
Does anyone have any idea what might cause SQL Server to stop updating identity properties, and where I might look for evidence? There is no replication or any triggers involved, it's just a plain old table.
EDIT: SQL Log Rescue would have been ideal, but it only works on SQL Server 2000. Is there a similar tool out there for SQL 2005 logs?
If someone has inserted to the table using SET IDENTITY_INSERT ON, someone could absolutely have entered in an invalid value for the table. That would be my first guess. You could use a log analyzer like SQL Log Rescue to go back in time through the transaction logs and see if you could find who the bad person was who messed up your data...
I think SET IDENTITY_INSERT ON reseeds the Identity.
From BOL
If the value inserted is larger than
the current identity value for the
table, SQL Server automatically uses
the new inserted value as the current
identity value.
The only way I could reproduce this issue was to manually set the seed too low with DBCC CHECKIDENT.