Clearing the data from all the tables

  • Hi, there is a requirement for me to clear all the tables of the database which I am using now. There are around 100 tables in the database. Lots of unwanted data is inserted to these tables, it needs to be cleared. Most of the tables have IDENTITY (1,1) property assigned on the ID column.

    I found like the following scripts will clear the data and the identity of the ID column in each table will start from 1.

    Kindly advise me whether this will work or suggest if there is a better way. Thanks.

    EXEC sp_MSForEachTable 'DISABLE TRIGGER ALL ON ?'
    GO
    EXEC sp_MSForEachTable 'ALTER TABLE ? NOCHECK CONSTRAINT ALL'
    GO
    EXEC sp_MSForEachTable 'TRUNCATE TABLE ?'
    GO
    EXEC sp_MSForEachTable 'ALTER TABLE ? CHECK CONSTRAINT ALL'
    GO
    EXEC sp_MSForEachTable 'ENABLE TRIGGER ALL ON ?'
    GO
  • I can't see why that wouldn't work.  But don't take my word for it - have you actually tried it?  Bear in mind that sp_MSForEachTable is an undocumented stored procedure.  That doesn't mean that you shouldn't use it - just bear in mind that it could change or be removed from the product at an time, however unlikely that may be.

    John

  • I wouldn't worry about sp_MSForEachTable going away.

    However, if we're really doing this all the time, nuking the entire database. What about just having an empty one available and run a restore. That will take a lot less time even than this. Especially for an empty database. It'll be safer and faster. The only gotcha would be that as the data structures change, you'll have to ensure that you get updated backups of your empty database.

    Alternatively, even better I'd say, since your database code is all in source control (right?), just drop the database and recreate it on the spot. That would work even better than the backup plan. Less maintenance and headache.

    BTW, if you said "no" that your database was not in source control, there's today's project.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • Another possibility is extracting a DACPAC for the DB in question and building an empty one from that.

    If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.

  • Phil Parkin wrote:

    Another possibility is extracting a DACPAC for the DB in question and building an empty one from that.

    I generally dislike DACPAC, but this might be a great use of it.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • Grant Fritchey wrote:

    Phil Parkin wrote:

    Another possibility is extracting a DACPAC for the DB in question and building an empty one from that.

    I generally dislike DACPAC, but this might be a great use of it.

    Using sqlpackage: https://docs.microsoft.com/en-us/sql/tools/sqlpackage?view=sql-server-ver15

    an extract followed by publish

  • If you TRUNCATE all tables, you better have a script handy to repopulate ALL your necessary reference tables. 😉

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Jeff Moden wrote:

    If you TRUNCATE all tables, you better have a script handy to repopulate ALL your necessary reference tables. 😉

    Aren't those already in source control too?

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • DELETE will be happening as TRUNCATE is not supported, even though I disabled the table constraints. Si I have replaced DELETE instead of TRUNCATE.

    I have tested this script by executing in my local database & it is working fine. DELETE is working & it has cleared data from all the tables.

    I have taken backup of the database before executing this script.

     

  • I submitted a script to truncate tables that have referencing foreign keys. It doesn't do anything with triggers though I'm sure it can fairly easily be amended to do that. You just call the SP with the table name and schema and it will truncate the table and recreate the foreign keys. When you truncate a table it resets the identity columns, delete does not do this, also truncate can be orders of magnitude faster than a delete.

    https://www.sqlservercentral.com/scripts/truncate-a-table-that-has-foreign-keys-referencing-its-columns

  • I use a very archaic method -

    select 'delete from '+name from sys.tables where type='u' and  name <>'sysdiagrams' and name not in (lookuptable1','lookuptable2'..... etc)

    copy the results into excel and put them in the right order for your foreign keys - then save your script and execute it.....

    I know it's old, but the first time you run your script it will show you your dependencies and force you into a really simple script you can re-use as a proc and a sql agent job

    do the same script with dbcc checkident (reseed) and you can reseed only the tables you choose in your where clause

    like I said it's archaic but it's been with me since sql 6.5

    MVDBA

  • Thanks for the replies. From your expert comments, I could reckon that the query I am using can be changed to the following one, which will serve my purpose.

    EXEC sp_MSForEachTable 'DISABLE TRIGGER ALL ON ?'
    GO
    EXEC sp_MSForEachTable 'ALTER TABLE ? NOCHECK CONSTRAINT ALL'
    GO
    EXEC sp_MSForEachTable 'DELETE FROM ?'
    GO
    -----Will execute the following query for reseting the identity for the tables which need to reset the existing identuty value
    DBCC CHECKIDENT ('[TestTable]', RESEED, 0);
    GO
    -------------------------------------------------------------------------------------------------------------------------------
    EXEC sp_MSForEachTable 'ALTER TABLE ? CHECK CONSTRAINT ALL'
    GO
    EXEC sp_MSForEachTable 'ENABLE TRIGGER ALL ON ?'
    GO
  • All you've done is change TRUNCATE to DELETE, right?  That's going to run slower and use more log space, and mean you have to do the extra step of reseeding the identities.  How many tables need to have the identity reseeded and how many need to have it left as it is?

    John

  • John Mitchell-245523 wrote:

    All you've done is change TRUNCATE to DELETE, right?  That's going to run slower and use more log space, and mean you have to do the extra step of reseeding the identities.  How many tables need to have the identity reseeded and how many need to have it left as it is?

    John

    that was kind of why I do it my way - what if someone adds a new table (doesn't tell you)

    you can easily stick a small script in at the end to show which tables still have data (then go and shout at someone for not giving you release notes 🙂   )

    MVDBA

  • Yes, I am replacing TRUNCATE with DELETE.  There are around 150 tables in total & for around 80 tables I have to reset the identity. Rest, of the tables, I can leave as it is.

Viewing 15 posts - 1 through 15 (of 16 total)

You must be logged in to reply to this topic. Login to reply