i am trying to replicate a database in SQL 2000 using transactional
replication and on one of the tables, i recieve the following error
Cannot insert duplicate key row in object 'F98611' with unique index
'F98611_PK'.
(Source: JDEBACKUP (Data source); Error number: 2601)
------
Function sequence error
(Source: JDEBACKUP (ODBC); Error number: S1010)
------
Can anyone tell me what i need to do to have replication succeed, i am not
very knowledgable of SQL as i am a network admin,...so if you could explain
in basic terms i would greatly appreciate...you can email me at
malejandro@.armadillohomes.com
Thanks in advance
Mark,
this is because the subscriber has been treated in a read-write fashion, and
this needs to be explored to ensure it doesn't recur and to check the
differences between publisher and subscriber data. To get things up and
going though, you can add 2601 to the SkipErrors parameter of the
distribution agent profile and restart it.
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com/default.asp
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Paul,
thank you i have gone ahead and added 2601 to skiperrors in the distribution
profile. what do you mean by the 'subscriber has been treated in a readwrite
fashion' . i know what the subscriber is, but the rest is a little foreign to
me. I greatly appreciate your help and knowledge
"Paul Ibison" wrote:
> Mark,
> this is because the subscriber has been treated in a read-write fashion, and
> this needs to be explored to ensure it doesn't recur and to check the
> differences between publisher and subscriber data. To get things up and
> going though, you can add 2601 to the SkipErrors parameter of the
> distribution agent profile and restart it.
> Rgds,
> Paul Ibison SQL Server MVP, www.replicationanswers.com/default.asp
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
>
|||Mark,
for normal transactional replication, there is an implication that the
subscriber is read-only. If users start adding, deleting or updating data on
the subscriber in this type of replication, that can mess things up for when
data from the publisher is synchronized, as you have seen. If the subscriber
needs to be changed directly, normally a different subscription model is
chosen - immediate updating subscribers or queued updating subscribers.
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com/default.asp
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Ok, got that, but nobody is accessing the subscriber, we are using it for
failover purposes, Ive tried transactional and snapshot. Both fail at the
same table...
i have even tried to delete the table and have the snapshot recreate it, but
i get the same result.
"Paul Ibison" wrote:
> Mark,
> for normal transactional replication, there is an implication that the
> subscriber is read-only. If users start adding, deleting or updating data on
> the subscriber in this type of replication, that can mess things up for when
> data from the publisher is synchronized, as you have seen. If the subscriber
> needs to be changed directly, normally a different subscription model is
> chosen - immediate updating subscribers or queued updating subscribers.
> Rgds,
> Paul Ibison SQL Server MVP, www.replicationanswers.com/default.asp
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
>
|||Mark,
in the name comflicts section of the article properties, is it set to drop
the table if it exists? It should be, but perhaps in this case it isn't.
Also, have a look at this article:
http://support.microsoft.com/default...b;en-us;813494 which may be
relevant.
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com/default.asp
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Pual,
Yes, it was set to 'drop the existing table and recreate it'. anything else
i can look into?
"Paul Ibison" wrote:
> Mark,
> in the name comflicts section of the article properties, is it set to drop
> the table if it exists? It should be, but perhaps in this case it isn't.
> Also, have a look at this article:
> http://support.microsoft.com/default...b;en-us;813494 which may be
> relevant.
> Rgds,
> Paul Ibison SQL Server MVP, www.replicationanswers.com/default.asp
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
>
>
|||Mark,
unless the article helps, I'm almost out of ideas
In your situation, I'd remove the publication and delete the table then
recreate the publication. I'd enable logging
(http://support.microsoft.com/?id=312292) then run the distribution agent to
see at what stage things go wrong (if they do in this case).
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com/default.asp
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||In article <52127098-74C0-4993-A721-BB3E07BD3716@.microsoft.com>,
MarkAlejandro@.discussions.microsoft.com says...
> Pual,
> Yes, it was set to 'drop the existing table and recreate it'. anything else
> i can look into?
> "Paul Ibison" wrote:
>
I have had the exact same error when by mistake, i put the same table in
two different publications to the same subscriber db.
You need to right click each publication and look at the articles in
it. Make sure no publication has the same table in it.
select * from sysobjects where replinfo <>0 will give you a list of
replicated tables but not if they are in two different publications.
, you can temporarily turn onIDENTITY_INSERT when you want to insert a row with specifying identity number: