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 sysmergesubscriptions where
subscriber_server='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 sysmergesubscriptions where
subscriber_server 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
