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 ***

Future Maintenance of SQL 2005 Merge Replication

I have remote offices that are entering data into their local database, then
using merge replication to "upload" their changes to a publisher on my web
server, and then possibly download any changes made on my web server. My
Web server is running SQL 2005 Standard, and the local offices are running
SQL 2005 Express. I've got it working via https/replisapi.dll, and once
it's started, it works very nicely.
Typically when a new office once to get started, they'll backup their
(never-before-replicated) database to a .bak file, send me that file, and
I'll restore their (new) database onto my server, and create a publication.
Then I'll send them instructions on how to start a subscription. This
causes the data they just send me to come back down, as a snapshot is
applied to init the subscription. I realize that I could start a no-sync
initialization, but if any changes were made from when they made the backup
to when they start/init the subscripion, I believe the two-databases would
be out of sync. Am I right?
I understand that once a subscription is started, that if a backup is
restored (on either the subscription side or publisher side) that as long as
you're within the retention period, merge replication will correctly bring
over the changes that have occurred since the backup. With this in mind...
Would it be possible on the soon-to-be subscriber database to get the
replication triggers installed and working (tracking all changes) before the
backup is made, so that if any changes occur on the subscriber side (from
the time the backup was made to when it's applied to the publisher database
to when the subscription is started), these changes will be applied to the
publisher when the new subscription is initialized?
--Troy
Unfortunately you cannot enable change tracking before setting up the
subscription. So you would have to track the subscriber side changes
yourself while the subscription is being setup and update those rows that
changed in that interval so that it triggers a replication upload.
“This posting is provided "AS IS" with no warranties, and confers no rights.”
"Troy Wolbrink" wrote:

> I have remote offices that are entering data into their local database, then
> using merge replication to "upload" their changes to a publisher on my web
> server, and then possibly download any changes made on my web server. My
> Web server is running SQL 2005 Standard, and the local offices are running
> SQL 2005 Express. I've got it working via https/replisapi.dll, and once
> it's started, it works very nicely.
> Typically when a new office once to get started, they'll backup their
> (never-before-replicated) database to a .bak file, send me that file, and
> I'll restore their (new) database onto my server, and create a publication.
> Then I'll send them instructions on how to start a subscription. This
> causes the data they just send me to come back down, as a snapshot is
> applied to init the subscription. I realize that I could start a no-sync
> initialization, but if any changes were made from when they made the backup
> to when they start/init the subscripion, I believe the two-databases would
> be out of sync. Am I right?
> I understand that once a subscription is started, that if a backup is
> restored (on either the subscription side or publisher side) that as long as
> you're within the retention period, merge replication will correctly bring
> over the changes that have occurred since the backup. With this in mind...
> Would it be possible on the soon-to-be subscriber database to get the
> replication triggers installed and working (tracking all changes) before the
> backup is made, so that if any changes occur on the subscriber side (from
> the time the backup was made to when it's applied to the publisher database
> to when the subscription is started), these changes will be applied to the
> publisher when the new subscription is initialized?
> --Troy
>
>
|||Thanks for confirming that. I'm considering setting the database to
read-only during the interim to keep the user from making any changes that
will get discarded. Or atleast just give the user a warning that any
changes during the interim will be ignored.
--Troy
"Vijay TS" <VijayTS@.discussions.microsoft.com> wrote in message
news:FF785F35-E3BA-4966-953F-69B58A30F057@.microsoft.com...[vbcol=seagreen]
> Unfortunately you cannot enable change tracking before setting up the
> subscription. So you would have to track the subscriber side changes
> yourself while the subscription is being setup and update those rows that
> changed in that interval so that it triggers a replication upload.
> --
> "This posting is provided "AS IS" with no warranties, and confers no
> rights."
>
> "Troy Wolbrink" wrote: