February 22, 2006 at 7:33 am
Hello all,
I have set up a merge replication, and for the most part it is working. The replication consists of 1 parent table and 17 daughter tables. Merge replication added the rowguid field in the daughter tables, and it also added an index, called index_xxxxxxxxx, for each of these rowguids in the daughters.
Do I need these extra indexes for the rowguids? The daughter tables already had a primary key field called RECID, which is an identity field.
There is a checkbox option to ignore duplicates in the rowguid field; can I check this checkbox with no ill effects?
I ask because on just one parent/daughter combination, I am getting a primary key violation error, and I cannot add records to the daughter table. I'm fairly sure its because of a conflict in the rowguid field.
Thanks in advance for any help!
February 22, 2006 at 8:30 pm
The indexes on the rowguid columns are created because this is what merge replication uses to select data out of these tables. If the indexes are dropped, the system will continue to operate but it will become very slow because merge replication will be causing table scans whenever it runs.
The rowguid column used by merge replication must be unique. If not, you will, potentially, have significant problems because merge replication assumes that it is unique and if this is not the case, it may be attempting to update (merge changes) from 2 records which will not make sense. This will start to compromise the integrity of your database.
You need to work out what is causing your primary key violation. This is not likely to be anything to do with merge replication itself. You should review how you are creating new primary key values - is it possible that two servers can generate the same primary key ? Once you understand this, you will then need to determine how to resolve the primary key violation.
February 23, 2006 at 4:42 am
Don't worry about indexes on rowguid. The problem may not be with rowguid.
It could be one or more of the foll situations
a) Identity column should be set Not for replication
b) Foreign key columns should not (Neet to be unchecked) enforce relationship for replication. (the reason being during replication the order of data could be insert to child tables first and then parent table first, unless this is unchecked the process will enfore the same order for replicated data as well)
Hope this helps
rangark
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply