Merge Replication - Invalid Subscriptions

Mike Fredrick

unread,

Jul 18, 2001, 1:42:53 PM7/18/01

to

Greetings List,

I hope somebody can help me out here... here's my situtation.

SS2K on 2 machines, on on DMZ one on Internal. Both have connectivity to
each other on 1433

Internal is the distributor and the publisher. A push subscription is set up
to send data from Internal to DMZ

I have the standard setup going and when I create the push subscription it
runs the snapshot agent just fine,
transports and imports the snapshot.. then when it looks like it works OK
the Merge Agent says:

The subscription to publication 'V3ReplDEV' is invalid.

Error Text:

The subscription to publication 'V3ReplDEV' is invalid.
(Source: Merge Replication Provider (Agent); Error number: -2147201019)
----------------------------------------------------------------------------
-----------------------------------
The remote server is not defined as a subscription server.
(Source: XXX.XXX.XXX.XXX (Data source); Error number: 14010)
----------------------------------------------------------------------------
-----------------------------------

So every time I run the merge agent after this it repeats the same process
(my bulk insering a new snapshot)

I have created another subscription on the same internal machine to a local
database. That subscription works
fine so I think there is a permissions issue. Unfortunatly, I really don't
know what permissions would be causing
the problem.. If anyone can help I would greatly appreciate it!

Thanks Much!
Mike Fredrick

TSVK

unread,

Jul 18, 2001, 2:49:40 PM7/18/01

to

The subscription server is defined with the servername but the replication
agent is trying to connect with IP address. (To be precise, the IP address
is not defined in the sysservers of the publisher database)
This is the problem. Instead of adding the IP address to sysservers of
publisher , I suggest that you make an alias with cliconfg.exe or lmhosts
type mapping between subscriber name and IP address so that the replication
agent knows only about the server name rather than IP address.

"Mike Fredrick" <Mike.F...@polarisind.com> wrote in message
news:uNgoWD7DBHA.1896@tkmsftngp07...

Mike Fredrick

unread,

Jul 18, 2001, 3:04:29 PM7/18/01

to

Interesting,

Can you explain this a bit? I looked in my sysservers table (master DB) on
my publisher and I did see the internal server (stored by hostname) and the
dmx server (stored by IP)Is the fact that it's intermingled the issue? (one
is using hostname, one using IP) If so, then can I use WINS on the internal
to point to the external IP and use refer to the host that way?

Thanks so much!

Mike

"TSVK" <vija...@hotmail.com> wrote in message
news:eQCtnp7DBHA.1652@tkmsftngp02...

John Gose

unread,

Jul 18, 2001, 5:36:50 PM7/18/01

to

Mike,

Vijayts is correct. Use the SQL client Network utility on your publisher
to define an alias for the server on the DMZ. Register that server as a
subscriber and then push your subscription.

John Gose
MCDBA
Microsoft SQL Server Support

Mike Fredrick

unread,

Jul 21, 2001, 7:02:23 PM7/21/01

to

Thanks Much all

I used the LMHOSTS local file of each NT machine and it worked like a
charm!!

Thanks again!
Mike

"John Gose" <John_Pleas...@microsoft.com> wrote in message
news:38YeCH9...@cppssbbsa01.microsoft.com...

John Gose

unread,

Jul 22, 2001, 10:41:13 AM7/22/01

to

Glad to be able to help.
--------------------
| From: "Mike Fredrick" <Mike.F...@polarisind.com>
| References: <uNgoWD7DBHA.1896@tkmsftngp07> <eQCtnp7DBHA.1652@tkmsftngp02>
<38YeCH9...@cppssbbsa01.microsoft.com>

| Subject: Re: Merge Replication - Invalid Subscriptions

| Date: Sat, 21 Jul 2001 18:02:23 -0500
|
<Snip of Header Stuff>

Yves

unread,

Jul 24, 2001, 10:26:55 AM7/24/01

to

Thanks,

This was the solution to the problem I coped with a few
weeks ago.
I thought the problem was that port 1433 was not open at
the publisher/originating side (for incoming traffic), so
we opened it a few days ago for certain IP's, but we had
the same result (not valid subscription).

Thanks again.

>.
>