Are disabling and enabling foreign key constraints supported in SQL Server? Or is my only option to drop
and then re-create
the constraints?
相关问题
- sql execution latency when assign to a variable
- What is the best way to cache a table from a (SQL)
- php PDO::FETCH_ASSOC doesnt detect select after ba
- Bulk update SQL Server C#
- SQL to Parse a Key-Value String
相关文章
- Entity Framework 4.3.1 failing to create (/open) a
- How to truncate seconds in TSQL?
- Code for inserting data into SQL Server database u
- Delete Every Alternate Row in SQL
- Linux based PHP install connecting to MsSQL Server
- SQL Azure Reset autoincrement
- How do we alias a Sql Server instance name used in
- Is recursion good in SQL Server?
Your best option is to DROP and CREATE foreign key constraints.
I didn't find examples in this post that would work for me "as-is", one would not work if foreign keys reference different schemas, the other would not work if foreign key references multiple columns. This script considers both, multiple schemas and multiple columns per foreign key.
Here is the script that generates "ADD CONSTRAINT" statements, for multiple columns it will separate them by comma (be sure to save this output before executing DROP statements):
Here is the script that generates "DROP CONSTRAINT" statements:
First post :)
For the OP, kristof's solution will work, unless there are issues with massive data and transaction log balloon issues on big deletes. Also, even with tlog storage to spare, since deletes write to the tlog, the operation can take a VERY long time for tables with hundreds of millions of rows.
I use a series of cursors to truncate and reload large copies of one of our huge production databases frequently. The solution engineered accounts for multiple schemas, multiple foreign key columns, and best of all can be sproc'd out for use in SSIS.
It involves creation of three staging tables (real tables) to house the DROP, CREATE, and CHECK FK scripts, creation and insertion of those scripts into the tables, and then looping over the tables and executing them. The attached script is four parts: 1.) creation and storage of the scripts in the three staging (real) tables, 2.) execution of the drop FK scripts via a cursor one by one, 3.) Using sp_MSforeachtable to truncate all the tables in the database other than our three staging tables and 4.) execution of the create FK and check FK scripts at the end of your ETL SSIS package.
Run the script creation portion in an Execute SQL task in SSIS. Run the "execute Drop FK Scripts" portion in a second Execute SQL task. Put the truncation script in a third Execute SQL task, then perform whatever other ETL processes you need to do prior to attaching the CREATE and CHECK scripts in a final Execute SQL task (or two if desired) at the end of your control flow.
Storage of the scripts in real tables has proven invaluable when the re-application of the foreign keys fails as you can select * from sync_CreateFK, copy/paste into your query window, run them one at a time, and fix the data issues once you find ones that failed/are still failing to re-apply.
Do not re-run the script again if it fails without making sure that you re-apply all of the foreign keys/checks prior to doing so, or you will most likely lose some creation and check fk scripting as our staging tables are dropped and recreated prior to the creation of the scripts to execute.
Find the constraint
Execute the SQL generated by this SQL
Safeway.
Note: Added solution for droping the constraint so that table can be dropped or modified without any constraint error.
I have a more useful version if you are interested. I lifted a bit of code from here http://www.dbaservices.com.au/news/drop-recreate-foreign-key-constraints/ modifying it to allow for an array of tables into the stored procedure and it populates the drop, truncate, add statements before executing all of them. This gives you control to decide which tables need truncating.
You can temporarily disable constraints on your tables, do work, then rebuild them.
Here is an easy way to do it...
Disable all indexes, including the primary keys, which will disable all foreign keys, then re-enable just the primary keys so you can work with them...
[Do something, like loading data]
Then re-enable and rebuild the indexes...
http://www.sqljunkies.com/WebLog/roman/archive/2005/01/30/7037.aspx