general network error

I have a publisher that has worked for months. Now, two of the three
subscriptions are getting errors:
The process could not query row metadata at the subscriber.
(source merge replication provider (agent): error number -217200996
General network error: check your network documentation
I turned on logging and everything is fine until:
[1/31/2007 4:26:58 AM]subscribeDB: {call sp_MSgetversion }
The process could not query row metadata at the 'Subscriber'.
The process could not enumerate changes at the 'Publisher'.
The merge process encountered an unexpected network error. The
connection to Subscriber 'subscribeDB' is no longer available.
Percent Complete: 0
The process could not query row metadata at the 'Subscriber'.
Percent Complete: 0
Category:NULL
Source: Merge Replication Provider
Number: -2147200996
Message: The process could not query row metadata at the 'Subscriber'.
Percent Complete: 0
Category:COMMAND
Source: Failed Command
Number: 0
Message: {call sp_MSgetmetadatabatch(?,?,?)}
Percent Complete: 0
Category:SQLSERVER
Source: subscribeDB
Number: 11
Message: General network error. Check your network documentation.
Percent Complete: 0
Category:NULL
Source: Merge Replication Provider
Number: -2147200999
Message: The process was successfully stopped.
I know the general network error is a catch-all. I have done Hilary's
keepalive and it never seems to fail. I have done a checkdb and checkdb
w/ rebuild_repair and that has made no difference. One subscriber has
had no problems, two started failing on Friday.
Any help would be greatly appreciated.
Thanks.
Darin
*** Sent via Developersdex http://www.codecomments.com ***
FWIW, GNEs are almost always indicative of a hardware (switch, NIC, cable)
or driver error. Not 100%, but pretty close in my experience.
Are your SQL Servers and MDACs current? Can you see anything in a Netmon
trace run from both machines?
Kevin Hill
3NF Consulting
http://www.3nf-inc.com/NewsGroups.htm
Real-world stuff I run across with SQL Server:
http://kevin3nf.blogspot.com
"Darin" <darin_nospam@.nospamever> wrote in message
news:u0TlpZTRHHA.1228@.TK2MSFTNGP06.phx.gbl...
>I have a publisher that has worked for months. Now, two of the three
> subscriptions are getting errors:
> The process could not query row metadata at the subscriber.
> (source merge replication provider (agent): error number -217200996
> General network error: check your network documentation
> I turned on logging and everything is fine until:
> [1/31/2007 4:26:58 AM]subscribeDB: {call sp_MSgetversion }
> The process could not query row metadata at the 'Subscriber'.
> The process could not enumerate changes at the 'Publisher'.
> The merge process encountered an unexpected network error. The
> connection to Subscriber 'subscribeDB' is no longer available.
> Percent Complete: 0
> The process could not query row metadata at the 'Subscriber'.
> Percent Complete: 0
> Category:NULL
> Source: Merge Replication Provider
> Number: -2147200996
> Message: The process could not query row metadata at the 'Subscriber'.
> Percent Complete: 0
> Category:COMMAND
> Source: Failed Command
> Number: 0
> Message: {call sp_MSgetmetadatabatch(?,?,?)}
> Percent Complete: 0
> Category:SQLSERVER
> Source: subscribeDB
> Number: 11
> Message: General network error. Check your network documentation.
> Percent Complete: 0
> Category:NULL
> Source: Merge Replication Provider
> Number: -2147200999
> Message: The process was successfully stopped.
>
> I know the general network error is a catch-all. I have done Hilary's
> keepalive and it never seems to fail. I have done a checkdb and checkdb
> w/ rebuild_repair and that has made no difference. One subscriber has
> had no problems, two started failing on Friday.
> Any help would be greatly appreciated.
> Thanks.
> Darin
> *** Sent via Developersdex http://www.codecomments.com ***
|||Yes everything is current on all servers regarding the OS and SQL
programs.
Darin
*** Sent via Developersdex http://www.codecomments.com ***
|||Hi,
Dont take this the wrong way but I had this error and found that my
broadband had a fault on the line. I blamed the server for weeks and spent
hours trying this and that but it was the link between my servers blipping
out that was causing the problem.
Just a thought!.
"Darin" wrote:

> Yes everything is current on all servers regarding the OS and SQL
> programs.
> Darin
> *** Sent via Developersdex http://www.codecomments.com ***
>
|||If my keepalive script (which doesn't really keep anything alive unless you
have a router which will shut down automatically when it senses no traffic)
reveals no network problems, it probably is a timeout issue. Change
querytimeout to something larger.
You can also run a ping -t and watch for dropped packets which just
indicates the line going down. replication is normally resilient to lossy
lines.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Darin" <darin_nospam@.nospamever> wrote in message
news:u0TlpZTRHHA.1228@.TK2MSFTNGP06.phx.gbl...
>I have a publisher that has worked for months. Now, two of the three
> subscriptions are getting errors:
> The process could not query row metadata at the subscriber.
> (source merge replication provider (agent): error number -217200996
> General network error: check your network documentation
> I turned on logging and everything is fine until:
> [1/31/2007 4:26:58 AM]subscribeDB: {call sp_MSgetversion }
> The process could not query row metadata at the 'Subscriber'.
> The process could not enumerate changes at the 'Publisher'.
> The merge process encountered an unexpected network error. The
> connection to Subscriber 'subscribeDB' is no longer available.
> Percent Complete: 0
> The process could not query row metadata at the 'Subscriber'.
> Percent Complete: 0
> Category:NULL
> Source: Merge Replication Provider
> Number: -2147200996
> Message: The process could not query row metadata at the 'Subscriber'.
> Percent Complete: 0
> Category:COMMAND
> Source: Failed Command
> Number: 0
> Message: {call sp_MSgetmetadatabatch(?,?,?)}
> Percent Complete: 0
> Category:SQLSERVER
> Source: subscribeDB
> Number: 11
> Message: General network error. Check your network documentation.
> Percent Complete: 0
> Category:NULL
> Source: Merge Replication Provider
> Number: -2147200999
> Message: The process was successfully stopped.
>
> I know the general network error is a catch-all. I have done Hilary's
> keepalive and it never seems to fail. I have done a checkdb and checkdb
> w/ rebuild_repair and that has made no difference. One subscriber has
> had no problems, two started failing on Friday.
> Any help would be greatly appreciated.
> Thanks.
> Darin
> *** Sent via Developersdex http://www.codecomments.com ***
|||I am still getting the general network failure, and I agree that it is
the network. Unfortunitly, the ISP says the lines are fine, so we are
all pointing fingers at eachother.
I can open QA and connect to the remote server from the publisher fine,
and acctually issue SELECT statements. So, what I am thinking is if I
can get the replication to go in very small bursts it might have better
success. So, I am playing w/ the profile. I have am using one I created
that has:
bcpbatchsize=100000
changesperhistory 20
destthreads 4
the next 3 download all 20
fastrowcount 1
historyverboselevel 1
keepalive 300
logintimeout 15
maxdownload & maxupload 20
metadataretention 1
numdeadlockretries 25
pollinginternal 60
querytimout 600
srcthreads 3
startqueuetimout 0
3 uploads 20
validate 0
validateinterval 60
These settings haven't made any difference. I am still getting the
errors:
the process could not deliver inserts at the subscriber
general network error
the merge process encountered an unexpected network error. The
connection to the subscriber is no longer available.
2 of the 3 subscribers have errors, the third subscriber works
perfectly. Can anyone think of any settings in the profile that might
help "slow-down" the replication so it will try more and wait longer and
send small bursts only?
Thanks - this is getting very important as it has been messed up for a
week.
THanks.
Darin
*** Sent via Developersdex http://www.codecomments.com ***