0

I have 2 servers... OTTO is located on site, and connected to domain It is running SQL 2008. I have created the database, in SQL 2000 compatability mode.

WEBDB3 is located in datacenter, not connected to our domain. It is running SQL 2000

DMZ set up between two sites, on Firewall.

I've created a transactional publication on OTTO I then set up a subscription to WebDB3.

After snapshot is initialized, i get this error if i right click and select View Synchronization Status:

The process could not connect to Subscriber 'WEBDB3'.

If i open Replication monitor:

Error messages: The process could not connect to Subscriber 'WEBDB3'. (Source: MSSQL_REPL, Error number: MSSQL_REPL0) Get help: http://help/MSSQL_REPL0 Named Pipes Provider: Could not open a connection to SQL Server [53]. (Source: MSSQLServer, Error number: 53) Get help: http://help/53 A network-related or instance-specific error has occurred while establishing a connection to SQL Server. Server is not found or not accessible. Check if instance name is correct and if SQL Server is configured to allow remote connections. For more information see SQL Server Books Online. (Source: MSSQLServer, Error number: 53) Get help: http://help/53

PREVIOUSLY there was a server called NavisionUpgrade. This was set up very similar, and replication worked.

What am I doing wrong? I've spend HOURS on this, and am pulling my hair out!

12
  • can you telnet to port 1433 on the remote server?
    – Zypher
    Jan 7, 2010 at 1:21
  • You'll need a rule in your firewalls that specifically allows port 1433 traffic to and from each SQL server.
    – joeqwerty
    Jan 7, 2010 at 1:24
  • i've turned the firewall off on the publisher (OTTO) to rule this out...
    – alex
    Jan 7, 2010 at 1:53
  • 1
    @alex: there still might be a firewall or a router filtering 1433. best test would be to see if you can telnet to port 1433
    – Zypher
    Jan 7, 2010 at 1:58
  • The firewall on the Subscriber is the more likely place for the firewall to be blocking the connection. I'm assuming the Publisher "pushes" data to the Subscriber. If so, then the Publisher is trying to initiate an incoming connection to port 1433 on the Subscriber, which is probably being blocked by the firewall on the Subscriber's end.
    – joeqwerty
    Jan 7, 2010 at 2:15

1 Answer 1

1

From joeqwerty's comments:

I just noticed in your errors that it looks like you're using named pipes on OTTO to connect to WEBDB3. Try configuring OTTO to use TCP\IP to connect to WEBDB3. Named pipes requires file and print sharing traffic to be able to transit the firewalls, which is probably being blocked.

Use the SQL client configuration utility on OTTO to change the connection parameters for WEBDB3 to use TCP\IP. If you don't have the client configuration utility installed you can configure an ODBC DSN to use TCP\IP for the connection to WEBDB3.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .