1

We've had a db replication working between two servers across the internet.

Server A is sitting on our server network (Windows Server 2008 + SQL Server 2008 R2) Server B is sitting on a different network (Windows Server 2008 + SQL Server 2008 R2)

Ports are still open, TCP and Named Pipes are enabled. Alias configured, TCP and ports open in the firewall, everything was smooth and working. All SQL Services are also running.

Server A is the publisher and Server B is the subscriber.

It's been using a Push subscription so everything was working on Server A.

All data was synced and everything was fine.

After a server issue on Server A, the DB name changed, the replication and publication was recreated and Server A was upgraded to SQL Server 2008 R2 SP3.

So far that's the only noticeable difference between the two, the publisher is running SQL 10.50.6000.34 and the subscriber 10.50.2500.0.

Now the replication stopped working and I'm not able to connect the two via named pipes..

If I try to create a new subscription from either server and use the server name (for replications you need to use the server name instead of TCP) I keep getting named pipe error

Named Pipe error

I can ping each Server from the other server. I can connect from SQL Management Studio using tcp with domain or ip and run queries on the other server. I can add them as linked servers and see the data as well.

But the moment I go to create new subscription and add the remote subscriber I get the named pipe error.

  • Have you tried using IP address instead of MW-2K8-EHA, which is clearly a local name? – Aaron Bertrand Oct 23 '15 at 19:20
  • @AaronBertrand Yes and it gives the exact same named pipes error as when using the local name – Federico Giust Oct 23 '15 at 19:48
  • Did you try disabling named pipes on both ends? I don't think it's possible to use named pipes over the Internet... but sorry, replication is a 4-letter word to me; I don't know how to tell any of its wizards to use a different protocol. – Aaron Bertrand Oct 23 '15 at 20:07
1

I've finally managed to connecto both servers!

As it turns out even though both server are x64 and running 64bit os and SQL Server 64 bit, it needs the aliases to be configured both on 64 & 32 Bit Native Client Aliases.

Once I configured the one for the 32 bit driver, it worked.

0

it is true, and I think the reason for this is, when you use 64 bit edition of SQL Server the process works 64 bit, but most tools like SSMS are working in 32 bit mode, and that's reason you need to aliases for both 64 and 32 bit in Native Client Configuration.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.