locked
Disabling all constraints on tables RRS feed

  • Question

  • Hi all

    I have an SSIS package which truncates and appends data in all tables in a database - but the package does not work because there are constraints on some of the tables involved.

    I realise there are many articles on how to disable foreign key constraints but I also have other constraints on the tables - like default value GUIDs in certain columns.

    How do I, if I can, disable every type of constraint on all tables in a database, run the transfer Objects Task in SSIS (which copies and replaces the data) and then re-enable the constraints please?

    Any help on this would be appreciated.

    Thanks in advance.

    Friday, December 7, 2012 3:05 PM

All replies

  • sp_msforeachtable 'Alter table ? NO CHECK Constraint ALL'

    Hope it this will helps you.


    Please Mark as Answer if my post works for you or Vote as Helpful if it helps you. Kapil Singh

    • Proposed as answer by Sergio S Arias Friday, December 7, 2012 3:17 PM
    Friday, December 7, 2012 3:16 PM
  • If you want to disable all constraints, you probably also want to disable all triggers.

    Do not forget to enable everything afterwards. The syntax for that is

    DISABLE TRIGGER ALL ON <TableName>
    ENABLE TRIGGER ALL ON <TableName>
    

    See http://msdn.microsoft.com/en-us/library/ms189748.aspx

    Also, you could use the 'sp_MSForEachTable' stored proc that Leo mentioned for disabling all triggers for all tables with a single statement.

    Friday, December 7, 2012 3:27 PM
  • I want to point at three more things.

    Firstly, Kapil_KK's answer contains a typo. It should be 'NOCHECK' instead of 'NO CHECK'.

    Secondly, you cannot disable default constraints, you can only disable foreign key constraints and check constraints.

    Thirdly, after disabling a constraint and enabling it again, it is considered 'not trusted' by the optimizer, which can have a negative performance impact. You should make the constraints trusted again.

    -- Disable all FK and CHECK constraints
    ALTER TABLE <TableName> NOCHECK CONSTRAINT ALL;
    GO
    
    -- Proof that they are disabled
    SELECT * FROM sys.foreign_keys WHERE is_disabled = 1;
    SELECT * FROM sys.check_constraints WHERE is_disabled = 1;
    GO
    
    -- Enable all FK and CHECK constraints again
    ALTER TABLE <TableName> CHECK CONSTRAINT ALL;
    GO
    
    -- Proof that they are enabled
    SELECT * FROM sys.foreign_keys WHERE is_disabled = 1;
    SELECT * FROM sys.check_constraints WHERE is_disabled = 1;
    GO
    
    -- Proof that they are not trusted
    SELECT * FROM sys.foreign_keys WHERE is_not_trusted = 1;
    SELECT * FROM sys.check_constraints WHERE is_not_trusted = 1;
    GO
    
    -- Make them trusted again
    -- The possibility exists that data prevents a constraint to become trusted
    ALTER TABLE <TableName> WITH CHECK CHECK CONSTRAINT ALL;
    GO
    
    -- Proof that your constraints are trusted again
    SELECT * FROM sys.foreign_keys WHERE is_not_trusted = 1;
    SELECT * FROM sys.check_constraints WHERE is_not_trusted = 1;
    GO


    Just to give you an extra option, I include some code to enable FK constraints one by one with a cursor and dynamic SQL

    DECLARE cr_EnableFKs CURSOR FOR
        SELECT 'ALTER TABLE ' + OBJECT_NAME(parent_object_id) + ' CHECK CONSTRAINT ' + Name
        FROM   sys.foreign_keys
        ORDER  BY OBJECT_NAME(parent_object_id), Name
    FOR READ ONLY;
    
    DECLARE @Statement VarChar(255);
    
    OPEN cr_EnableFKs;
    FETCH cr_EnableFKs INTO @Statement;
    WHILE @@FETCH_STATUS = 0
    BEGIN
        EXECUTE(@Statement);
        FETCH cr_EnableFKs INTO @Statement;
    END;
    CLOSE cr_EnableFKs;
    
    DEALLOCATE cr_EnableFKs;
    
    IF EXISTS ( SELECT 1 FROM sys.foreign_keys WHERE is_disabled = 1 )
    BEGIN
      SELECT name AS FK_Name, 'ERROR! FK not enabled' AS Remark FROM sys.foreign_keys WHERE is_disabled = 1;
      RAISERROR(N'Not all foreign keys were enabled!', 11, 1);
    END;
    GO
    -- End of script


    • Edited by Chris Sijtsma Friday, December 7, 2012 4:03 PM
    • Proposed as answer by Naomi N Friday, December 7, 2012 4:13 PM
    Friday, December 7, 2012 3:54 PM
  • I am sorry Kalman, that my post is on exactly the same things your reference is about. I think it is a bad practice to post the same answer that somebody else already posted, but I didn't do it on purpose. I really did not see your reply. I must suffer from lag in this part of the world.

    Friday, December 7, 2012 7:20 PM