could not deliver the snapshot to the subscriber

We have a customer w/ merge replication setup and has been functioning.
Their server's were hacked. We have spent 3 days on the phone w/ MS and
everything is working except for 1 client. When it is trying to deliver
the snapshot it is getting an error:
The process could not bulk copy into table {table name}
Violation of PRIMARY KEY constraint. Cannot insert duplicate key.
I understand what that means, so on that table (it is not a necessary
table, just a log), I deleted all records from that table and the
delivery got past that table to the next table in the list and displayed
the same message.
What can I do on the client to get this to work? I can't delete the info
in the second table because it is much more required and I don't want to
have it delete the same data on the main server. I know it is trying to
insert a new record that has the same primary key, but is it trying to
do that because the server record has one guid and the client has a
different guid (I don't really know how the guid's work in replication -
if the record has the same guid on all servers).
Darin
*** Sent via Developersdex http://www.codecomments.com ***
I would use a tool like RedGate's datacompare to reconcile the data to the
Publisher. You'll need to modify the scripts somewhat if you have PK issues
and then I'd reinitialize.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
|||I know they are duplicate keys. The client has a record w/ the key as 2
(identity column), so does the distributor. The snapshot is trying to
send that record down - why, and how can I make so the snapshot doesn't
try to send it down?
Darin
*** Sent via Developersdex http://www.codecomments.com ***
|||Hi.
In the publisher, mark that identity column which is acting as primary key
to NOT FOR REPLICATION in the design mode of that table.
in this case, the identity will be inserted independently at the subscriber
avoiding primary key errors.
"Darin" wrote:

> I know they are duplicate keys. The client has a record w/ the key as 2
> (identity column), so does the distributor. The snapshot is trying to
> send that record down - why, and how can I make so the snapshot doesn't
> try to send it down?
> Darin
> *** Sent via Developersdex http://www.codecomments.com ***
>
|||The table on both the subscriber and the distrubtor are setup that way.
Darin
*** Sent via Developersdex http://www.codecomments.com ***
|||Can you outline your situation a little more. Usually a snapshot of the
publisher's data is sent from the publisher to the subscriber. Initially
there is a drop table executed on the subscriber. There are variations - one
of which is a nosync initialization, where all the required info already
exists on the subscriber and the publisher just sends the metadata and
system stored procedures/triggers required to run replication. There are
other possibilities where the table and its data remain and the new data is
appended. Of these, which is your requirement, or is your requirement
something quite different?
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com