May 3, 2010 at 8:35 am
Hi folks, we have a deployment coming up soon which would impact replication to a reporting server. As far as I know, is it possible to trick replication to use an alternate table by renaming it? I got some good ideas from replicationanswers.com and I think the sequence I would take is:
1. Verify that the number of rows in the publisher and subscriber are exactly the same.
2. Take table out of replication
3. Create a temp table that is identical to original table in every way (constraints/indexes/data/etc.)
4. Rename all constraints/indexes of old table to backup name (e.g. PK_backup) and rename the table to Table_backup
5. Rename the temp table to original table name along with restoring contraints/etc. to original names
6. The final step, before adding the article back to replication is to run sp_scriptpublicationcustomprocs to recreate the procs on the subscriber.
7. Add article back without reinitializing the snapshot.
Is this a correct way to go about this?
Thanks.
Gaby________________________________________________________________"In theory, theory and practice are the same. In practice, they are not." - Albert Einstein
June 4, 2010 at 2:41 am
I assume after you have added the new table in you will run the snapshot agent and then distribute that new table..correct.
Once you drop an article from replication you can do whatever you want to it before adding it back...
Sounds like you are just following the standard approach to modifying a table that is part of replication (On a SQL2K box)..rather than tricking it ;)...or am I missing something
HTH
Graeme
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply