I have a database which consist of 300 tables with data in it. I need to delete all the data inside each tables. I tried to truncate all tables but then I got an error that the process could not be completed because one of the column in a table is a foreign key. Is there other way to resolve my problem? Thanks.
You need to either:
remove all the foreign keys, truncate, then re-create FKs;
disable all the foreign keys, delete (not truncate), then re-enable FKs; or,
delete from child tables first.
The latter may not be possible if you're lucky enough to have circular references, and it can still be complicated even without circular references. The first two are also relatively complex, but I solved a very similar problem for a different user recently (and I find these easier than trying to determine the proper delete order):
Temporarily disable all foreign key constraints
Another idea is to perform a simpler and more complete wipe:
script the tables (and other objects obviously), drop the database and re-create it; or,
create a copy of the database, and use Visual Studio / SSDT or a 3rd party schema comparison tool to create all of the objects in the empty database (then you can drop the old database and rename the new one).
Try this : A quick way of doing it .sp_msforeachtable is an undocumented SP so there's a risk in using them. I came up with this answer using Aaron Logic by disabling the constraints used in his answer.
use [YourDB]
Go
EXEC sp_MSForEachTable 'ALTER TABLE ? NOCHECK CONSTRAINT ALL'
EXEC sp_MSForEachTable 'Truncate Table ?'
EXEC sp_MSForEachTable 'ALTER TABLE ? CHECK CONSTRAINT ALL'
Related
scrp.Options.ScriptForAlter -- I suppose it scripts an ALTER TABLE instead of a CREATE TABLE
scrp.Options.ScriptForCreateDrop -- I'd guess it scripts a DROP TABLE and only afterwards a CREATE TABLE ?
My DB is fairly large and I'm still using Management Studio for script generation, so I'd like to know if someone else already found out the meaning of those options.
I am working on SDL Server 2008 R2, where I generated a schema-only database script. The generated script is as follows:
ALTER TABLE [dbo].[ConsoleServer] WITH CHECK ADD CONSTRAINT [FK_ConsoleServer_RackUnits] FOREIGN KEY([RackUnitID])
REFERENCES [dbo].[RackUnits] ([UnitID])
GO
ALTER TABLE [dbo].[ConsoleServer] CHECK CONSTRAINT [FK_ConsoleServer_RackUnits]
I have these 2 questions:-
I know that the first line is responsible to create a FK between two DB tables. but what is the purpose of the following :
ALTER TABLE [dbo].[ConsoleServer] CHECK CONSTRAINT [FK_ConsoleServer_RackUnits]
In general, why does the DB script have the word GO. Now if I remove it the script will be executed well on the destination DB, so why it is included in the script prior to any statement?
The ALTER TABLE ... CHECK CONSTRAINT ... line enables the constraint. You can add a constraint and leave it disable (while you clean up the data for example). See more here
GO is a batch separator, it's only recognized by SSMS. Some statements, such as CREATE PROCEDURE... requires it to be the first statement in the batch. You can type it out in a new file, or use GO to terminate the previous batch. Don't send GO from your application through OLEDB or ADO.NET though.
exec dbms_metadata.set_transform_param(DBMS_METADATA.SESSION_TRANSFORM, 'CONSTRAINTS_AS_ALTER', TRUE);
SELECT DBMS_METADATA.GET_DDL(object_type, object_name, owner) FROM all_OBJECTS WHERE
OWNER = 'USERNAME' AND OBJECT_TYPE = 'TABLE';
When I run these commands, unfortunately I am getting the alter statements after each table. I would prefer to have the DDL generated for all of my tables, then have that followed by the alter statements to set up the constraints. Currently, the alter statement runs and fails for some tables because the table being referenced has not been created yet.
I have seen this command:
select dbms_metadata.get_ddl('CONSTRAINT',constraint_name) from user_constraints;
But to use that wouldn't I have to somehow tell GET_DDL to not generate any constraints at all?
Is there some way to just make the tables created in the right order?
Thanks!
You can tell GET_DDL to not generate referential integrity constraints by running:
exec dbms_metadata.set_transform_param(DBMS_METADATA.SESSION_TRANSFORM, 'REF_CONSTRAINTS', FALSE);
Then run the constraint DDL, but only where constraint_type = 'R'. (You do not want to run all of the constraints separately, else you will need to generate the primary keys before the foreign keys, and run into the same dependency issue.)
See here for the list of transform parameters.
How can I truncate all tables of a database?
Why would you want to truncate all tables? If you want an empty database, why not run the CREATE script of the database?
If you want to Truncate a table referenced by a foreign key, you will have to drop the FK constraint first. Disabling constraints is something that is not possible anymore in recent versions of SQL Server.
You can see this post : how-do-you-truncate-all-tables-in-a-database-using-tsql
I use the script
EXEC sp_MSForEachTable 'ALTER TABLE ? NOCHECK CONSTRAINT ALL'
EXEC sp_MSForEachTable 'DELETE FROM ?'
EXEC sp_MSForEachTable 'ALTER TABLE ? CHECK CONSTRAINT ALL'
GO
Reset Auto-Increment? I'm not sure if you understand correctly how this works.
Primary Key incrementing is handled by SQL Server using the IDENTITY specification. If your tables have got no data in them, it will always start from 0.
If I were you, I'd go have a flick through your programming books and pick up some basic database knowledge as it sounds like you're missing some fundamental facts there.
Can anybody help me with this?
I prefer if I don't have to explicitly list the table names.
Saw this before...
exec sp_MSforeachtable "DROP TABLE ? PRINT '? to be dropped' "
Source - http://sqlserver-qa.net/blogs/t-sql/archive/2008/05/20/4266.aspx
How about dropping the database? DROP DATABASE <database name>
Of course, that's rough on stored procedures, triggers, etc. But if the purpose is to eliminate all the tables in order to recreate them, it makes sense that you'd recreate all the other associated components as well, such as indexes.