Merge republish Schema changes

Hello,

I'm working on a replication topology that is completely merge. We have a single consolidated instance (SQL 2005 SP1 Standard) that holds all data and is a continuous push merge publication filtered by region to regional instances (SQL 2005 SP1 Standard). Then we have individual user instances (SQL Express SP1) that pulls from the republished regional instances which is filtered by user. Both publications have Replicate Schema Changes set to true.

I'm testing out changes to tables and sps on a test system I've been using this process:

1-Run Snapshot on the Consolidated instance

2-Verify all published articles have a status of 2 in sysmergearticles

3-Run Regional Snapshot

4-Verify all published articles have a status of 2 in sysmergearticles

5-Run alter table scripts

6-Once all three levels have the table changes, run the alter sp scripts

I've gotten to step 5 and and the changes get replicated to the regional instance just fine however only the existing column changes get replicated to the SQLExpress instance, not the new columns. Looking at the articles in the regional publication it shows the new columns, but they are not selected. I know I can manually select them (or probably write a script that adds them to the publication although sp_repladdcolumn has been depreciated), but isn't there a way to make this a completely automated process since it's just a republished database? Also is the process I'm using the correct one?

Thank you,

Aaron Lowe

Is your publication property replication_ddl set to true?|||I apologize for not being clearer in my original post. I had said that replicate schema changes was set to true, this is the replication_ddl property that I was referring to. Thanks, Aaron|||when you add a new column, the column should get replicated to all nodes in your topology. Is the new column not getting replicated at all? Where in your topology are you adding the new columns - publisher, republisher or subscriber?|||I'm adding the columns at my original publisher (the consolidated one). As I said it is pushed down to my subscribers that republish the data (the regional ones that are pushed from the consolidated one), it just doesn't get all the way down to my final subscribers (the individual sqlexpress ones that pull the data). Looking at the properties of the publication on the republisher it shows the columns in the publication but they are not selected.|||if replicate_ddl option is truly enabled at both the publisher and the republisher, then I'm not sure what the problem is. You verified the replicate_ddl column is set to 1 in sysmergepublications table in the published database at both the publisher and republisher?|||

Well, I believe it's correct, here's what is in the sysmergepublications:

Consolidated database (original publisher)

publication name, replicate_ddl

Consolidated, 1

Region, 0

Regional database (republisher)

publication name, replicate_ddl

Consolidated, 1

Region, 1

SQL Express database (subscriber)

publication name, replicate_ddl

Consolidated, 0

Region, 1

Also the status in sysmergearticles in the consolidated db is 2 (active). There are two sets of articles in the sysmergearticles table in the regional db, one for each the consolidated and regional publication. The records in sysmergearticles for the consolidated publication has a status of 1 (Unsynced) while the records for the regional publication have a status of 2 (active). The status in the SQLExpress pull subscriptions is all 1 (Unsynced).

Thanks,

Aaron

|||Can you try your scenario with SP2? We fixed somewhat similar issue in SP2.sql

Merge replication: View Conflicts interface errors

Hi,

Not sure if this is the correct place to post this but I'm doing merge replication between SQL Server 2005 SP1 and SQL Server Mobile 2005 (on mobile devices) and I'm having some problems with data conflict resolution in the "View Conflicts" interface on the server management studio. The "Select Conflict Table" comes up and there are 5 tables listed. When I click on any of these tables I get an error dialog box titled "Microsoft Replication Conflict Viewer" and message "[ColumnName] is neither a DataColumn nor a DataRelation for table summary (System.Data)" with details:

===================================

CSRTechnicianID is neither a DataColumn nor a DataRelation for table summary. (System.Data)

Program Location:

at System.Data.DataRowView.get_Item(String property)
at Microsoft.SqlServer.Management.UI.ConflictViewer.ViewerForm.GetWinnerSQL(DataRow loserRow, Boolean blockFetch)
at Microsoft.SqlServer.Management.UI.ConflictViewer.ViewerForm.GetSourceRow()
at Microsoft.SqlServer.Management.UI.ConflictViewer.ViewerForm.FillDetailData()
at Microsoft.SqlServer.Management.UI.ConflictViewer.ViewerForm.FillDetail()
at Microsoft.SqlServer.Management.UI.ConflictViewer.ViewerForm.summaryInfoGrid_SelectionChanged(Object sender, SelectionChangedEventArgs args)
at Microsoft.SqlServer.Management.UI.Grid.GridControl.OnSelectionChanged(BlockOfCellsCollection selectedCells)
at Microsoft.SqlServer.Management.UI.Grid.GridControl.SelectedCellsInternal(BlockOfCellsCollection col, Boolean bSet)
at Microsoft.SqlServer.Management.UI.Grid.GridControl.set_SelectedCells(BlockOfCellsCollection value)
at Microsoft.SqlServer.Management.UI.ConflictViewer.ViewerForm.ResetSummaryGrid()
at Microsoft.SqlServer.Management.UI.ConflictViewer.ViewerForm.LoadConflict()

