Merge Replication with SQL Mobile 2005

We are using SQL 2005 (SP1) and mobile agents with SQL Mobile. We are seeing an excessive number of updates after a device's database is reinitialized. My understanding was that if I generate a new snapshot or reinitialize all subscriptions (from the server), the devices would only get what the database looks like right now (inserts only) after syncing and/or reinitializing, but they are actually getting the right number of inserts and a huge number of updates in Replication Monitor. Any ideas?

Thanks!

Mike

Update: Found a weird thing with the updates: On our test server, the number of updates, after generating a snapshot and reinitializing the mobile db, exactly matches the number of inserts. On production, the number of updates being transferred is 6 times the number of inserts on every article, so it the mobile database should get 10 rows for an article (based on filters), it will show 10 inserts and 60 updates.

Hope this helps, although it seems pretty strange!

Mike

|||

are the any configuration difference or data load difference between the test server and the production server ?

and also, by saying "On our test server, the number of updates, after generating a snapshot and reinitializing the mobile db, exactly matches the number of inserts", you meant to say the "updates on the subscriber is the same number as the inserts on the subscriber", right ?

what is you publication looks like ? e.g. number of articles, RIs between them ? etc.

that'll help us to identify the issue.

thanks

Yunwen

|||

First of all, I have an update. We recreated the publication on our test server as well as our production server (causing outages to our customers). After doing so, everything went back to normal and we were only seeing inserts (no updates) after a subscription is reinitialized. Now, just this morning, our production server started showing duplicates again, right now the number of inserts is exactly the same as the number of updates. Another thing to note is that right before we recreated the publication in production, the ratio was up to 7 to 1 (updates to inserts), meaning that it went up again.

As to your question, we have 23 articles. All of them have filters based on HOST_NAME(), some have even more complex filters that use subqueries based on HOST_NAME as a simple join will not work. All tables have PK/FK relationships with the exception of several tables that have auditing fields (created by, modified by, etc). We do not have referential integrity as the assosiated data is not always transferred to the device, nor do we use these fields on the device except to set or update them. The only exception to this is a LOG table that contains a trigger to move the logs into a historical table so that we can gather information from the device. This produces an insert during the upload and a delete during the download, removing the log from the device during a sync.

BTW, you are correct, the number of updates to the subscriber matches (or is some multiple of) the number of inserts on the subscriber. So far, we do not see this with normal syncs, only reinitializations.

One other thing to note is that we recreated the publication yesterday at around 7AM CST. This morning is the first time we are seeing the updates again, and they started sometime between yesterday evening (when the last reinitialization was recorded; worked fine) and this morning at 9:30AM (the first reinit that showed the duplicates). That being said, it took over a month for the previous publication to reach a multiple of 7.

Hope this all makes sense! This is getting more and more urgent as we send nearly 20,000 rows to some devices, meaning that their reinit is starting to take a larger and larger amount of time as the multiples go up.

Thanks!

Mike

|||

Thanks for the update.

do you generate a new snapshot prior reinitializing the subscriptions ? if the snapshot is old one and the subscription was reinitizlied. it will apply the snapshot and then apply the data in the mscontent table and if there are more and more updates/inserts on the publisher, this will give you this impression that subscriber was getting some unnecessary data.

also, you mentioned that there is a trigger on one of the published tables. is it possible you provide more details about it, or event better, send us the the publication script and the creation scripts for all the tables ?

Thanks

Yunwen

|||

First, yet another update: We removed and recreated the distribution database and publication after doing so on our test server and seeing the problem go away (usually we see some sort of duplication before a week has passed). So far so good, although it has not yet been 24 hours on the production side.

At the time of recreation in production, we were up to 5 times the number of updates as inserts, which means that it was going up by a multiple of 1 almost every 24 hours (although some days it skipped and the time the updates increased moved around; hopefully this removes scheduled jobs as a possible cause). I copied the distmdl and distribution files out before we recreated the distribution DB so that we can review a few of the critical system stored_procedures for differences, just in case the service pack did not update existing distribution databases correctly.

As to your questions...

Yes, we have tried generating a new snapshot to see if that would fix the issue. It had no effect. I agree that we may see some updates in there, but to have an exact multiple on every table would still not seem right to me. I would expect to see "random" updates throughout the articles.

I will look at scripting out the rest of the publication, but here is the trigger:

CREATE TRIGGER [dbo].[MoveLog]
ON [dbo].[LOG]
AFTER INSERT
AS
BEGIN
SET NOCOUNT ON;
BEGIN TRANSACTION

INSERT INTO LOG_HISTORY SELECT * FROM [LOG]
DELETE FROM [LOG]
IF @.@.error <> 0
BEGIN
ROLLBACK TRANSACTION
END
ELSE
BEGIN
COMMIT TRANSACTION
END

SET NOCOUNT ON;

END

Thanks,

Mike

|||

Almost forgot, we have a fax table that functions the same way as the log table. Also, both the log and fax table have no filters (as they are emptied after each sync;have yet to see them leave data in the table on the server or in any of our test SQL Mobile databases).

