0

I had created identical databases in different environments: Dev and QA. While doing the development, I have changed a few tables in the Dev database. How do I change the QA database to make it again identical to the Dev database in terms of tables (and constraints)?

I checked the below link:

[Copy one database to another database

Steps in the above link did not directly work because the tables and constraints already existed in the second database. I did modification in the sql file after the steps

I followed the below steps:

  1. Right-click on the database you want to copy
  2. Choose 'Tasks' > 'Generate scripts'
  3. 'Select specific database objects' and Check 'Tables'
  4. Click on Next. Again click on Next.

This exports .sql file to the path shown while following the above steps.

  1. I edited the script file and changed the database name to the QA database name (at the top of the script).

  2. After this added the below line above every create table statement as the table exist.

    DROP TABLE IF EXISTS tablename;

On running the query, I get an error message saying

Could not drop object tablename because it is referenced by a FOREIGN KEY constraint.

How do I change the second database to make it identical to the first database in terms of tables (and constraints)?

Thank You

Saurabh Rana
  • 168
  • 3
  • 22
  • So are you simply looking to copy the data, and not the objects? Adding `DROP TABLE IF EXISTS`, won't help prior, because the first table the script will create is the table at the "bottom" of the relationship tree; which would need to be the first table created but the last table deleted. – Thom A Sep 06 '19 at 15:43
  • You can also disable all constraints checks in the target database and re-enable after your copy, see: https://stackoverflow.com/questions/737115/turn-off-constraints-temporarily-ms-sql/773094#773094 – Jonathan Larouche Sep 06 '19 at 15:48
  • @JonathanLarouche . Does that mean to follow these steps? 1) Disable all constraints temporarily 2) Edit the script and remove the line that creates the constraints (because constraints are already there just in disabled mode) 3) Run the script 4) Enable the constraints again. – Saurabh Rana Sep 09 '19 at 12:02
  • @SauravR, yes that should work, But It might fails re-enabling constraints if data integrity is not valid at the end – Jonathan Larouche Sep 09 '19 at 14:39

2 Answers2

1

Well, the most straight forward solution would be to drop all constraints first. You could add a drop constraint per constraint above your drop table lines, though that may be tedious.

An answer to this question has a script that drops every constraint in a database and table. You could omit the table name param in the where.

But, since you're destroying everything in the database, it might be easiest to delete and recreate the database. Then you wouldn't need to add the drop table statements to the create script from dev.

memtha
  • 797
  • 5
  • 24
0

In your scripts, separate tables creation, from insertion of records, for later.

Example (before):

create table one ...
insert into table one ...
create table two ...
insert into table two ..
create table three ...
insert into table three ..

Example (after)

create table one ...
create table two ...
create table three ...

insert into table one ...
insert into table two ..
insert into table three ..

If you have foreign constraints, check that the destination tables (primary table or master table), are created and filled first, than the source tables (secondary table or slave table).

Example (before):

create table one 
  (int onekey primary key, int threekey foreing key)
create table three ...
 (int threekey primary key)

insert into table one ...
insert into table three ..

Example (after):

create table three ...
   (int threekey primary key)
create table one 
   (int onekey primary key, int threekey foreing key)

insert into table three ..
insert into table one ...

And, finally, if you use automatic of self generated keys, turn off before table insertion, and turn on back, after table insertion, because the DB server may assign new keys to destination tables, and source tables, may expect the previous keys.

umlcat
  • 4,091
  • 3
  • 19
  • 29