Merge process could not update the list of subscriptions

[Jim]

We've got a problem with a 2005 publisher to a 2005 subscriber. We had a
merge subscription that got four months out of date. It was fine when the
two machines were back-to-back (snapshot applied fine and all seemed well)
but when we moved it to site we forgot to change the publisher's alias's IP
address from 192.168.x.y to its real-world IP. Our fault entirely.

When we corrected the IP it tried to go through but gave the error:

The merge process could not update the list of subscriptions

and failed.

In attempting to correct this we broke the subscription off (deleted it from
the publisher) and tried to push it out again as a new subscription. It
applied the snapshot but then gave the same error somewhere towards the end
of the stage where it's creating triggers.

We've tried pushing it to a different database on the same subscriber
machine and that works, so it's something to do with the interaction between
the publisher's db and the subscriber's db. I'm guessing that the publisher
in some way still thinks the subscription exists.

Doing a 'select * from sysmergesubscri ptions where
subscriber_serv er='STATION1'

lists 15 rows, of which all bar 4 are status 1 (active) - the others are 2
(deleted).



Given that there are now _no_ subscriptions to the subcriber from the
publisher am I safe to delete all entries in sysmergesubscri ptions where
subscriber_serv er is 'STATION1' or would this just make matters worse?

If that's not the way I should be proceeding I'd welcome suggestions. Any
thoughts/ideas gratefully received.

Thank you.

Jim
--
http://www.ursaMinorBeta.co.uk http://twitter.com/GreyAreaUK

"Sometimes when I talk to a Windows person about using a Mac,
I feel like I'm explaining Van Halen to a horse." Merlin Mann

[Jim]

Re: Merge process could not update the list of subscriptions

On 2008-05-15, Jim <jim@magrathea. plus.comwrote:

>
We've tried pushing it to a different database on the same subscriber
machine and that works, so it's something to do with the interaction between
the publisher's db and the subscriber's db. I'm guessing that the publisher
in some way still thinks the subscription exists.

I forgot to add - we also tried creating a second publication at the publisher
that contained a single table from the problem subscrition, and tried to
push that out. Same result, same error.

Jim
--
http://www.ursaMinorBeta.co.uk http://twitter.com/GreyAreaUK

"Sometimes when I talk to a Windows person about using a Mac,
I feel like I'm explaining Van Halen to a horse." Merlin Mann