SQL Server 2014: I am importing a table that is living in an old SQL Server to a new server. What I did was download the table to MS Access, then uploaded it to the new server (different environments).
The problem is that on upload, my primary key and auto increment are dropped. PK was easy to fix, and I was able to add a new identity column, but now I cannot append to the identity column as an error saying IDENTITY_INSERT is ON. So I turned it off, but still getting the same error.
Any ideas work a workaround?
Reading the documentation for INDENTITY_INSERT:
At any time, only one table in a session can have the IDENTITY_INSERT property set to ON. If a table already has this property set to ON, and a SET IDENTITY_INSERT ON statement is issued for another table, SQL Server returns an error message that states SET IDENTITY_INSERT is already ON and reports the table it is set ON for.
If you already tried turning it off for the other table, you might be in a transaction - try issuing a COMMIT.
Related
This question already has answers here:
How to turn IDENTITY_INSERT on and off using SQL Server 2008?
(7 answers)
Closed 2 years ago.
I'm trying to import an SQL Server database to mylittleadmin but for some reason, it not showing me all it options like import backup or any kind of importing method maybe it's due to permissions of my web hosting (GoDaddy).
So now am trying to insert all the data using SQL queries I already converted all my database to script but almost all tables have an identity primary key so when I tried to execute the script.
I got this error:
Cannot insert explicit value for identity column in table 'Adversaire'
when IDENTITY_INSERT is set to OFF.
This is a three-step process:
Turn IDENTITY_INSERT on for the table you want to insert data into. ex:
SET IDENTITY_INSERT Adversaire ON
Insert your data into that table, explicitly providing values to the identity field.
INSERT INTO Adversaire (name_of_your_identity_field, other_field1, other_field2...) etc...
When you're done inserting that data, be sure to turn IDENTITY_INSERT back OFF.
SET IDENTITY_INSERT Adversaire OFF
because according to the docs: At any time, only one table in a session can have the IDENTITY_INSERT property set to ON.
If the field is a Primary Key or otherwise has uniqueness constraints on it, turning on IDENTITY_INSERT still won't let you slip in duplicates. If you need to replace records that were already assigned a given ID value, you will either need to delete the old ones before inserting, or update the old records, whichever makes more sense in your application.
I have a super big table, more than 404 million rows, with an Identity column, but we don't use that table anymore, we only send certain data to it, is it possible to execute only once the SET IDENTITY_INSERT ON and never need to use it again?
What I want is to avoid any failure by the identity column during the inserts.
If I execute only that line it will remain forever or it's by session?
Thanks
https://learn.microsoft.com/en-us/sql/t-sql/statements/set-identity-insert-transact-sql?view=sql-server-ver15 says :
At any time, only one table in a session can have the IDENTITY_INSERT
property set to ON. If a table already has this property set to ON,
and a SET IDENTITY_INSERT ON statement is issued for another table,
SQL Server returns an error message that states SET IDENTITY_INSERT is
already ON and reports the table it is set ON for.
So, you'll have to set the identity_insert on every new session, and you're limited to only one table at a time per session.
You'll be better fixing the table, especially if "you don't use that table anymore". If the identity doesn't matter anymore, remove it.
Using MS SQL Server Management Studio 2008.
I have a db (say ip 10.16.17.10 and called db1) and a second one (say ip 10.16.17.25 called db2).
I am trying to copy one table (and its contents) from db1 into db2.
I have the database on both (but empty in db2).
The problem is no matter how I copy/export/import, no matter what options I set in MS SQL Server Management Studio 2008 when I click 'table'->'Design' (on db2) it ALWAYS says 'Identity Spefication: NO' even tho the db1 table has it on.
From db1 I go to 'Tasks'->'export'->'source/db' and 'destination/db'->'Edit Mapping'->'Enable identity Insert' and click it on.
But no joy. ALWAYS exports without it.
I try similar thing from IMPORT on db2. Similar thing if I use COPY.
I have read MANY of the STACKOVERFLOW articles on this, they all suggest setting IDENTITY_INSERT setting to ON but when I do run below:
SET IDENTITY_INSERT [dbo].[mytable] ON
The table either doesn't exist yet or has already copied WITHOUT the identity setting on so see the error:
does not have the identity property. Cannot perform SET operation.
I have tried setting it as a property (under database properties) for db2 but when I copy/import/export never works.
Would appreciate any help here as lots of StackOverflow articles so far all seem to be having an easier time than me.
I am planning on doing this for another 50 or so tables in this database so am hoping to find a way which doesnt involve running scripts for each table.
thanks
The process of using the Export Data Wizard to copy the data from one table to another will NOT replicate all aspects of the schema (like identity and auto-increment). If you want to replicate the schema, script out your table into a create statement, change the name to db2, and create it. Then you should be able to run the export/import wizard with the identity insert option on and insert into your new table that replicates the schema of your old table.
Ended up sorting this out using MS SQL Management Studio.
Thanks to #kevin for the help regarding Import Data and Export Data. Schemas are NOT transferred across however they are the best means to transport the data once schema is up.
Found best way to MASS import/export db table schemas using below (Saved SQL create scripts to file):
Tasks->Generate Scripts->All Tables To File->with Identity on
Ran 200kb SQL file on db2 for schema.
Then ran Import Data from db1 to db2.
Done, all Identity_Inserts maintained.
thanks for help
According to the Error message I think your table does not have an IDENTITY column. Make sure that [dbo].[mytable] does have an IDENTITY column before you executing SET IDENTITY_INSERT.
SET IDENTITY_INSERT [dbo].[mytable] ON
DEMO1 (Trying to set identity ON when there is NO identity column)
--Error
'Table 'T' does not have the identity property. Cannot perform SET operation.: SET IDENTITY_INSERT T ON'
DEMO2 (Trying to set identity ON when there is identity column)
--No Errors
Follow following Steps :
From db1 I go to 'Tasks'->'export'->'source/db' and 'destination/db'->'Edit Mapping'->'Enable identity Insert' and Edit SQL - > You will able to see query structure of Table.
IN the query for eg. ID int NOT NULL, do the next step ID int NOT NULL IDENTITY(1,1)
Then proceed.
I bet it will work.
I do a unit test Add/Insert a data record into a table with column name Id which is an identity column.
In the unit test I manually insert the id. So I could set the Identiy_Insert to ON before the Insert statement.
Are there any drawbacks keeping this feature turned ON for the production server?
Or should I change my unit testing approach? Inserting a value for the Name field and retrieve
and ASSERT it should be prove enough that the data record got inserted for the integrations
sake.
its not a feature you can keep ON. It is valid per connection.
give it a try, open a connection on SSMS and set it to ON to one table.
Then open another connection and you will see that if you try to insert the IDENTITY on the same table, it will fail.
From MSDN:
At any time, only one table in a session can have the IDENTITY_INSERT property set to ON. If a table already has this property set to ON, and a SET IDENTITY_INSERT ON statement is issued for another table, SQL Server returns an error message that states SET IDENTITY_INSERT is already ON and reports the table it is set ON for.
In general, I would not recommend using IDENTITY_INSERT in production to avoid concurrency issues.
As for the unit tests, I'd suggest creating a mocked data access layer instead of relying on a real database.
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.