It then opens the conflict viewer window, and lists a conflict in the top grid, but nothing in the lower grid (usually shows details of the winner and loser records). In the top grid it shows conflict type as "4(Update/Delete, Update wins)" and the conflict loser is the mobile device subscriber. If I click on anything (Submit Winner, Remove) I get an error message "Column [Column Name] does not belong to table summary (System.Data)" with details:

===================================

Column 'CSRTechnicianID' does not belong to table summary. (System.Data)

Program Location:

at System.Data.DataRow.GetDataColumn(String columnName)
at System.Data.DataRow.get_Item(String columnName)
at Microsoft.SqlServer.Management.UI.ConflictViewer.ViewerForm.SetLogInfo(DataRow logRow, String sql)
at Microsoft.SqlServer.Management.UI.ConflictViewer.ViewerForm.btnSubmitWinner_Click(Object sender, EventArgs eg)

It seems that the conflict resolution function has gotten corrupted. Does anyone have any tips on how to fix this?

Regards,

Greg

Hi Greg,

This is a known issue which is now fixed in SQL Server 2000 SP2. Please try it and let us know if the problem persists.

The problem is that your table already had a roguid column which was named differently than what the conflict viewer was expecting.

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 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 UNIQUEIDENTIFIER Column?

Hi all,
I am using SQL 2005 sp1 to setup Merge replication for PDA access.
i created my Primary Key column a GUID using NEWID() as the default value.
When the snapshot was created it still went and added anothe GUID to all my
tables called rowguid.
i thought it was suposed to use the existing Unique GUID column before
creating a new one?
thanks for you advice. i hope i have the corect groups here?
inkquote:
If a published table does not have a uniqueidentifier column with the
ROWGUIDCOL property and a unique index, replication adds one
So, check for the rowguidcol property...
MC
"iKiLL" <iKill@.NotMyEmail.com> wrote in message
news:uS1$gVbWHHA.4796@.TK2MSFTNGP05.phx.gbl...
> Hi all,
> I am using SQL 2005 sp1 to setup Merge replication for PDA access.
> i created my Primary Key column a GUID using NEWID() as the default value.
> When the snapshot was created it still went and added anothe GUID to all
> my tables called rowguid.
> i thought it was suposed to use the existing Unique GUID column before
> creating a new one?
> thanks for you advice. i hope i have the corect groups here?
> ink
>|||Sorry my point was that i had created one and SQL2005 still created its own.
Now from what i can tell i think i have figgerd it out.
The behaviour i was expecting was how SQL 2000 handled the row GUID column
for snapshots.
i am using SQL 2005.
it seems that there is in fact a property of the column called RowGuid that
must be set to Yes before creating the first snapshot.
Then SQL2005 will use that column instead of creating it's own. Just setting
the data type and making it the primary key is not enough.
Thanks for your input Marko.
"MC" <marko.culoNOSPAM@.gmail.com> wrote in message
news:eruu6p$pcf$1@.ss408.t-com.hr...
> quote:
> If a published table does not have a uniqueidentifier column with the
> ROWGUIDCOL property and a unique index, replication adds one
>
> So, check for the rowguidcol property...
>
> MC
>
> "iKiLL" <iKill@.NotMyEmail.com> wrote in message
> news:uS1$gVbWHHA.4796@.TK2MSFTNGP05.phx.gbl...
>|||Yes, you need RowGuid property. Point is, you can have any number of
uniqueidentifiers in a table, but one of them needs to have this property
set. Since SQL Server doesnt want to guess which one would you like to have
as the 'main' GUID in a table, it adds another with rowguid property set.
Offcourse, if you allready have one it doesnt need to add it.
MC
"iKiLL" <iKill@.NotMyEmail.com> wrote in message
news:e2jo3%23bWHHA.600@.TK2MSFTNGP05.phx.gbl...
> Sorry my point was that i had created one and SQL2005 still created its
> own.
> Now from what i can tell i think i have figgerd it out.
> The behaviour i was expecting was how SQL 2000 handled the row GUID column
> for snapshots.
> i am using SQL 2005.
> it seems that there is in fact a property of the column called RowGuid
> that must be set to Yes before creating the first snapshot.
> Then SQL2005 will use that column instead of creating it's own. Just
> setting the data type and making it the primary key is not enough.
> Thanks for your input Marko.
>
>
>
> "MC" <marko.culoNOSPAM@.gmail.com> wrote in message
> news:eruu6p$pcf$1@.ss408.t-com.hr...
>

