Sunday, March 11, 2012

Double replication

I have merge replication set up on Server A with the distributor also on Server A. I want to set up transactional replication on this same Server A, but with the subscribing Server B set up as the distributor. Is this possible? I've tried creating a ne
w publication, but it won't give me the option to use Server B as the distributor--I think probably because Server A is already configured. Is there anyway to achieve this? Thank you.
no each Publisher server has a single distributor.
Multiple publishers can share the same distribution database on a single
distributor, or they can have their own seperate distribution databases on a
single distributor, but a single publisher can only have 1 distribution
database which can be on the publisher, distributor or subscriber.
"Andrea Worley" <k_rage@.hotmail.com> wrote in message
news:C05E8AD2-6D42-4CE0-BF50-245381D2E841@.microsoft.com...
> I have merge replication set up on Server A with the distributor also on
Server A. I want to set up transactional replication on this same Server A,
but with the subscribing Server B set up as the distributor. Is this
possible? I've tried creating a new publication, but it won't give me the
option to use Server B as the distributor--I think probably because Server A
is already configured. Is there anyway to achieve this? Thank you.
|||So, is it possible to set up trans replication to another server even though the existing publication is for merge replication? (And by your answer, I would be using the same distributor) And if so, will it be possible to disable the trans replication in
the future without messing up the existing merge publication? Thank you for your answer.
-- Hilary Cotter wrote: --
no each Publisher server has a single distributor.
Multiple publishers can share the same distribution database on a single
distributor, or they can have their own seperate distribution databases on a
single distributor, but a single publisher can only have 1 distribution
database which can be on the publisher, distributor or subscriber.
"Andrea Worley" <k_rage@.hotmail.com> wrote in message
news:C05E8AD2-6D42-4CE0-BF50-245381D2E841@.microsoft.com...
> I have merge replication set up on Server A with the distributor also on
Server A. I want to set up transactional replication on this same Server A,
but with the subscribing Server B set up as the distributor. Is this
possible? I've tried creating a new publication, but it won't give me the
option to use Server B as the distributor--I think probably because Server A
is already configured. Is there anyway to achieve this? Thank you.
|||yes, you can replicate a table that is part of a merge publication using
transactional publication as long as its not transactional publication with
queued updating.
You can drop the table from the merge publication or the transactional
publication without breaking either publication.
The publications are completely independent of each other (except when you
are using queued with merge).
"Andrea Worley" <anonymous@.discussions.microsoft.com> wrote in message
news:C97EA05A-916E-4713-8319-05D794082EF1@.microsoft.com...
> So, is it possible to set up trans replication to another server even
though the existing publication is for merge replication? (And by your
answer, I would be using the same distributor) And if so, will it be
possible to disable the trans replication in the future without messing up
the existing merge publication? Thank you for your answer.
>
> -- Hilary Cotter wrote: --
> no each Publisher server has a single distributor.
> Multiple publishers can share the same distribution database on a
single
> distributor, or they can have their own seperate distribution
databases on a
> single distributor, but a single publisher can only have 1
distribution[vbcol=seagreen]
> database which can be on the publisher, distributor or subscriber.
> "Andrea Worley" <k_rage@.hotmail.com> wrote in message
> news:C05E8AD2-6D42-4CE0-BF50-245381D2E841@.microsoft.com...
also on
> Server A. I want to set up transactional replication on this same
Server A,
> but with the subscribing Server B set up as the distributor. Is this
> possible? I've tried creating a new publication, but it won't give
me the
> option to use Server B as the distributor--I think probably because
Server A
> is already configured. Is there anyway to achieve this? Thank you.
>
>
|||Hilary, I tried creating another publication for trans rep using the same distributor that is set up for the merge rep. I got the error: Error 14294 Supply either @.job_id or @.job_name to identify the job.
Searching on this error, I saw in a different post that you wrote that it is caused by having duplicate agent names (your post is below). How do I resolve this issue if I am setting up trans replication using the wizards? I don't see how I can change th
e names. Do I have to script out the replication for this to work? Thanks.
[vbcol=seagreen]
if you are keeping the existing publications/subscriptions intact and
creating new subscriptions/publications based on the scripts you have to
modify the publication name, the log reader agent name, the snapshot agent
name, and the distribution agent name. Otherwise you will get errors like
this.[vbcol=seagreen]
-- Hilary Cotter wrote: --
yes, you can replicate a table that is part of a merge publication using
transactional publication as long as its not transactional publication with
queued updating.
You can drop the table from the merge publication or the transactional
publication without breaking either publication.
The publications are completely independent of each other (except when you
are using queued with merge).
"Andrea Worley" <anonymous@.discussions.microsoft.com> wrote in message
news:C97EA05A-916E-4713-8319-05D794082EF1@.microsoft.com...
> So, is it possible to set up trans replication to another server even
though the existing publication is for merge replication? (And by your
answer, I would be using the same distributor) And if so, will it be
possible to disable the trans replication in the future without messing up
the existing merge publication? Thank you for your answer.[vbcol=seagreen]
single
> distributor, or they can have their own seperate distribution
databases on a
> single distributor, but a single publisher can only have 1
distribution[vbcol=seagreen]
> database which can be on the publisher, distributor or subscriber.
> "Andrea Worley" <k_rage@.hotmail.com> wrote in message
> news:C05E8AD2-6D42-4CE0-BF50-245381D2E841@.microsoft.com...
also on
> Server A. I want to set up transactional replication on this same
Server A,
> but with the subscribing Server B set up as the distributor. Is this
> possible? I've tried creating a new publication, but it won't give
me the
> option to use Server B as the distributor--I think probably because
Server A[vbcol=seagreen]
> is already configured. Is there anyway to achieve this? Thank you.
|||create another publication perhaps in your pubs database and replicate to
your northwind database. If this works you have a localized problem with
your publication database.
Script out your publication and subscriber and then drop it.
Change the publication name throughout your script to something you have not
used before.
Go through your entire script and remove all references to
@.snapshot_job_name, @.logreader_job_name, @.qreader_job_name if you have one.
Re run your script.
"Andrea Worley" <anonymous@.discussions.microsoft.com> wrote in message
news:F356A1A1-E061-4F90-8905-3D41ECC16DA4@.microsoft.com...
> Hilary, I tried creating another publication for trans rep using the same
distributor that is set up for the merge rep. I got the error: Error 14294
Supply either @.job_id or @.job_name to identify the job.
> Searching on this error, I saw in a different post that you wrote that it
is caused by having duplicate agent names (your post is below). How do I
resolve this issue if I am setting up trans replication using the wizards?
I don't see how I can change the names. Do I have to script out the
replication for this to work? Thanks.
> if you are keeping the existing publications/subscriptions intact and
> creating new subscriptions/publications based on the scripts you have to
> modify the publication name, the log reader agent name, the snapshot agent
> name, and the distribution agent name. Otherwise you will get errors like
> this.
> -- Hilary Cotter wrote: --
> yes, you can replicate a table that is part of a merge publication
using
> transactional publication as long as its not transactional
publication with
> queued updating.
> You can drop the table from the merge publication or the
transactional
> publication without breaking either publication.
> The publications are completely independent of each other (except
when you
> are using queued with merge).
> "Andrea Worley" <anonymous@.discussions.microsoft.com> wrote in
message[vbcol=seagreen]
> news:C97EA05A-916E-4713-8319-05D794082EF1@.microsoft.com...
even
> though the existing publication is for merge replication? (And by
your
> answer, I would be using the same distributor) And if so, will it be
> possible to disable the trans replication in the future without
messing up[vbcol=seagreen]
> the existing merge publication? Thank you for your answer.
on a[vbcol=seagreen]
> single
> databases on a
> distribution
subscriber.[vbcol=seagreen]
> also on
same[vbcol=seagreen]
> Server A,
Is this[vbcol=seagreen]
give[vbcol=seagreen]
> me the
because[vbcol=seagreen]
> Server A
Thank you.[vbcol=seagreen]
|||The create publication does not work in the pubs database either. I think for now I am going to just set up some DTS jobs to bulk copy the data to a new database. Thanks for your help.
|||In this case you need to disable publishing (through the tools menu, select
Replication and then click disable publishing).
Then re-install and try again. If this fails try to reapply sp3.
"Andrea Worley" <anonymous@.discussions.microsoft.com> wrote in message
news:F5126947-6463-4AD5-9220-42B2FAE2CB7A@.microsoft.com...
> The create publication does not work in the pubs database either. I think
for now I am going to just set up some DTS jobs to bulk copy the data to a
new database. Thanks for your help.

No comments:

Post a Comment