Merge replication sync fails with error code 80040E19 on handheld

Hi;

We are performing merge replication between SQL Server 2005 and SQL Server Mobile with more than 1100 handheld, and recently replications are terminating with eror code 80040E19.
We can only avoid the problem by deleting the related user's partition directory and reruning the related user's dynamic snapshot.

Any advice on this issue would be appreciated

Thanks,
Hakan Gümüs

I feel your pain. We only have 300 handhelds in the field but receive this error after every couple of weeks or so. We have not found much information on it at all. It seems to be a client side error, ie no error shows up in the server logs. What we do to alleviate the error is to right click on the publication in SQL Server and Reinitialize All Subscriptions, selecting the Use a new snapshot option with Generate now checked. Once the snapshot is done (monitor with View Snapshot Agent Status) the device replicates again just fine.

Due to the cyclic affect of when it occurs, it seems it may correlate to Retention period of the publication. This is difficult to say as we don't fully understand what happens when the expiration period is reached. The only thing we do know is that Reinitializing the subscriptions works every time.

It is also a guess that it may have something to do with the number of simultaneous replications occuring. Possibly some data at some point gets corrupted or out of sync. We did not see the error during our pilot when we only had a couple of dozen units in the field. Our users by the way replicate twice a day - morning and night, so there are periods of high activity.

Please, if you find out any additional information to this issue, let me know. It has plagued us now for over 6 months. I'll be happy to share whatever information that I can to help solve this issue for good.

Regards,
Santino Lamberti|||

Hi Santino;

We have opened a case about this issue, I'll inform you about the result.

Thanks for your reply.

Hakan Gümü?

|||The Investigation about the case is still going on. The only workaround that we could find is dropping the related user's merge partition with below command and resync it.

sp_dropmergepartition 'TESTPUB',NULL,'THOSTNAME'

|||Thanks for sharing this. I'll try it next time we run across the error. It seems that I've tried doing this via the UI once before with no effect, but I'll give this a whirl anyway. I also plan on looking at the snapshot data (schema and bcp files) for the failing user and the master snapshot. The error seems to occur after all the schemas are applied and possibly when the data is being copied in.

Merge Replication is very slow

Hi
We have configured merge replication in SQL 2005 (SP 1) for a database
having more than 100 GB. The merge agent duration was for every 5 mins.
Normally it used to take around 2 to 3 mins to complete. It was working fine
till now but now it is taking around 45 minutes. When checked and viewed
details in the replication monitor the below message was displayed for a long
time.
The process is waiting for a response from the query '{call
sys.sp_MSenumchangesdirect(?,?,?,?,?,?,?,?,90,1,0, '39B06489-B2C7-4FA4-B109-8609CD6C18FF')}'
Any help in this regard is appreciated
Thanks.
Are you using join Filters? Also you might want to drop your retention
period so that metadata is purged more frequently.
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
"Roy" <Roy@.discussions.microsoft.com> wrote in message
news:A96295C7-71C5-4764-9093-6737DED1E033@.microsoft.com...
> Hi
> We have configured merge replication in SQL 2005 (SP 1) for a database
> having more than 100 GB. The merge agent duration was for every 5 mins.
> Normally it used to take around 2 to 3 mins to complete. It was working
> fine
> till now but now it is taking around 45 minutes. When checked and viewed
> details in the replication monitor the below message was displayed for a
> long
> time.
> The process is waiting for a response from the query '{call
> sys.sp_MSenumchangesdirect(?,?,?,?,?,?,?,?,90,1,0, '39B06489-B2C7-4FA4-B109-8609CD6C18FF')}'
> Any help in this regard is appreciated
> Thanks.
|||In addition to Hilary's suggestions, look at if you really need all the data
at the subscribers. Does all data change at both places, if not utilize the
downloadonly articles. And when using filters, see if you can use any of the
filtering enhancements in SQL Server 2005.
Also was there a lot of activity on the database recently that is causing
this wait?
Hope that helps
--Mahesh
[ This posting is provided "as is" with no warranties and confers no
rights. ]
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:ugqNAvvEHHA.3820@.TK2MSFTNGP02.phx.gbl...
> Are you using join Filters? Also you might want to drop your retention
> period so that metadata is purged more frequently.
> --
> 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
>
> "Roy" <Roy@.discussions.microsoft.com> wrote in message
> news:A96295C7-71C5-4764-9093-6737DED1E033@.microsoft.com...
>
|||Thanks for the reply
I don't have any join Filters.
The retention period was 14 days and now changed to 7 days. Removed some
records from MSmerge_contents &
MSmerge_genhistory.
Now there is some improvement. But still it is taking more than it used to.
Data changes are there at both (subscriber & publisher) ends. It is a 24/7
high activity database.
Checked memory & bandwidth , CPU, etc., all seems to be normal.
Thanks,
"Mahesh [MSFT]" wrote:

> In addition to Hilary's suggestions, look at if you really need all the data
> at the subscribers. Does all data change at both places, if not utilize the
> downloadonly articles. And when using filters, see if you can use any of the
> filtering enhancements in SQL Server 2005.
> Also was there a lot of activity on the database recently that is causing
> this wait?
> Hope that helps
> --Mahesh
> [ This posting is provided "as is" with no warranties and confers no
> rights. ]
> "Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
> news:ugqNAvvEHHA.3820@.TK2MSFTNGP02.phx.gbl...
>
>
|||If it is a highly active database, then it will be due to metadata growth.
If you can be sure that the subscriber will be synchronizing often, then you
can further reduce the retention. However remember that if the subscriber
fails to synchronize within the retention, it will expire and will need
reinitialization.
Hope that helps
--Mahesh
[ This posting is provided "as is" with no warranties and confers no
rights. ]
"Roy" <Roy@.discussions.microsoft.com> wrote in message
news:9456F61D-74FD-45AF-BE89-8BFFEFD571DF@.microsoft.com...[vbcol=seagreen]
> Thanks for the reply
> I don't have any join Filters.
> The retention period was 14 days and now changed to 7 days. Removed some
> records from MSmerge_contents &
> MSmerge_genhistory.
> Now there is some improvement. But still it is taking more than it used
> to.
> Data changes are there at both (subscriber & publisher) ends. It is a 24/7
> high activity database.
> Checked memory & bandwidth , CPU, etc., all seems to be normal.
> Thanks,
>
> "Mahesh [MSFT]" wrote: