I have an issue that is only occurring in a production environment. The architecture is filtered merge replication between two SQL Server 2000 SP4 databases. The publisher is standard edition and the subscriber is personal edition.
The issue is that is I update certain rows on the subscriber the data is not replicated to the publisher. Inserts and deletes seem to replicate correctly. The issue is specific to certain rows in some tables. If I update other rows the updates replicate correctly. The subscription has been re-initialized once and it did not fix the issue. The replication process indicates that there was not data to merge and the subscriber updates remain and are at that point different form the publisher row values after the sync.
I can reproduce the issue by updating the row, running the sync process, and checking the publisher database. The synchronization process is executed using the merge agent ActiveX control.
This issue started occurring after a large conflict was generated during an earlier synch on this particular subscriber. We have other subscribing databases that are working fine.
I have already spent 8+ hours on the phone with TCS trying to solve this issue. If anyone has any ideas or has seen this type of issue before I would appreciate any direction to try to fix this issue.
Thanks
I ran another test today. I created a new database on a separate server and added a subscription to the publication and synced. The data came down correctly but my local updates to the specific rows where still ignored during the sync process.
I then updated the problem row in the publisher, synced to the new subscriber and now I can update the local row and it will sync back up to the publisher. Does anyone have any idea what happened to cause this?
can you tell us what's specific about the columns/rows you're updating? Are you updating the primary key column? Are you updating a column that's moving in and out of a partition?
|||There are actually 5 tables with 6 rows that if I update on the subscriber will not replicate to the publisher. These rows where all involved in a conflict at one time that was resolved. I setup a new database, subscriptions and synced and updates to these 5 rows will not propagate to the server.
I am updating a GUID field that is not the primary key and has no relation to the partition which is based on a join filter between these tables. The field I am updating is a last update key and its only purpose it to have a unique GUID that changes with each update. I can change other fields and the changes do not go to the publisher as well. The issue is definitely related to these rows as other rows will propagate to the publisher in the same tables.
Updating the row on the server seemed to fix one of the rows. The others are still broken.
Thanks for your help on this tricky issue.
|||Since you say that creating a new subscription to this publication still faces the same problem, can you try this:
1. Run the snapshot agent at the publisher.
2. Create a new subscription to this publication
3. Synchronize this subscription
4. Try the updates at the subscriber and synchronize
5. See if your updates are sent or not.
|||I have tried this test and the updates for these specific rows do not replicate from the subscriber to the publisher.|||
I have a question related to this issue:
I executed the sp_showreplicainfo stored procedure on the rows that will not update on the subscriber. The row info returned two rows. One with the server name set to the publisher database and another with the server name set to one of the subscribers (not the one I am testing with).
Is this expected behavior? The documentation on this is a bit thin.
|||
Hi Jeff , I'm having the same issue that you , but for me this start happeing after i install SP4.
I can't reinit all my suscriber (500+) , did you find the problem or a solution to this issue.
thxs. You can replay to my email at tutipedro@.hotmail.com
|||I am still working with Microsoft Technical support to try to find out why this happened. I did notices that when I update the rows that have the issue on the publisher side it seems to "unstick" the row and subscriber updates now work.|||
Something interesting came up related to this issue while working with Microsoft tech support. I have twotables in my database that have a one-to-one relationship with each other. In the two tables the rowid is the primary key. This means that I have duplicate rowid values in different tables (The same rowid value is in 2 tables at the same time).
Could this have caused my issue? Is this a supported schema for replication?
No is not an issue since the msmerge_contents include the article id table_nick.
|||Sorry - I posted this to the wrong thread - not sure how to delete
It seems like I've come accross the same issue this weekend (or something close) - that is, we are using merge replication on SQL2K SP4 - I wanted to increase a column size slightly so using a variation of the post on the Replication Answers website.
That is, store the data in a temp table, drop the column, re-add the column with the increase value, and then perform an update on the column - the first updates will make it to all the republisher and children. I've noticed that performing updates on this column for any value that was included in the first update does not propagate to the children. In the profiler, I can see the system procedure being called, but when one should field the new value it has "default".
What ended up being the issue is that we are using continuous replication so the skema changes got replicated to the subscribers before the snapshot finished running. What fixed the issue was to manual stop the merge agent, run the skema script, run the snapshot, and then sync. This time all was good.
-Ryan
|||
I have a question for you ..
run this query on your server
SELECT missing_cols, missing_col_count, * FROM sysmergearticles WHERE name LIKE '%<YOUR TABLE NAME>%'
Open the replication update triger on your server look out for this line of code
/* only do the map down when needed */
set @.missingbm = <SOME VALUE>
Are the missing_cols value equal to the @.missingbm in the trigger ?
|||Hello Pedro
I've got a similar problem, but changes from the publisher are not send to the subscriber after schema and datachanges. (No error message nor any conflicts indicated)
I've tried your instructions. And yes, I've got the same values (0x18). What does this mean? Can you explain it to me?
Thanks a lot
Aline
|||
Aline i'm short of time now a quick solution is , the replication triger for the tables that you know that have that problem should be the same in the susciber that in the server. Take the server (publisher) triger and run in the suscriber.
