Detach/attach is breaking the link between replication and these databases.
Depending on some specifics, there may be several ways to get what you want to do.
First, knowing what version and edition will tell us what tools we have to work with.
Off the top of my head, you could tear down your replication setup, detach/attach, and recreate the replication config. Not pretty, but you could automate it with scripts.
You can use backup/restore instead of detach/attach.
You could possibly create database snapshots of all the databases, and then to reset use RESTORE DATABASE <dbname> FROM DATABASE_SNAPSHOT=<snapshot name> to limit the amount of data being moved.
|||The situation is: my project is partitioned in two db servers, which all use SQL Server 2005. db01 is on server01 and has replication in server02, db02 is on server02 and has replication in server01. Each time there is a new build of the project, I have to do performance test for it. Unluckily, prepare for the performance test data need 2 days, each time do deployment for the new build, the db will be re-deployed, so all data will lose. I have keep the old build database and data, the most important thing is how to resotore data into new build. I ever used "bcp" to export and import data. But I don't know when replication will end up. So I think maybe detach/attach can help.
No comments:
Post a Comment