I am thinking that I am going to have to turn off updating subscribers and just go with straight transactional replication from Server A to Server B.If Server A failed, then we would run off server B until A was fixed, restore Server B's copy of the database over Server A's, then restart the replication.Be sure to update a column that has not a unique constraint on it. Hugues Boivin Hi Hugues Boivin, I did some research on this problem with a simple table, but I was unable to repro the issue.You should get an error message telling that a unique constraint has been violated. I will do some more testing on this using the schema you supplied, and will post information based on my research. Ramu This posting is provided "AS IS" with no warranties, and confers no rights. For information about the Strategic Technology Protection Program and to order your FREE Security Tool Kit, please visit This was because I had created a unique index on the mrepl_tran_version column!!!Hi, I am trying to architect a system that has servers around the world.I am considering transactional replication with Queued Updating Subscribers (that uses MSMQ).
I have a transactional replication with queued updating.However, a command like this does not execute correctly : UPDATE T_Person SET Name = 'John Doe' I get this error message : "Cannot insert duplicate key row in 'T_Person' with unique index 'IX_repl_tran_version'".This is strange because I did not modify msrepl_tran_version.Regards, Hugues Boivin Here is the schema of the table :) CREATE TABLE [dbo].[T_Site] ( [Site Number] [smallint] NOT NULL , [Domain] [varchar] (20) NULL , [Location] [varchar] (255) NULL , [Contact] [varchar] (255) NULL , [Var Greenwich] [smallint] NULL , [Server Name] [varchar] (256) NULL , [msrepl_tran_version] [uniqueidentifier] NOT NULL ) ON [PRIMARY] GO ALTER TABLE [dbo].[T_Site] WITH NOCHECK ADD CONSTRAINT [DF__T_Site__msrepl_t__6ADB9D16] DEFAULT (newid()) FOR [msrepl_tran_version], CONSTRAINT [PK_T_Site_1__13] PRIMARY KEY CLUSTERED ( [Site Number] ) WITH FILLFACTOR = 90 ON [PRIMARY] GO Here are the steps to reproduce the problem (This takes about 5 minutes) : Just create the table with at the subscriber and the publisher.Then, replicate this table with a transactional publication that has queued updating enabled. Then, try to execute an UPDATE command with no where clause on the subscriber (to update all the rows in the table).
In merge replication, creating an index on the rowguid column helped to improve performance.