views:

104

answers:

5

I am designing a standard ASP.Net site with a SQL database. I have a database schema and During the tests I am changing data types amongst other tasks and the data contained inside really is not that important.

I keep getting errors as the old data does not match the new rules. This is not important and I am happy to clear everything but currently, I have to export/publish the database to a .sql file then import it from scratch - which is time consuming.

Is there a quick button / feature that I have missed that allows you to reset autonumbers / IDs to 1 and delete all content, or just speed up what I currently do?

+1  A: 

Here'a a quick way to delete all of the data in a table:

TRUNCATE TABLE YourTableName

You could write a script that would truncate all of your tables.

The alternative is to just DROP the table and re-create it.

If you really want to drop all data, then you could detach the database and create a brand new one; it's a bit extreme, but possibly faster than dropping everything first.

RickNZ
Many thanks +1, the reason for resetting is simply I have been deleting all table content and the number generates itself, when working on relations, it is easier to remember that it will be one instead of going in to data view to verify what it is... I know I can write a script or similar, but this project has grown so big for something that was meant to be one days work, I just don't want to complicate things any more than they are already!
Wil
+3  A: 

There are a few options you could take, the "fastest" really depends on your database.

To firstly answer your questions on seeding, etc - TRUNCATE TABLE will delete all information in a table (very fast, as it is not logged) and will reset your identity column.

eg:

TRUNCATE TABLE dbo.table

http://msdn.microsoft.com/en-us/library/aa260621%28SQL.80%29.aspx

The significant restriction here is that you cannot use it on a table that is referenced by another table. In this case you can use a standard delete and then use DBCC CHECKIDENT

eg:

DELETE FROM dbo.table
GO
DBCC CHECKIDENT(dbo.table, reseed, 0)

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

Remember with delete to make sure you delete information in the correct order (i.e. taking into account foreign keys).

Another approach I often use is simply writing a complete tear-down / rebuild script when I want to reset the database. The basic premise is to tear down, or drop all database objects at the beginning of the script and then recreate them. This is not necessarily a solution for all scenarios, but for basic tasks works well for me. To avoid errors I would usually add my drop statements in IF statements, eg:

IF EXISTS 
(
     SELECT * 
     FROM information_schema.tables 
     WHERE table_name = 'table' AND table_schema = 'dbo'
)
BEGIN
    DROP TABLE dbo.table
END
Chris
Many thanks + 1
Wil
I can't get truncate working - it randomly changes indexes - sometimes starts from 3, other times 1 but your second method/example works perfectly... I copied and pasted it 6 times with different names and can run together - it resets everything and does **exactly** what I need. Many thanks.
Wil
Thanks, happy to help :) Sounds odd behavior with the truncate, if you ever start dealing with very large amounts of data you may have to revisit this method - but if you get there let us know and we can help you resolve the issue
Chris
+1  A: 

Why don't you write some T-SQL code to delete (or truncate, even quicker) all your tables? Be careful to take into consideration your integrity rules while clearing the tables: allways clean the tables containing the foreign key before cleaning the one containing the primary key.

Philippe Grondier
Many thanks + 1
Wil
+1  A: 

Hi,

If you just need to clear out data then just write a script to truncate all the data in each table. The truncate command also resets any IDENTITY fields as well.

TRUNCATE TABLE myTable

For each table you have. Then just run that script each time.

Leigh Shayler
Many thanks + 1
Wil
A: 

As others have suggested I find it preferable to maintain a script that builds the database from scratch and can tear down the database prior to rebuilding it. Develop this script just as you'd develop the rest of the application. I find it easier to understand the database through a script than by building it through a GUI, especially where there are complex relationships, triggers and so on.

It's also useful if you have other developers, and perhaps quicker and less prone to errors than copying your working database and handing it to another developer.

On release you can freeze that script and then create delta scripts for the next release which has just the changes from the initial schema to the new. This could also tear down the new objects created in the delta before recreating them so it can be easily re-run without having to wipe the entire database.

tjmoore