Data Source / ODBC error

Hi all,

My replication of those SQL 2000 servers gave errors: Data source (11): General Network Error. Check your network documentation... and ODBC (08S01): Communication link failure. The replication was across the WAN. I don't know where to start to troubleshoot this problem. Please help!

Thanks in advance.

John

Communication link failure means some network or communication problem between the Publisher/Distributor and Subscriber. Check the connection between them. Try connecting to the other servers from each of the servers and ensure that you are able to connect and then retry the Sync.

Also note for any firewalls that need to be taken care of or if the ports are different or enabled.

See if the domains are different and if so ensure trust or use SQL authentication.

Also is this the first time the sync ran or it previously used to succeed?

|||

Hi,

This is not the first time the replication failed. It worked perfect before.

DNS is fine since I did check.

Since this is a site to site interconnected (site2site VPN across internet). Therefore, the domains are different.

It has failed several times a day.

I don't know if we have any testing tools for replication available so I can narrow down the problems and troubleshoot more efficiently.

thanks much for your help!!!

|||This mostly has to do with network connectivity then. For merge agent to run successfully, the connection needs to be established. Try rerunning it and see if it succeeds. Also see if there are any other external factors affecting the connection. Peak load, network flakiness, disconnects or downtime during certain periods of time etc.|||On the machine where the failure occurred, try creating a UDL file

(create a new text document, then rename it to "test.udl"). Open the

UDL file by double-clicking it, then try to establish a connection to

your database using the same sorts of parameters (ie provider [SQL

Server native / ODBC etc.], server name, login parameters). You can use

this to narrow down the cause of the problem (eg. whether it's the DB

provider, or a lack of connectivity which can be checked using other

means such as a traceroute etc.).|||

Thanks much. I will implement this method. In the meantime, is the packet from replication UDP or TCP when it is sent to the subcribed machine from distributed machine. I have thought my network is being flooding at the switch before data reached the nodes of the cluster. Therefore, it is redirected elsewhere but the destination. What I did was trying to send data from host inside network through that switch to the gateway...and I was only successful 35%. This means packets drops no matter incoming or outgoing through that switch.

Having some methods to test the replication directly will help a lot.

Thanks for your helps, guys.

|||Doesn't UDP run on top of TCP, hence they're both going to be TCP?

Also, it'd depend on whether you've got the IIS machine on the

Publisher machine, the Subscriber machine, or another machine?

Also try playing around with the configuration of the Client/Server

Network Protocol - if you're having problems using TCP/IP, then try

using Named Pipes instead. Make sure to configure this on both the

publisher and subscriber machine.|||

Problem Fixed, Guys. It was just network problem. The Fixwall is misconfigured so that it operated half duplex instead of full. There Ain't nothin to do with the replication!!!

However, I have to deal with new problem......queue reader failed with the error message: Queue reader aborting. The steps failed. What does it mean? Where should I start to troubleshoot this error?

Thanks a lot!

|||Is there anything more helpful in the Event log?|||What I 've got is Failed while applying queued message to publisher!|||

I'm not an expert in SQL Server replication, so I can't help you more with your specific error (I've just recently spent a few days reading lots about SQL Mobile replication, hence the reason I came across your post).

If I was in your position, however, I'd start by getting everything working on on one box (even if it's just a staging box), and once it all works, you can move bit by bit elsewhere (eg. Publisher DB / IIS virtual dir / IIS server / Subscriber DB).

As you try to move things bit by bit you'll realise where the problem is. Sometimes the 'longest' way is the shortest because by being systematic, you don't end up pulling your hair out looking at something that 'should work', but doesn't!

|||

Oh, by the way, if you can't get it to work, I suggest starting a new thread, because some people will see this thread as answered, and not read it.

Cheers.