I'm not sure how can I replicate the table which is part of nosync
transactional replication? I have to add a column in that table and to
replicate again. I'm using no-sync initialization?
Thanks,
BaniSQL
I want to add some additional explainations regarding this issue. I'm
currently running transactional replication with nosync initialization. In
one of the articles - replicating table I want to add 2 additional fields for
future usage. Some good explainations exists in the www.replicationanwers.com
website, but I'm not so sure what I have exactly to do? Removing the table
from replication, adding 2 additional fileds ... thereafter do I have to run
all the process from the beginning or I can create the same table in the
subscriber with the new structure, make sure that all records exists in
subscriber same as they are in publisher, and drop the Push subscribtion and
run again (with no-sync initialization, knowing that the structure and data
already exists in the subscriber?)
Can somebody give me some additional informations if I'm right or not?
Thanks, BaniSQL.
"BaniSQL" wrote:
> I'm not sure how can I replicate the table which is part of nosync
> transactional replication? I have to add a column in that table and to
> replicate again. I'm using no-sync initialization?
> Thanks,
> BaniSQL
|||Interesting. I just tried this and even though my subscription was a nosync
one, using sp_repladdcolumn on the publisher propagated the change to the
subscriber, along with the new set of stored procedures. This was quite
unexpected for me as well, but it means that you don't need to jump through
loads of hoops here and can make your changes quite easily.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com .
|||Hi Paul,
As I understood it worked simply by only running sp_repladdcolumn in the
publisher database, even without generating custom procedures for
INSERT/UPDATE/DELETE on the Subscriber for this article/table?
Thanks,
BaniSQL.
"Paul Ibison" wrote:
> Interesting. I just tried this and even though my subscription was a nosync
> one, using sp_repladdcolumn on the publisher propagated the change to the
> subscriber, along with the new set of stored procedures. This was quite
> unexpected for me as well, but it means that you don't need to jump through
> loads of hoops here and can make your changes quite easily.
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com .
>
>
|||Exactly - I tried it in a test environment and it worked fine.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com .
Monday, February 13, 2012
Adding column in replicated table with nosync initialization
Labels:
adding,
column,
database,
initialization,
microsoft,
mysql,
nosync,
nosynctransactional,
oracle,
replicate,
replicated,
replication,
server,
sql,
table,
toreplicate
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment