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!
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 migrating data from one database to another. I have my scripts mostly together already, but I am trying to figure out the best way to make one change to a table in the new database.
I have a Customer table. That table has a customer_id column which is the identity column. I want to change the identity seed/increment from (1,1) to (200,1) without changing the customer_ids for the existing data I will be inserting into the table.
Old data is 101-108. Basically we want to keep the old data the same so it matches up with old records in other systems, but we want the new data to start seeding in at 200.
I tried Googling how to do this, but all my Googling came back with results where people wanted to change what column was the identity column, and not just change the identity seed number. Is there a simple query I can use to accomplish what I want to do?
You can use DBCC CHECKIDENT:
DBCC CHECKIDENT ('dbo.customer', RESEED, 200)
This will change the current seed value of the identity column of the specified table. If you need to insert specific identity values, you can SET IDENTITY_INSERT ON in your insert statement.
IDENTITY_INSERT
What I would do unset the new column as an identity (using alter table), then insert the data from the old table, and then reset the new column as the identity again, with whatever increment you want as per the link
https://learn.microsoft.com/en-us/sql/t-sql/statements/create-table-transact-sql-identity-property?view=sql-server-2017
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.
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 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.