gk-411903 (10/21/2009)
HelloThe following is the error i am encoutering.
2009-10-12 22:45:19.579 Agent message code 20037. The process could not bulk copy
into table '"dbo"."MY_TABLE"'.
2009-10-12 22:45:19.683 Category:NULL
Source: Microsoft SQL Server Native Client 10.0
Number:
Message: Batch send failed
2009-10-12 22:45:19.716 Category:NULL
Source: Microsoft SQL Server Native Client 10.0
Number: 2627
Message: Violation of PRIMARY KEY constraint 'MYTABLE_PKEY'. Cannot insert duplicate key
in object 'dbo.MY_TABLE'.
2009-10-12 22:45:19.741 Category:NULL
Source: Microsoft SQL Server Native Client 10.0
Number: 20253
Message: To obtain an error file with details on the errors encountered when initializing
the subscribing table, execute the bcp command that appears below. Consult the BOL for
more information on the bcp utility and its supported options.
2009-10-12 22:45:19.766 Category:NULL
Source:
Number: 20253
Message: bcp "LDTST"."dbo"."MY_TABLE" in
"\\025edddb1\SQLREP\unc\SRCSERVER_LDTST_PUB_LDTST\20091012145537\MY_TABLE#1.bcp"
-e "errorfile" -t"<x$3>" -r"<,@g>" -m10000 -SDESTSRVR -T -w
I referred the following URL / website and introduced the -SkipErrors option. Does not seem to be helping.
Skipping Errors in Transactional Replication
http://msdn.microsoft.com/en-us/library/ms151331(SQL.90).aspx
The -SkipErrors Parameter
Also, when i created the Articles i chose the "keep existing object unchanged" option.
Any help would be appreciated.
Thanks
you mentioned that you selected keep existing objects unchanged. that means, replication will not drop and recreate the destination tables. It will start inserting rows into the destination tables without any validation and if the rows already exists, you may see these errors.
The workaround to get rid of these error is to set the option "Continue on Data Consistency error". It will ignore data consistency error and continue on replication.
Alternation solutions:
The permanent solution could be, if you can run the snapshot agent and recreate the destination tables from snapshot, however if you have any persisted data in destination table that does not exists in source table anymore, you will lose that persisted data.
-or-
Pause the replication, manually compare source and destination tables using joins, remove any consistency issues manually from destination table.
Swarndeep
http://talksql.blogspot.com