Wednesday, March 21, 2012
Problem with snapshot replication
only move data for the previous day. The snapshot agent runs, and creates
the .bcp file. I check the MSsnapshot_history table, and the snapshot
completes successfully, and the commands are posted to the distribution
database. I run sp_browsereplcmds, and I can see the commands in there.
The data is not getting moved to my subscriber. I have no idea why. What
can I check to figure this out? I have dropped the subscription, and
re-subscribed, but it just doesn't work.
Please help!
You have to make sure the distribution agent is also running, and not
failing with errors.
HTH,
Vyas, MVP (SQL Server)
SQL Server Articles and Code Samples @. http://vyaskn.tripod.com/
"captainkt" <nothing@.fake.com> wrote in message
news:OLA7eR$TFHA.2940@.TK2MSFTNGP10.phx.gbl...
I have a snapshot publication, which does not seem to be moving the data. I
only move data for the previous day. The snapshot agent runs, and creates
the .bcp file. I check the MSsnapshot_history table, and the snapshot
completes successfully, and the commands are posted to the distribution
database. I run sp_browsereplcmds, and I can see the commands in there.
The data is not getting moved to my subscriber. I have no idea why. What
can I check to figure this out? I have dropped the subscription, and
re-subscribed, but it just doesn't work.
Please help!
sql
Saturday, February 25, 2012
Problem with push subscription where subscriber identified by IP not name
network successfully, but am having a problem with the seventh one. I think
the problem is due to the fact that the subscription was set up using the
subscribing server's IP address rather than network name (there is currently
a problem on the network so the server's name can't be resolved)
The error seen in the merge agent for the subscription is:
The subscription to publication 'PersonNameAddrUpdate' is invalid.
(Source: Merge Replication Provider (Agent); Error number: -2147201019)
------
The remote server is not defined as a subscription server.
(Source: xxx.xxx.xxx.xx (Data source); Error number: 14010)
------
(xxx.xxx.xxx.xx is the subscribing server's IP address)
Is there anything that can be done while we have this problem with the
network?
Try using the client network utility to map the subscriber's IP address to
its netbios name and then register that in Enterprise Manager and as a
subscriber.
HTH,
Paul Ibison
"Laurence Neville" <laurenceneville@.hotmail.com> wrote in message
news:%237O3GIeTFHA.2812@.TK2MSFTNGP09.phx.gbl...
>I have set up six push subscriptions of the same publication on a wide area
>network successfully, but am having a problem with the seventh one. I think
>the problem is due to the fact that the subscription was set up using the
>subscribing server's IP address rather than network name (there is
>currently a problem on the network so the server's name can't be resolved)
> The error seen in the merge agent for the subscription is:
> The subscription to publication 'PersonNameAddrUpdate' is invalid.
> (Source: Merge Replication Provider (Agent); Error number: -2147201019)
> ------
> The remote server is not defined as a subscription server.
> (Source: xxx.xxx.xxx.xx (Data source); Error number: 14010)
> ------
> (xxx.xxx.xxx.xx is the subscribing server's IP address)
> Is there anything that can be done while we have this problem with the
> network?
>
|||I figured it out with help from this page:
http://www.adminlife.com/247referenc...36/184432.aspx
The answer was:
The error can also occur if the subscriber is registered using a TCP/IP
address instead of a Name.(see 321822). To work around, use the client
utilities to create an ALIAS name to the subscribers TCP/IP address and then
use that ALIAS name when registering the subscriber instead of the TCP/IP
address.
"Laurence Neville" <laurenceneville@.hotmail.com> wrote in message
news:%237O3GIeTFHA.2812@.TK2MSFTNGP09.phx.gbl...
>I have set up six push subscriptions of the same publication on a wide area
>network successfully, but am having a problem with the seventh one. I think
>the problem is due to the fact that the subscription was set up using the
>subscribing server's IP address rather than network name (there is
>currently a problem on the network so the server's name can't be resolved)
> The error seen in the merge agent for the subscription is:
> The subscription to publication 'PersonNameAddrUpdate' is invalid.
> (Source: Merge Replication Provider (Agent); Error number: -2147201019)
> ------
> The remote server is not defined as a subscription server.
> (Source: xxx.xxx.xxx.xx (Data source); Error number: 14010)
> ------
> (xxx.xxx.xxx.xx is the subscribing server's IP address)
> Is there anything that can be done while we have this problem with the
> network?
>
Problem with Publication Articles being deleted
I wonder if anyone can advise, I currently have a replication set to 5 offices. Which has been working fine for some 18 months+, then the replication dropped out. When I looked in the publisher it had lost all its articles and would not allow me to add back in. I deleted the publication and recreated it and then after creating a new snapshot starting rolling back out to the various locations, and one of the locations failed and again all the articles where lost. I deleted and rebuilt the database at that office and went through the same routine again, only for it to happen again, the issue being that now errors where produced!!!.
So at present I have the publication and all the subscriptions running apart from this one office.
Has anyone had this before, or any ideas. I have run a full virus scan just in case and it was fine.
Can you provide more information?
Are you using push transactional replication?
Where does the replication fail? What error messages are you getting?
When you say one of the location failed, does it mean other locations worked fine?
Gary
|||Hi Gary,
I found the problem, they were two dns records for the server I was trying to replicate to, and one of the records pointed back to the publication server. Now just need to find why all of a sudden I have 2 DNS records.
Thanks
Tony