The triggers are identical to the point that you could just replace "LOG" with "FAX" and you would have it (in fact, that's how the fax trigger was created!).

Thanks again!

Mike

|||

Thanks for th update for this issue. yes, seeing update is exact X * insert number does indicate there could be issues.

so is both Log and log_history was published ?

Please keep us updated on the issue.

thanks

Yunwen

|||

Only LOG is published. Basically, the device logs to the log table. During a sync, the log entries are uploaded, the trigger fired (to move it to the history table), then the log entry is deleted off the device, during the download phase.

I am now working with MS support on the issue, so hopefully we can figure something out. So far, I am just gathering logs for review.

Thanks,

Mike

|||

Thanks Mike.

Working with MS support probably a good way to pursure this issue. they can instruct you how to trouble shooting this issue.

Thanks

Yunwen

|||

Hello,

we are running into the same issue (multiplied insert, updates, initial synchronization taking up to 10 times longer than on identical publication on sql2000). I am therefore very concerned if you finally solved the case?

Thanks in advance

Kuba

|||We are running into this same issue as well. It started out as updates matching the number of inserts, and has now gone to updates doubling the number of inserts. If anyone has any solutions or feedback on this issue, it'd be greatly appreciated!

Thanks,
Adrien.|||I have contacted Microsoft developer support and resolved this issue with them. It is a known issue and they have a hot fix for it. However, the fix won't be available publicly until the next service pack. If you want to resolve this issue sooner though, developer support will refund the cost of an incident since it is a known issue.

Adrien.|||

Hello,

are you sure whether the hotfix to the discussed problem is going to be available in SP2? I've seen the list of bugs fixed by SP2CPT and I can't find anything that seems to be related to the case. How do I conctact developer support, is it possible to obtain the single hotfix from them or from anybody else?

Thanks in advance

Kuba

|||Hello,

My contact at developer support told me that the hotfix would be available in the next service pack. Whether he meant for SP2, or a future service pack, who knows? If you can't wait for it to be ready in a service pack, yes you can get it from developer support. To contact them, browse to the MSDN home page while logged into MSDN, then click on "Support Incidents".

Adrien.

Merge Replication with SQL Mobile 2005

We are using SQL 2005 (SP1) and mobile agents with SQL Mobile. We are seeing an excessive number of updates after a device's database is reinitialized. My understanding was that if I generate a new snapshot or reinitialize all subscriptions (from the server), the devices would only get what the database looks like right now (inserts only) after syncing and/or reinitializing, but they are actually getting the right number of inserts and a huge number of updates in Replication Monitor. Any ideas?

Thanks!

Mike

Update: Found a weird thing with the updates: On our test server, the number of updates, after generating a snapshot and reinitializing the mobile db, exactly matches the number of inserts. On production, the number of updates being transferred is 6 times the number of inserts on every article, so it the mobile database should get 10 rows for an article (based on filters), it will show 10 inserts and 60 updates.

Hope this helps, although it seems pretty strange!

Mike

|||

are the any configuration difference or data load difference between the test server and the production server ?

and also, by saying "On our test server, the number of updates, after generating a snapshot and reinitializing the mobile db, exactly matches the number of inserts", you meant to say the "updates on the subscriber is the same number as the inserts on the subscriber", right ?

what is you publication looks like ? e.g. number of articles, RIs between them ? etc.

that'll help us to identify the issue.

thanks

Yunwen

|||

First of all, I have an update. We recreated the publication on our test server as well as our production server (causing outages to our customers). After doing so, everything went back to normal and we were only seeing inserts (no updates) after a subscription is reinitialized. Now, just this morning, our production server started showing duplicates again, right now the number of inserts is exactly the same as the number of updates. Another thing to note is that right before we recreated the publication in production, the ratio was up to 7 to 1 (updates to inserts), meaning that it went up again.

As to your question, we have 23 articles. All of them have filters based on HOST_NAME(), some have even more complex filters that use subqueries based on HOST_NAME as a simple join will not work. All tables have PK/FK relationships with the exception of several tables that have auditing fields (created by, modified by, etc). We do not have referential integrity as the assosiated data is not always transferred to the device, nor do we use these fields on the device except to set or update them. The only exception to this is a LOG table that contains a trigger to move the logs into a historical table so that we can gather information from the device. This produces an insert during the upload and a delete during the download, removing the log from the device during a sync.

BTW, you are correct, the number of updates to the subscriber matches (or is some multiple of) the number of inserts on the subscriber. So far, we do not see this with normal syncs, only reinitializations.

One other thing to note is that we recreated the publication yesterday at around 7AM CST. This morning is the first time we are seeing the updates again, and they started sometime between yesterday evening (when the last reinitialization was recorded; worked fine) and this morning at 9:30AM (the first reinit that showed the duplicates). That being said, it took over a month for the previous publication to reach a multiple of 7.

Hope this all makes sense! This is getting more and more urgent as we send nearly 20,000 rows to some devices, meaning that their reinit is starting to take a larger and larger amount of time as the multiples go up.

Thanks!

Mike

|||

Thanks for the update.

do you generate a new snapshot prior reinitializing the subscriptions ? if the snapshot is old one and the subscription was reinitizlied. it will apply the snapshot and then apply the data in the mscontent table and if there are more and more updates/inserts on the publisher, this will give you this impression that subscriber was getting some unnecessary data.

also, you mentioned that there is a trigger on one of the published tables. is it possible you provide more details about it, or event better, send us the the publication script and the creation scripts for all the tables ?

Thanks

Yunwen

|||

First, yet another update: We removed and recreated the distribution database and publication after doing so on our test server and seeing the problem go away (usually we see some sort of duplication before a week has passed). So far so good, although it has not yet been 24 hours on the production side.

At the time of recreation in production, we were up to 5 times the number of updates as inserts, which means that it was going up by a multiple of 1 almost every 24 hours (although some days it skipped and the time the updates increased moved around; hopefully this removes scheduled jobs as a possible cause). I copied the distmdl and distribution files out before we recreated the distribution DB so that we can review a few of the critical system stored_procedures for differences, just in case the service pack did not update existing distribution databases correctly.

As to your questions...

Yes, we have tried generating a new snapshot to see if that would fix the issue. It had no effect. I agree that we may see some updates in there, but to have an exact multiple on every table would still not seem right to me. I would expect to see "random" updates throughout the articles.

I will look at scripting out the rest of the publication, but here is the trigger:

CREATE TRIGGER [dbo].[MoveLog]
ON [dbo].[LOG]
AFTER INSERT
AS
BEGIN
SET NOCOUNT ON;
BEGIN TRANSACTION

INSERT INTO LOG_HISTORY SELECT * FROM [LOG]
DELETE FROM [LOG]
IF @.@.error <> 0
BEGIN
ROLLBACK TRANSACTION
END
ELSE
BEGIN
COMMIT TRANSACTION
END

SET NOCOUNT ON;

END

Thanks,

Mike

|||

Almost forgot, we have a fax table that functions the same way as the log table. Also, both the log and fax table have no filters (as they are emptied after each sync;have yet to see them leave data in the table on the server or in any of our test SQL Mobile databases).

The triggers are identical to the point that you could just replace "LOG" with "FAX" and you would have it (in fact, that's how the fax trigger was created!).

Thanks again!

Mike

|||

Thanks for th update for this issue. yes, seeing update is exact X * insert number does indicate there could be issues.

so is both Log and log_history was published ?

Please keep us updated on the issue.

thanks

Yunwen

|||

Only LOG is published. Basically, the device logs to the log table. During a sync, the log entries are uploaded, the trigger fired (to move it to the history table), then the log entry is deleted off the device, during the download phase.

I am now working with MS support on the issue, so hopefully we can figure something out. So far, I am just gathering logs for review.

Thanks,

Mike

|||

Thanks Mike.

Working with MS support probably a good way to pursure this issue. they can instruct you how to trouble shooting this issue.

Thanks

Yunwen

|||

Hello,

we are running into the same issue (multiplied insert, updates, initial synchronization taking up to 10 times longer than on identical publication on sql2000). I am therefore very concerned if you finally solved the case?

Thanks in advance

Kuba

|||We are running into this same issue as well. It started out as updates matching the number of inserts, and has now gone to updates doubling the number of inserts. If anyone has any solutions or feedback on this issue, it'd be greatly appreciated!

Thanks,
Adrien.|||I have contacted Microsoft developer support and resolved this issue with them. It is a known issue and they have a hot fix for it. However, the fix won't be available publicly until the next service pack. If you want to resolve this issue sooner though, developer support will refund the cost of an incident since it is a known issue.

Adrien.|||

Hello,

are you sure whether the hotfix to the discussed problem is going to be available in SP2? I've seen the list of bugs fixed by SP2CPT and I can't find anything that seems to be related to the case. How do I conctact developer support, is it possible to obtain the single hotfix from them or from anybody else?

Thanks in advance

Kuba

|||Hello,

My contact at developer support told me that the hotfix would be available in the next service pack. Whether he meant for SP2, or a future service pack, who knows? If you can't wait for it to be ready in a service pack, yes you can get it from developer support. To contact them, browse to the MSDN home page while logged into MSDN, then click on "Support Incidents".

Adrien.

Merge Replication with SQL Mobile 2005

We are using SQL 2005 (SP1) and mobile agents with SQL Mobile. We are seeing an excessive number of updates after a device's database is reinitialized. My understanding was that if I generate a new snapshot or reinitialize all subscriptions (from the server), the devices would only get what the database looks like right now (inserts only) after syncing and/or reinitializing, but they are actually getting the right number of inserts and a huge number of updates in Replication Monitor. Any ideas?

Thanks!

Mike

Update: Found a weird thing with the updates: On our test server, the number of updates, after generating a snapshot and reinitializing the mobile db, exactly matches the number of inserts. On production, the number of updates being transferred is 6 times the number of inserts on every article, so it the mobile database should get 10 rows for an article (based on filters), it will show 10 inserts and 60 updates.

Hope this helps, although it seems pretty strange!

Mike

|||

are the any configuration difference or data load difference between the test server and the production server ?

and also, by saying "On our test server, the number of updates, after generating a snapshot and reinitializing the mobile db, exactly matches the number of inserts", you meant to say the "updates on the subscriber is the same number as the inserts on the subscriber", right ?

what is you publication looks like ? e.g. number of articles, RIs between them ? etc.

that'll help us to identify the issue.

thanks

Yunwen

|||

First of all, I have an update. We recreated the publication on our test server as well as our production server (causing outages to our customers). After doing so, everything went back to normal and we were only seeing inserts (no updates) after a subscription is reinitialized. Now, just this morning, our production server started showing duplicates again, right now the number of inserts is exactly the same as the number of updates. Another thing to note is that right before we recreated the publication in production, the ratio was up to 7 to 1 (updates to inserts), meaning that it went up again.

As to your question, we have 23 articles. All of them have filters based on HOST_NAME(), some have even more complex filters that use subqueries based on HOST_NAME as a simple join will not work. All tables have PK/FK relationships with the exception of several tables that have auditing fields (created by, modified by, etc). We do not have referential integrity as the assosiated data is not always transferred to the device, nor do we use these fields on the device except to set or update them. The only exception to this is a LOG table that contains a trigger to move the logs into a historical table so that we can gather information from the device. This produces an insert during the upload and a delete during the download, removing the log from the device during a sync.

BTW, you are correct, the number of updates to the subscriber matches (or is some multiple of) the number of inserts on the subscriber. So far, we do not see this with normal syncs, only reinitializations.

One other thing to note is that we recreated the publication yesterday at around 7AM CST. This morning is the first time we are seeing the updates again, and they started sometime between yesterday evening (when the last reinitialization was recorded; worked fine) and this morning at 9:30AM (the first reinit that showed the duplicates). That being said, it took over a month for the previous publication to reach a multiple of 7.

Hope this all makes sense! This is getting more and more urgent as we send nearly 20,000 rows to some devices, meaning that their reinit is starting to take a larger and larger amount of time as the multiples go up.

Thanks!

Mike

|||

Thanks for the update.

do you generate a new snapshot prior reinitializing the subscriptions ? if the snapshot is old one and the subscription was reinitizlied. it will apply the snapshot and then apply the data in the mscontent table and if there are more and more updates/inserts on the publisher, this will give you this impression that subscriber was getting some unnecessary data.

also, you mentioned that there is a trigger on one of the published tables. is it possible you provide more details about it, or event better, send us the the publication script and the creation scripts for all the tables ?

Thanks

Yunwen

|||

First, yet another update: We removed and recreated the distribution database and publication after doing so on our test server and seeing the problem go away (usually we see some sort of duplication before a week has passed). So far so good, although it has not yet been 24 hours on the production side.

At the time of recreation in production, we were up to 5 times the number of updates as inserts, which means that it was going up by a multiple of 1 almost every 24 hours (although some days it skipped and the time the updates increased moved around; hopefully this removes scheduled jobs as a possible cause). I copied the distmdl and distribution files out before we recreated the distribution DB so that we can review a few of the critical system stored_procedures for differences, just in case the service pack did not update existing distribution databases correctly.

As to your questions...

Yes, we have tried generating a new snapshot to see if that would fix the issue. It had no effect. I agree that we may see some updates in there, but to have an exact multiple on every table would still not seem right to me. I would expect to see "random" updates throughout the articles.

I will look at scripting out the rest of the publication, but here is the trigger:

CREATE TRIGGER [dbo].[MoveLog]
ON [dbo].[LOG]
AFTER INSERT
AS
BEGIN
SET NOCOUNT ON;
BEGIN TRANSACTION

INSERT INTO LOG_HISTORY SELECT * FROM [LOG]
DELETE FROM [LOG]
IF @.@.error <> 0
BEGIN
ROLLBACK TRANSACTION
END
ELSE
BEGIN
COMMIT TRANSACTION
END

SET NOCOUNT ON;

END

Thanks,

Mike

|||

Almost forgot, we have a fax table that functions the same way as the log table. Also, both the log and fax table have no filters (as they are emptied after each sync;have yet to see them leave data in the table on the server or in any of our test SQL Mobile databases).

The triggers are identical to the point that you could just replace "LOG" with "FAX" and you would have it (in fact, that's how the fax trigger was created!).

Thanks again!

Mike

|||

Thanks for th update for this issue. yes, seeing update is exact X * insert number does indicate there could be issues.

so is both Log and log_history was published ?

Please keep us updated on the issue.

thanks

Yunwen

|||

Only LOG is published. Basically, the device logs to the log table. During a sync, the log entries are uploaded, the trigger fired (to move it to the history table), then the log entry is deleted off the device, during the download phase.

I am now working with MS support on the issue, so hopefully we can figure something out. So far, I am just gathering logs for review.

Thanks,

Mike

|||

Thanks Mike.

Working with MS support probably a good way to pursure this issue. they can instruct you how to trouble shooting this issue.

Thanks

Yunwen

|||

Hello,

we are running into the same issue (multiplied insert, updates, initial synchronization taking up to 10 times longer than on identical publication on sql2000). I am therefore very concerned if you finally solved the case?

Thanks in advance

Kuba

|||We are running into this same issue as well. It started out as updates matching the number of inserts, and has now gone to updates doubling the number of inserts. If anyone has any solutions or feedback on this issue, it'd be greatly appreciated!

Thanks,
Adrien.
|||I have contacted Microsoft developer support and resolved this issue with them. It is a known issue and they have a hot fix for it. However, the fix won't be available publicly until the next service pack. If you want to resolve this issue sooner though, developer support will refund the cost of an incident since it is a known issue.

Adrien.
|||

Hello,

are you sure whether the hotfix to the discussed problem is going to be available in SP2? I've seen the list of bugs fixed by SP2CPT and I can't find anything that seems to be related to the case. How do I conctact developer support, is it possible to obtain the single hotfix from them or from anybody else?

Thanks in advance

Kuba

|||Hello,

My contact at developer support told me that the hotfix would be available in the next service pack. Whether he meant for SP2, or a future service pack, who knows? If you can't wait for it to be ready in a service pack, yes you can get it from developer support. To contact them, browse to the MSDN home page while logged into MSDN, then click on "Support Incidents".

Adrien.

Merge Replication with SQL Mobile 2005

We are using SQL 2005 (SP1) and mobile agents with SQL Mobile. We are seeing an excessive number of updates after a device's database is reinitialized. My understanding was that if I generate a new snapshot or reinitialize all subscriptions (from the server), the devices would only get what the database looks like right now (inserts only) after syncing and/or reinitializing, but they are actually getting the right number of inserts and a huge number of updates in Replication Monitor. Any ideas?

Thanks!

Mike

Update: Found a weird thing with the updates: On our test server, the number of updates, after generating a snapshot and reinitializing the mobile db, exactly matches the number of inserts. On production, the number of updates being transferred is 6 times the number of inserts on every article, so it the mobile database should get 10 rows for an article (based on filters), it will show 10 inserts and 60 updates.

Hope this helps, although it seems pretty strange!

Mike

|||

are the any configuration difference or data load difference between the test server and the production server ?

and also, by saying "On our test server, the number of updates, after generating a snapshot and reinitializing the mobile db, exactly matches the number of inserts", you meant to say the "updates on the subscriber is the same number as the inserts on the subscriber", right ?

what is you publication looks like ? e.g. number of articles, RIs between them ? etc.

that'll help us to identify the issue.

thanks

Yunwen

|||

First of all, I have an update. We recreated the publication on our test server as well as our production server (causing outages to our customers). After doing so, everything went back to normal and we were only seeing inserts (no updates) after a subscription is reinitialized. Now, just this morning, our production server started showing duplicates again, right now the number of inserts is exactly the same as the number of updates. Another thing to note is that right before we recreated the publication in production, the ratio was up to 7 to 1 (updates to inserts), meaning that it went up again.

As to your question, we have 23 articles. All of them have filters based on HOST_NAME(), some have even more complex filters that use subqueries based on HOST_NAME as a simple join will not work. All tables have PK/FK relationships with the exception of several tables that have auditing fields (created by, modified by, etc). We do not have referential integrity as the assosiated data is not always transferred to the device, nor do we use these fields on the device except to set or update them. The only exception to this is a LOG table that contains a trigger to move the logs into a historical table so that we can gather information from the device. This produces an insert during the upload and a delete during the download, removing the log from the device during a sync.

BTW, you are correct, the number of updates to the subscriber matches (or is some multiple of) the number of inserts on the subscriber. So far, we do not see this with normal syncs, only reinitializations.

One other thing to note is that we recreated the publication yesterday at around 7AM CST. This morning is the first time we are seeing the updates again, and they started sometime between yesterday evening (when the last reinitialization was recorded; worked fine) and this morning at 9:30AM (the first reinit that showed the duplicates). That being said, it took over a month for the previous publication to reach a multiple of 7.

Hope this all makes sense! This is getting more and more urgent as we send nearly 20,000 rows to some devices, meaning that their reinit is starting to take a larger and larger amount of time as the multiples go up.

Thanks!

Mike

|||

Thanks for the update.

do you generate a new snapshot prior reinitializing the subscriptions ? if the snapshot is old one and the subscription was reinitizlied. it will apply the snapshot and then apply the data in the mscontent table and if there are more and more updates/inserts on the publisher, this will give you this impression that subscriber was getting some unnecessary data.

also, you mentioned that there is a trigger on one of the published tables. is it possible you provide more details about it, or event better, send us the the publication script and the creation scripts for all the tables ?

Thanks

Yunwen

|||

First, yet another update: We removed and recreated the distribution database and publication after doing so on our test server and seeing the problem go away (usually we see some sort of duplication before a week has passed). So far so good, although it has not yet been 24 hours on the production side.

At the time of recreation in production, we were up to 5 times the number of updates as inserts, which means that it was going up by a multiple of 1 almost every 24 hours (although some days it skipped and the time the updates increased moved around; hopefully this removes scheduled jobs as a possible cause). I copied the distmdl and distribution files out before we recreated the distribution DB so that we can review a few of the critical system stored_procedures for differences, just in case the service pack did not update existing distribution databases correctly.

As to your questions...

Yes, we have tried generating a new snapshot to see if that would fix the issue. It had no effect. I agree that we may see some updates in there, but to have an exact multiple on every table would still not seem right to me. I would expect to see "random" updates throughout the articles.

I will look at scripting out the rest of the publication, but here is the trigger:

CREATE TRIGGER [dbo].[MoveLog]
ON [dbo].[LOG]
AFTER INSERT
AS
BEGIN
SET NOCOUNT ON;
BEGIN TRANSACTION

INSERT INTO LOG_HISTORY SELECT * FROM [LOG]
DELETE FROM [LOG]
IF @.@.error <> 0
BEGIN
ROLLBACK TRANSACTION
END
ELSE
BEGIN
COMMIT TRANSACTION
END

SET NOCOUNT ON;

END

Thanks,

Mike

|||

Almost forgot, we have a fax table that functions the same way as the log table. Also, both the log and fax table have no filters (as they are emptied after each sync;have yet to see them leave data in the table on the server or in any of our test SQL Mobile databases).

The triggers are identical to the point that you could just replace "LOG" with "FAX" and you would have it (in fact, that's how the fax trigger was created!).

Thanks again!

Mike

|||

Thanks for th update for this issue. yes, seeing update is exact X * insert number does indicate there could be issues.

so is both Log and log_history was published ?

Please keep us updated on the issue.

thanks

Yunwen

|||

Only LOG is published. Basically, the device logs to the log table. During a sync, the log entries are uploaded, the trigger fired (to move it to the history table), then the log entry is deleted off the device, during the download phase.

I am now working with MS support on the issue, so hopefully we can figure something out. So far, I am just gathering logs for review.

Thanks,

Mike

|||

Thanks Mike.

Working with MS support probably a good way to pursure this issue. they can instruct you how to trouble shooting this issue.

Thanks

Yunwen

|||

Hello,

we are running into the same issue (multiplied insert, updates, initial synchronization taking up to 10 times longer than on identical publication on sql2000). I am therefore very concerned if you finally solved the case?

Thanks in advance

Kuba

|||We are running into this same issue as well. It started out as updates matching the number of inserts, and has now gone to updates doubling the number of inserts. If anyone has any solutions or feedback on this issue, it'd be greatly appreciated!

Thanks,
Adrien.|||I have contacted Microsoft developer support and resolved this issue with them. It is a known issue and they have a hot fix for it. However, the fix won't be available publicly until the next service pack. If you want to resolve this issue sooner though, developer support will refund the cost of an incident since it is a known issue.

Adrien.|||

Hello,

are you sure whether the hotfix to the discussed problem is going to be available in SP2? I've seen the list of bugs fixed by SP2CPT and I can't find anything that seems to be related to the case. How do I conctact developer support, is it possible to obtain the single hotfix from them or from anybody else?

Thanks in advance

Kuba

|||Hello,

My contact at developer support told me that the hotfix would be available in the next service pack. Whether he meant for SP2, or a future service pack, who knows? If you can't wait for it to be ready in a service pack, yes you can get it from developer support. To contact them, browse to the MSDN home page while logged into MSDN, then click on "Support Incidents".

Adrien.sql

Merge Replication with SQL Mobile 2005

We are using SQL 2005 (SP1) and mobile agents with SQL Mobile. We are seeing an excessive number of updates after a device's database is reinitialized. My understanding was that if I generate a new snapshot or reinitialize all subscriptions (from the server), the devices would only get what the database looks like right now (inserts only) after syncing and/or reinitializing, but they are actually getting the right number of inserts and a huge number of updates in Replication Monitor. Any ideas?

Thanks!

Mike

Update: Found a weird thing with the updates: On our test server, the number of updates, after generating a snapshot and reinitializing the mobile db, exactly matches the number of inserts. On production, the number of updates being transferred is 6 times the number of inserts on every article, so it the mobile database should get 10 rows for an article (based on filters), it will show 10 inserts and 60 updates.

Hope this helps, although it seems pretty strange!

Mike

|||

are the any configuration difference or data load difference between the test server and the production server ?

and also, by saying "On our test server, the number of updates, after generating a snapshot and reinitializing the mobile db, exactly matches the number of inserts", you meant to say the "updates on the subscriber is the same number as the inserts on the subscriber", right ?

what is you publication looks like ? e.g. number of articles, RIs between them ? etc.

that'll help us to identify the issue.

thanks

Yunwen

|||

First of all, I have an update. We recreated the publication on our test server as well as our production server (causing outages to our customers). After doing so, everything went back to normal and we were only seeing inserts (no updates) after a subscription is reinitialized. Now, just this morning, our production server started showing duplicates again, right now the number of inserts is exactly the same as the number of updates. Another thing to note is that right before we recreated the publication in production, the ratio was up to 7 to 1 (updates to inserts), meaning that it went up again.

As to your question, we have 23 articles. All of them have filters based on HOST_NAME(), some have even more complex filters that use subqueries based on HOST_NAME as a simple join will not work. All tables have PK/FK relationships with the exception of several tables that have auditing fields (created by, modified by, etc). We do not have referential integrity as the assosiated data is not always transferred to the device, nor do we use these fields on the device except to set or update them. The only exception to this is a LOG table that contains a trigger to move the logs into a historical table so that we can gather information from the device. This produces an insert during the upload and a delete during the download, removing the log from the device during a sync.

BTW, you are correct, the number of updates to the subscriber matches (or is some multiple of) the number of inserts on the subscriber. So far, we do not see this with normal syncs, only reinitializations.

One other thing to note is that we recreated the publication yesterday at around 7AM CST. This morning is the first time we are seeing the updates again, and they started sometime between yesterday evening (when the last reinitialization was recorded; worked fine) and this morning at 9:30AM (the first reinit that showed the duplicates). That being said, it took over a month for the previous publication to reach a multiple of 7.

Hope this all makes sense! This is getting more and more urgent as we send nearly 20,000 rows to some devices, meaning that their reinit is starting to take a larger and larger amount of time as the multiples go up.

Thanks!

Mike

|||

Thanks for the update.

do you generate a new snapshot prior reinitializing the subscriptions ? if the snapshot is old one and the subscription was reinitizlied. it will apply the snapshot and then apply the data in the mscontent table and if there are more and more updates/inserts on the publisher, this will give you this impression that subscriber was getting some unnecessary data.

also, you mentioned that there is a trigger on one of the published tables. is it possible you provide more details about it, or event better, send us the the publication script and the creation scripts for all the tables ?

Thanks

Yunwen

|||

First, yet another update: We removed and recreated the distribution database and publication after doing so on our test server and seeing the problem go away (usually we see some sort of duplication before a week has passed). So far so good, although it has not yet been 24 hours on the production side.

At the time of recreation in production, we were up to 5 times the number of updates as inserts, which means that it was going up by a multiple of 1 almost every 24 hours (although some days it skipped and the time the updates increased moved around; hopefully this removes scheduled jobs as a possible cause). I copied the distmdl and distribution files out before we recreated the distribution DB so that we can review a few of the critical system stored_procedures for differences, just in case the service pack did not update existing distribution databases correctly.

As to your questions...

Yes, we have tried generating a new snapshot to see if that would fix the issue. It had no effect. I agree that we may see some updates in there, but to have an exact multiple on every table would still not seem right to me. I would expect to see "random" updates throughout the articles.

I will look at scripting out the rest of the publication, but here is the trigger:

CREATE TRIGGER [dbo].[MoveLog]
ON [dbo].[LOG]
AFTER INSERT
AS
BEGIN
SET NOCOUNT ON;
BEGIN TRANSACTION

INSERT INTO LOG_HISTORY SELECT * FROM [LOG]
DELETE FROM [LOG]
IF @.@.error <> 0
BEGIN
ROLLBACK TRANSACTION
END
ELSE
BEGIN
COMMIT TRANSACTION
END

SET NOCOUNT ON;

END

Thanks,

Mike

|||

Almost forgot, we have a fax table that functions the same way as the log table. Also, both the log and fax table have no filters (as they are emptied after each sync;have yet to see them leave data in the table on the server or in any of our test SQL Mobile databases).

The triggers are identical to the point that you could just replace "LOG" with "FAX" and you would have it (in fact, that's how the fax trigger was created!).

Thanks again!

Mike

|||

Thanks for th update for this issue. yes, seeing update is exact X * insert number does indicate there could be issues.

so is both Log and log_history was published ?

Please keep us updated on the issue.

thanks

Yunwen

|||

Only LOG is published. Basically, the device logs to the log table. During a sync, the log entries are uploaded, the trigger fired (to move it to the history table), then the log entry is deleted off the device, during the download phase.

I am now working with MS support on the issue, so hopefully we can figure something out. So far, I am just gathering logs for review.

Thanks,

Mike

|||

Thanks Mike.

Working with MS support probably a good way to pursure this issue. they can instruct you how to trouble shooting this issue.

Thanks

Yunwen

|||

Hello,

we are running into the same issue (multiplied insert, updates, initial synchronization taking up to 10 times longer than on identical publication on sql2000). I am therefore very concerned if you finally solved the case?

Thanks in advance

Kuba

|||We are running into this same issue as well. It started out as updates matching the number of inserts, and has now gone to updates doubling the number of inserts. If anyone has any solutions or feedback on this issue, it'd be greatly appreciated!

Thanks,
Adrien.|||I have contacted Microsoft developer support and resolved this issue with them. It is a known issue and they have a hot fix for it. However, the fix won't be available publicly until the next service pack. If you want to resolve this issue sooner though, developer support will refund the cost of an incident since it is a known issue.

Adrien.|||

Hello,

are you sure whether the hotfix to the discussed problem is going to be available in SP2? I've seen the list of bugs fixed by SP2CPT and I can't find anything that seems to be related to the case. How do I conctact developer support, is it possible to obtain the single hotfix from them or from anybody else?

Thanks in advance

Kuba

|||Hello,

My contact at developer support told me that the hotfix would be available in the next service pack. Whether he meant for SP2, or a future service pack, who knows? If you can't wait for it to be ready in a service pack, yes you can get it from developer support. To contact them, browse to the MSDN home page while logged into MSDN, then click on "Support Incidents".

Adrien.

Merge Replication with SQL Mobile 2005

We are using SQL 2005 (SP1) and mobile agents with SQL Mobile. We are seeing an excessive number of updates after a device's database is reinitialized. My understanding was that if I generate a new snapshot or reinitialize all subscriptions (from the server), the devices would only get what the database looks like right now (inserts only) after syncing and/or reinitializing, but they are actually getting the right number of inserts and a huge number of updates in Replication Monitor. Any ideas?

Thanks!

Mike

Update: Found a weird thing with the updates: On our test server, the number of updates, after generating a snapshot and reinitializing the mobile db, exactly matches the number of inserts. On production, the number of updates being transferred is 6 times the number of inserts on every article, so it the mobile database should get 10 rows for an article (based on filters), it will show 10 inserts and 60 updates.

Hope this helps, although it seems pretty strange!

Mike

|||

are the any configuration difference or data load difference between the test server and the production server ?

and also, by saying "On our test server, the number of updates, after generating a snapshot and reinitializing the mobile db, exactly matches the number of inserts", you meant to say the "updates on the subscriber is the same number as the inserts on the subscriber", right ?

what is you publication looks like ? e.g. number of articles, RIs between them ? etc.

that'll help us to identify the issue.

thanks

Yunwen

|||

First of all, I have an update. We recreated the publication on our test server as well as our production server (causing outages to our customers). After doing so, everything went back to normal and we were only seeing inserts (no updates) after a subscription is reinitialized. Now, just this morning, our production server started showing duplicates again, right now the number of inserts is exactly the same as the number of updates. Another thing to note is that right before we recreated the publication in production, the ratio was up to 7 to 1 (updates to inserts), meaning that it went up again.

As to your question, we have 23 articles. All of them have filters based on HOST_NAME(), some have even more complex filters that use subqueries based on HOST_NAME as a simple join will not work. All tables have PK/FK relationships with the exception of several tables that have auditing fields (created by, modified by, etc). We do not have referential integrity as the assosiated data is not always transferred to the device, nor do we use these fields on the device except to set or update them. The only exception to this is a LOG table that contains a trigger to move the logs into a historical table so that we can gather information from the device. This produces an insert during the upload and a delete during the download, removing the log from the device during a sync.

BTW, you are correct, the number of updates to the subscriber matches (or is some multiple of) the number of inserts on the subscriber. So far, we do not see this with normal syncs, only reinitializations.

One other thing to note is that we recreated the publication yesterday at around 7AM CST. This morning is the first time we are seeing the updates again, and they started sometime between yesterday evening (when the last reinitialization was recorded; worked fine) and this morning at 9:30AM (the first reinit that showed the duplicates). That being said, it took over a month for the previous publication to reach a multiple of 7.

Hope this all makes sense! This is getting more and more urgent as we send nearly 20,000 rows to some devices, meaning that their reinit is starting to take a larger and larger amount of time as the multiples go up.

Thanks!

Mike

|||

Thanks for the update.

do you generate a new snapshot prior reinitializing the subscriptions ? if the snapshot is old one and the subscription was reinitizlied. it will apply the snapshot and then apply the data in the mscontent table and if there are more and more updates/inserts on the publisher, this will give you this impression that subscriber was getting some unnecessary data.

also, you mentioned that there is a trigger on one of the published tables. is it possible you provide more details about it, or event better, send us the the publication script and the creation scripts for all the tables ?

Thanks

Yunwen

|||

First, yet another update: We removed and recreated the distribution database and publication after doing so on our test server and seeing the problem go away (usually we see some sort of duplication before a week has passed). So far so good, although it has not yet been 24 hours on the production side.

At the time of recreation in production, we were up to 5 times the number of updates as inserts, which means that it was going up by a multiple of 1 almost every 24 hours (although some days it skipped and the time the updates increased moved around; hopefully this removes scheduled jobs as a possible cause). I copied the distmdl and distribution files out before we recreated the distribution DB so that we can review a few of the critical system stored_procedures for differences, just in case the service pack did not update existing distribution databases correctly.

As to your questions...

Yes, we have tried generating a new snapshot to see if that would fix the issue. It had no effect. I agree that we may see some updates in there, but to have an exact multiple on every table would still not seem right to me. I would expect to see "random" updates throughout the articles.

I will look at scripting out the rest of the publication, but here is the trigger:

CREATE TRIGGER [dbo].[MoveLog]
ON [dbo].[LOG]
AFTER INSERT
AS
BEGIN
SET NOCOUNT ON;
BEGIN TRANSACTION

INSERT INTO LOG_HISTORY SELECT * FROM [LOG]
DELETE FROM [LOG]
IF @.@.error <> 0
BEGIN
ROLLBACK TRANSACTION
END
ELSE
BEGIN
COMMIT TRANSACTION
END

SET NOCOUNT ON;

END

Thanks,

Mike

|||

Almost forgot, we have a fax table that functions the same way as the log table. Also, both the log and fax table have no filters (as they are emptied after each sync;have yet to see them leave data in the table on the server or in any of our test SQL Mobile databases).

The triggers are identical to the point that you could just replace "LOG" with "FAX" and you would have it (in fact, that's how the fax trigger was created!).

Thanks again!

Mike

|||

Thanks for th update for this issue. yes, seeing update is exact X * insert number does indicate there could be issues.

so is both Log and log_history was published ?

Please keep us updated on the issue.

thanks

Yunwen

|||

Only LOG is published. Basically, the device logs to the log table. During a sync, the log entries are uploaded, the trigger fired (to move it to the history table), then the log entry is deleted off the device, during the download phase.

I am now working with MS support on the issue, so hopefully we can figure something out. So far, I am just gathering logs for review.

Thanks,

Mike

|||

Thanks Mike.

Working with MS support probably a good way to pursure this issue. they can instruct you how to trouble shooting this issue.

Thanks

Yunwen

|||

Hello,

we are running into the same issue (multiplied insert, updates, initial synchronization taking up to 10 times longer than on identical publication on sql2000). I am therefore very concerned if you finally solved the case?

Thanks in advance

Kuba

|||We are running into this same issue as well. It started out as updates matching the number of inserts, and has now gone to updates doubling the number of inserts. If anyone has any solutions or feedback on this issue, it'd be greatly appreciated!

Thanks,
Adrien.|||I have contacted Microsoft developer support and resolved this issue with them. It is a known issue and they have a hot fix for it. However, the fix won't be available publicly until the next service pack. If you want to resolve this issue sooner though, developer support will refund the cost of an incident since it is a known issue.

Adrien.|||

Hello,

are you sure whether the hotfix to the discussed problem is going to be available in SP2? I've seen the list of bugs fixed by SP2CPT and I can't find anything that seems to be related to the case. How do I conctact developer support, is it possible to obtain the single hotfix from them or from anybody else?

Thanks in advance

Kuba

|||Hello,

My contact at developer support told me that the hotfix would be available in the next service pack. Whether he meant for SP2, or a future service pack, who knows? If you can't wait for it to be ready in a service pack, yes you can get it from developer support. To contact them, browse to the MSDN home page while logged into MSDN, then click on "Support Incidents".

Adrien.

Merge Replication trigger count

Hi,
I have Merge Replication ( Articles x,y) with Publications at 4 Sites and a
Central Subscriber. All the Merge Agents are running with property
-exchangetype 2 parameter
Article x have 12 triggers (4 for insert, 4 delete and 4 updates) which
looks OK ( 1 set for each publication) but article y has only 3 triggers(1
insert, i update and 1 delete). I am getting invalid following erros in the
conflict viewer:
1. The row was updated at 'SINDEV21.NewCase' but could not be updated at
'SINDEV20.NewCase'. Invalid object name
'ctsv_CAB6F215FE394ECAB4CE7DD56BD4B1B8'.
2. The row was updated at 'SINDEV21.NewCase' but could not be updated at
'SINDEV20.NewCase'. Unable to synchronize the row because the row was updated
by a different process outside of replication.
You need to reinitialize this subscription and resend your data. It looks
like your replication metadata is out of sync.
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
"Vikas Kohli" <VikasKohli@.discussions.microsoft.com> wrote in message
news:7DC1A948-B930-45A1-ACFF-BB88246FBC16@.microsoft.com...
> Hi,
> I have Merge Replication ( Articles x,y) with Publications at 4 Sites and
a
> Central Subscriber. All the Merge Agents are running with property
> -exchangetype 2 parameter
> Article x have 12 triggers (4 for insert, 4 delete and 4 updates) which
> looks OK ( 1 set for each publication) but article y has only 3 triggers(1
> insert, i update and 1 delete). I am getting invalid following erros in
the
> conflict viewer:
> 1. The row was updated at 'SINDEV21.NewCase' but could not be updated at
> 'SINDEV20.NewCase'. Invalid object name
> 'ctsv_CAB6F215FE394ECAB4CE7DD56BD4B1B8'.
> 2. The row was updated at 'SINDEV21.NewCase' but could not be updated at
> 'SINDEV20.NewCase'. Unable to synchronize the row because the row was
updated
> by a different process outside of replication.
|||When I had first configured this, everything was OK. However to carry a
schema change activity, I had dropped all the subscriptions and Publications,
dropped all the replication procedures, triggers manually wherever required
and reconfigure the Replication again after the schema change. It has started
giving error after then.I have tried removing replication a number of times
but each time same problem.
Also please let me know what should be the normal count of Triggers at the
Central Subscriber, is it 12 or 4?
"Hilary Cotter" wrote:

> You need to reinitialize this subscription and resend your data. It looks
> like your replication metadata is out of sync.
> --
> 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
> "Vikas Kohli" <VikasKohli@.discussions.microsoft.com> wrote in message
> news:7DC1A948-B930-45A1-ACFF-BB88246FBC16@.microsoft.com...
> a
> the
> updated
>
>
|||Just to add more...
I cant reinitialize the Replication since the Data volume is huge and I
can't send that accross WAN. I have to use the property 'do not initialize
Schema or data' when I add subscription.
"Vikas Kohli" wrote:
[vbcol=seagreen]
> When I had first configured this, everything was OK. However to carry a
> schema change activity, I had dropped all the subscriptions and Publications,
> dropped all the replication procedures, triggers manually wherever required
> and reconfigure the Replication again after the schema change. It has started
> giving error after then.I have tried removing replication a number of times
> but each time same problem.
> Also please let me know what should be the normal count of Triggers at the
> Central Subscriber, is it 12 or 4?
> "Hilary Cotter" wrote:
|||Hi,
Any help in this matter will be appreciated as we are encountering lot of
issues due to this
Vikas Kohli
"Vikas Kohli" wrote:
[vbcol=seagreen]
> Just to add more...
> I cant reinitialize the Replication since the Data volume is huge and I
> can't send that accross WAN. I have to use the property 'do not initialize
> Schema or data' when I add subscription.
> "Vikas Kohli" wrote:

Merge Replication limit running in continuous mode

Hi,
We have a customer site running merge replication with a
publisher/distributer and 12 subscribers. All the merge agents are running in
continuous mode. It seems that two of the agents are always failed, or don't
last long. Is this directly related to the "number of concurrent merge
processes" number? It looks like because there are 10 merge agents *always*
running, the other two don't get a look in. Is this correct?
We can increase this number to 20 and the site seems to run ok, but we've
been hearing rumours that any number past 10 concurrent merge processes gets
unstable. What's the MS position on this?
What's the recommended solution to this situation? Schedule the agents
instead of continuous mode?
What is the error message generated by these two always failing agents?
Do you have the "limit the number of concurrent merge processes to the
following" option checked and set to 10.
What happens is that for long running merge agents the agents will timeout
or deadlock themselves, so MS advised you to limit the number that run
concurrently.
If you do choose this option you have to configure your agents to wait a
longer time before timing out. To do this right click on your merge agents,
select agent properties, click on the Steps tab, and double click on Run
Agent. Place focus in the commands text box, press End, and press the space
bar. enter -StartQueueTimeout 120
This will have the effect of having these two failing merge agents of
waiting up to 2 minutes for the first 10 merge agents in the queue to finish
their work.
I am not sure what the rational for 10 was. The fact it seems to work fine
when you bump it up to 20 seems to indicate that this throttling is not
optimal for you. I suspect that you did not use StartQueueTimeout option.
Running the agents in continuous mode will have no effect. The agents poll
by default every minute, so after the agent completes it will go to sleep
for a minute, and any agents in the queue will have their timeslice.
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
"Sydney" <hsc@.newsgroup.nospam> wrote in message
news:5C49D704-C649-41FA-8686-3EA92151867F@.microsoft.com...
> Hi,
> We have a customer site running merge replication with a
> publisher/distributer and 12 subscribers. All the merge agents are running
> in
> continuous mode. It seems that two of the agents are always failed, or
> don't
> last long. Is this directly related to the "number of concurrent merge
> processes" number? It looks like because there are 10 merge agents
> *always*
> running, the other two don't get a look in. Is this correct?
> We can increase this number to 20 and the site seems to run ok, but we've
> been hearing rumours that any number past 10 concurrent merge processes
> gets
> unstable. What's the MS position on this?
> What's the recommended solution to this situation? Schedule the agents
> instead of continuous mode?
>

Merge Replication Agents

Hi everybody,
I have a system of 2 PC, with installed Win XP and SQL 2000. I
configured one PC as Publisher and Distrbutor, and the other as a
Subscriber with a "push" subscription. The snapshot and the merge
agents are running on the Publisher/Distributor. This PC is always ON
for 24 hours everyday, while the subscriber PC at the evening is
turned off and restarted at the morning.
Looking the Replication monitor at the morning, I see red cross on
both agents (snapshot and merge) and the synchronization doesnt' seem
working; if I restart the agents a message tells that the agent is
already running and the red flags disappear.
Anyone can help me to undertand better the situation, or give me some
suggestion?
Thanks a lot.
Marco
What error messages exist for the agents when there is a red cross - can you
please post it up. I'd expect that the merge agent would be killed if it is
synchronising during the process of rebooting the subscriber, but if there is
a schedule or it is set to run continously then it should restart ok. The
snapshot agent shouldn't be running at all after initialization. So, perhaps
the initialization never worked, and the merge agent failed because the
snapshot agent hadn't run? Anyway, please post up some more info and things
whould get clearer.
Paul Ibison
|||On 19 Giu, 17:57, Paul Ibison <Paul.Ibi...@.Pygmalion.Com> wrote:
> What error messages exist for the agents when there is a red cross - can you
> please post it up. I'd expect that the merge agent would be killed if it is
> synchronising during the process of rebooting the subscriber, but if there is
> a schedule or it is set to run continously then it should restart ok. The
> snapshot agent shouldn't be running at all after initialization. So, perhaps
> the initialization never worked, and the merge agent failed because the
> snapshot agent hadn't run? Anyway, please post up some more info and things
> whould get clearer.
> Paul Ibison
Hi Paul,
I don't know exactly what kind of error there is, because I dont' have
the PC with me; this problem has been explained me by another
technician that is testing the system. But I know that the merge agent
is setted to run continously, and that the synchronization was working
when I setted the replication process; only I tested it with the 2 PC
both running and I didn't test the condition with 1 PC running and the
other PC turned off.
|||OK - there's not much I can do without the error message. Try to get it off
your colleague and post it up and I'll take a look.
Cheers,
Paul Ibison