Quantcast
Channel: SQL Server Replication forum
Viewing all articles
Browse latest Browse all 4054

SQL Merge Pull Replication over VPN - violation of Primary Key

$
0
0

Hi,

After a multitude of problems attempting to get web sync to work reliably, I have been testing replication over VPN and I've been impressed at the reliability.

I have now encountered an unexpected error and wonder if this is the start of a slippery slope of new replication issues.

While performing a routine sync, I noticed a conflict error on one of the tables as a result of a primary key violation.  Now I understand what this means, just not how it has occurred in this case.

For historic reasons we are using a merge replication, but in fact we only use replication as a one way process, single server downloading data to multiple clients.  All of our articles are marked as download only.  Our client application does not attempt to insert, delete or update any data and wouldnt be able to anyway, since I cannot even change the data via SSMS since the tables are download only.

The problem table has had a single row inserted today.  I know this, because as part of my testing this morning i regenerated the snapshot for the publication.  When I reinitialize my subscriber and perform a sync, I can see that initially my local table is wiped clean and then after the bulk copy has completed for that table, it has 3277 rows.

Once all of the snapshot has been applied, the sync then attempts to apply any updates that have occurred since the snapshot was generated.  It successfully inserts row with primary key 3278 into my subscriber database.  It then complains that it cannot insert row 3278 due to a primary key violation.

Is their an explanation for how this could occur? My current guess is that maybe the row was inserted at the publisher, deleted and then re-inserted, and somehow the sync fails to send the delete command in between the two inserts. I have no evidence that this deletion occurred, I'm just trying to make sense of it.

Any one have any idea what might be happening and how to avoid it?  I'm currently assuming that I now need to recreate the snapshot and fully resync to fix the problem.  This isn't something I'm going to want to see on a regular basis when we put this into production.


Viewing all articles
Browse latest Browse all 4054

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>