Merge replication UNIQUEIDENTIFIER Column?

Hi all,
I am using SQL 2005 sp1 to setup Merge replication for PDA access.
i created my Primary Key column a GUID using NEWID() as the default value.
When the snapshot was created it still went and added anothe GUID to all my
tables called rowguid.
i thought it was suposed to use the existing Unique GUID column before
creating a new one?
thanks for you advice. i hope i have the corect groups here?
ink
Sorry my point was that i had created one and SQL2005 still created its own.
Now from what i can tell i think i have figgerd it out.
The behaviour i was expecting was how SQL 2000 handled the row GUID column
for snapshots.
i am using SQL 2005.
it seems that there is in fact a property of the column called RowGuid that
must be set to Yes before creating the first snapshot.
Then SQL2005 will use that column instead of creating it's own. Just setting
the data type and making it the primary key is not enough.
Thanks for your input Marko.
"MC" <marko.culoNOSPAM@.gmail.com> wrote in message
news:eruu6p$pcf$1@.ss408.t-com.hr...
> quote:
> If a published table does not have a uniqueidentifier column with the
> ROWGUIDCOL property and a unique index, replication adds one
>
> So, check for the rowguidcol property...
>
> MC
>
> "iKiLL" <iKill@.NotMyEmail.com> wrote in message
> news:uS1$gVbWHHA.4796@.TK2MSFTNGP05.phx.gbl...
>

Merge Replication Synchronization Manager

Hi,
after upgrading a client within a Merger Replication scenario from MSDE2000A
to SQL Express SP1 the subscription is no longer listed within the
synchronisation manager.
How to register the subscription within Synchronization Manager?
(I know it is possible within Management Studio but I need to automate this
process).
Thanks in advance,
Thomas
have you tried to pull it again in WSM?
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
"ThoHot00" <ThoHot00@.discussions.microsoft.com> wrote in message
news:F36273CF-38BA-4A7C-A373-CB96CCDE37E4@.microsoft.com...
> Hi,
> after upgrading a client within a Merger Replication scenario from
> MSDE2000A
> to SQL Express SP1 the subscription is no longer listed within the
> synchronisation manager.
> How to register the subscription within Synchronization Manager?
> (I know it is possible within Management Studio but I need to automate
> this
> process).
> Thanks in advance,
> Thomas
|||Hi Hilary,
I haven't tried to pull it again within WSM. I would need to reregister it
within WSM, but since this upgrade occurs within a software upgrade I do not
have access to all client machines and I need a solution that I can integrate
into an installer package.
The subscription registration can still be found under
HKLM\Software\Microsoft\Microsoft SQL Server\80\Replication\Subscriptions\...
If I copy this entry to HKLM\Software\Microsoft\Microsoft SQL
Server\90\Replication\Subscriptions\... the subscription shows up in WSM and
works fine. I'm a little bit worried about the fact that within this key is
entry called subid. When I regenerate this entry using "Management Studio"
the subid is different and there is one additional entry called WebSync.
WebSync is always 0 in our case but I don't have a clue where the changed
subid comes from. If I call sp_helpmergepullsubscription it still shows the
"old" subid.
Greetings,
Thomas
"Hilary Cotter" wrote:

> have you tried to pull it again in WSM?
> --
> 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
> "ThoHot00" <ThoHot00@.discussions.microsoft.com> wrote in message
> news:F36273CF-38BA-4A7C-A373-CB96CCDE37E4@.microsoft.com...
>
>

Merge Replication Enumerations issues

we are using sql server CE on a pocket pc for our salesforce that syncs orders with a SQL2000 sp1 server via merge replication. we had an issue where one person tried to sync and got the error message

The process could not enumerate changes at the 'Subscriber'.

i understand this probably means something is out of sync. however, i am trying to determine what exactly is out of sync. any idea how to do this? i tried to enable vergose logging with the replmerge.exe utility at the command prompt, but becaase it is a mobile device, it could not find the server connected. (we tried connecting to sync the mobile device and running the utility at the same time, but it still did not find it as it said it was not a 'registered' server.)

any help is greatly appreciated.

thanks,
tammyWow! I didn't even know they made a CE version of SQL SErver?

Sorry no help..