Scenario:
servers in the same domain:
Create the publisher/distributor
Create publication "MyPublication"
Create push subscription to Server B "PushToB"
Logon onto Server B
Create Pull Subscription "PullFromA"
Cannot create Pull Subscription...
A quick google search and I find
"When you create a pull subscription and a push subscription for the
publication already exists for the Subscriber, an error message informs you
that the push subscription already exists and that you should drop any push
subscriptions before proceeding. When you create a pull subscription, and
another pull subscription to the same publication already exists, you will be
required to drop the existing subscription before adding the new one unless
the first subscription has expired."
Logon to Publisher
Delete Push subscription "PushToB" on publisher
logon to subscriber
Create Pull subscription "PullFromA" on subscriber
logon to publisher
Create Push subscription "PushToB" on publisher
Push subscription fails....
When I create a publication for each on the publisher, it works.
What am I missing?
MJ
Hi Pual;
No, you are dealing with ignorance on my end (thank you for your patience).
Context:
I need to changes at the publisher to push to the subscriber
I then need changes at the subscriber to push to the publisher.
Test envrironment Solution:
I set up a merge publication on the publisher then loged onto the
subscriber and created a pull subscription. Every thing is fine.
this is sql server 2000.
My biggest challenge has been reading so many sources and I am getting
confused:
Microsofts "Patterns and Practices" Data Patterns
Microsoft's High Availablitity Volume 1 and Volume 2
Hillary's "Transaction ad Snapshot"
I even pleaded Hillary to publish his promised 2nd book on Merge Replication.
"Paul Ibison" wrote:
> I'm not sure I follow. You are restricted from having a pull and push on the
> subscriber to the same publication and the same subscriber database. Your
> scenario arrives at this same point each time but in a different order
> (pushtob is still created after pullfroma) - or am I misreading something
> here.
> Cheers,
> Paul Ibison
>
>
|||Question: Merge or Transactional bidirectional replication?
I am looking for a Bi-directional merge replication solution
Does the subscriber go offline? Yes
Does the subscriber modify the same data as the publisher? Yes
What happens when they conflict (assuming the subscriber isn't connected to
the publisher)? Publisher has ultimate determination.
How many subscribers do you have?
A vague answer is 12
A better answer is I use a filter and create a separate publication for each.
Do the subscribers need to be distinguished? Yes
"Paul Ibison" wrote:
> OK - I see. The term Push and Pull refer to where the work is being done
> (simplified a bit). The actual work remains the same, so you need either a
> push or a pull subscription but not both. If you want bidirectional
> replication then the choice usually is between merge and transactional. The
> latter can be queued, immediate updating or bidirectional or peer-to-peer.
> Many posibilities here. Some questions will help narrow down a bit. Does the
> subscriber go offline? Does the subscriber modify the same data as the
> publisher? What happens when they conflict (assuming the subscriber isn't
> connected tot he publisher). How many subscribers do you have? Do the
> subscribers need to be distinguished?
> If you have clear answers to these questions and hopefully I've not left too
> many out, then we can probably tell you exactly what type of replication you
> need
> HTH,
> Paul Ibison
>
>
|||Thank you for patience and dedication from a dedicated Ibison and Cotter
follower.
MJ
"Paul Ibison" wrote:
> OK - it sounds like merge is your best option then. You don't necessarily
> need a separate publication per subscriber - dynamic subscriptions might do
> the trick for you.
> HTH,
> Paul Ibison
>
>
>
