Question

I’m struggling to find a suitable solution to this. I have a fairly large SQL Server 2008 Express database containing 60+ tables (many with key constraints) and a whole bunch of data.

I need to essentially copy all of these tables and the data and the constraints exactly from one database to another. I’m basically duplicating website A – to produce an exact copy (website B) on a different domain so we end up with two completely identical websites running in parallel, each with their own identical database to begin with.

Database A is up and running on website A. Database B is set up and has it’s own user. I just need to get the tables and the data intact from A to B. I can them modify my web.config connection to use the log-in credentials for database B and it should work.

I’ve tried backing up database A and restoring to database B via Management Studio Express, but it tells me:

System.Data.SqlClient.SqlError: The backup set holds a backup of a database other than the existing ‘database-B’ database.
(Microsoft.SqlServer.Smo)

I’ve also tried right clicking database A in Management Studio Express and going to Tasks > Generate scripts. But when I do this and run the SQL scripts on database B I get a whole load of errors to do with foreign keys etc as it imports the content. It seems like it’s doing the right thing, but can’t handle the different keys/relationships.

So does anyone know of a simple, sure-fire way of getting my data 100% exact and intact from database A to database B?

I think I used SQL Server Database Publishing Wizard to do something like this about 5 years ago, but that product seems to be defunct now – I tried to install it and it wanted me to regress my version of SQL Server to 2005, so I’m not going there!

Answer 1

Don’t use the UI for this. If you’re not familiar with the various aspects of BACKUP/RESTORE the UI is just going to lead you down the wrong path for a lot of options. The simplest backup command would be:

BACKUP DATABASE dbname TO DISK = 'C:\some folder\dbname.bak' WITH INIT;

Now to restore this as a different database, you need to know the file names because it will try to put the same files in the same place. So if you run the following:

EXEC dbname.dbo.sp_helpfile;

You should see output that contains the names and paths of the data and log files. When you construct your restore, you’ll need to use these, but replace the paths with the name of the new database, e.g.:

RESTORE DATABASE newname FROM DISK = 'C\some folder\dbname.bak'
  WITH MOVE 'dbname' TO 'C:\path_from_sp_helpfile_output\newname_data.mdf',
  MOVE 'dbname_log' TO 'C:\path_from_sp_helpfile_output\newname_log.ldf';

You’ll have to replace dbname and newname with your actual database names, and also some folder and C:\path_from_sp_helpfile_output\ with your actual paths. I can’t get more specific in my answer unless I know what those are.

---

** EDIT **

Here is a full repro, which works completely fine for me:

CREATE DATABASE [DB-A];
GO

EXEC [DB-A].dbo.sp_helpfile;

Partial results:

name     fileid filename
-------- ------ ---------------------------------
DB-A     1      C:\Program Files\...\DB-A.mdf
DB-A_log 2      C:\Program Files\...\DB-A_log.ldf

Now I run the backup:

BACKUP DATABASE [DB-A] TO DISK = 'C:\dev\DB-A.bak' WITH INIT;

Of course if the clone target (in this case DB-B) already exists, you’ll want to drop it:

USE [master];
GO
IF DB_ID('DB-B') IS NOT NULL
BEGIN
  ALTER DATABASE [DB-B] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
  DROP DATABASE [DB-B];
END
GO

Now this restore will run successfully:

RESTORE DATABASE [DB-B] FROM DISK = 'C:\dev\DB-A.bak'
  WITH MOVE 'DB-A'     TO 'C:\Program Files\...\DB-B.mdf',
       MOVE 'DB-A_log' TO 'C:\Program Files\...\DB-B_log.ldf';

If you are getting errors about the contents of the BAK file, then I suggest you validate that you really are generating a new file and that you are pointing to the right file in your RESTORE command. Please try the above and let me know if it works, and try to pinpoint any part of the process that you’re doing differently.