Receiving 'PRIMARY KEY constraint 'PK__@snapshot_seqnos' error...

I'm adding a new subscriber to a transactional publication (no snapshot) and
I'm receiving a 'Violation of PRIMARY KEY constraint
'PK__@.snapshot_seqnos__543BF21A'. Cannot insert duplicate key in object
'#5253A9A8'.' error. The subscriber, remote distributor and publisher are all
running SP3.
I did some research and it appears this is fixed in MS03-031:
http://support.microsoft.com/default...b;en-us;813494
Can this be installed just on the distributor w/o affecting the other
systems? We actually have 5 other subscribers and some also publish to other
subscribers and also to other publishers so I don't want to affect any of the
other other servers.
TIA!!
Darin
While I can't comment about your individual case, I find that using
different service pack levels/hotfixes across the computers involved in a
replication topology can give unpredictable results. The recommended upgrade
path does start with the distributor, then publisher then subscriber, but in
your case I'd apply sp4 to all computers (in this order but in one shot)
rather than one by one and running replication inbetween.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Have a look at this post.
http://groups.google.com/group/micro...0?dmode=source
This will fix it. IIRC you will make this change on the distributor.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"DTully" <DTully@.discussions.microsoft.com> wrote in message
news:45B780CE-96CF-45AE-8716-BE22A062C5FE@.microsoft.com...
> I'm adding a new subscriber to a transactional publication (no snapshot)
> and
> I'm receiving a 'Violation of PRIMARY KEY constraint
> 'PK__@.snapshot_seqnos__543BF21A'. Cannot insert duplicate key in object
> '#5253A9A8'.' error. The subscriber, remote distributor and publisher are
> all
> running SP3.
> I did some research and it appears this is fixed in MS03-031:
> http://support.microsoft.com/default...b;en-us;813494
> Can this be installed just on the distributor w/o affecting the other
> systems? We actually have 5 other subscribers and some also publish to
> other
> subscribers and also to other publishers so I don't want to affect any of
> the
> other other servers.
> TIA!!
> Darin

Rebuildix clutered index on different field

Hello!
I have got a table with clustered key defined on primary key. This tables is
referenced using FK by hundreds of other tables using its primary key. I am
trying to build clustered index on different column in the most efficient
way. It looks like I have to drop PK constraint first before changing
clustered index. This also means I have to drop/recreate all FK constraints
which could be time consuming. I suppose disabling constraints wouldn't
help. Is there quickest way of changing clustered index?
Thanks,
IgorHi
As there can only be one clustered index on a table I think you will need to
drop it which would require all FKs referencing it to be dropped first,
although alternatively you may want to create an indexed view that can have
it's own clustered index.
John
"Igor Marchenko" <igormarchenko@.hotmail.com> wrote in message
news:eftV0UGPFHA.3356@.TK2MSFTNGP12.phx.gbl...
> Hello!
> I have got a table with clustered key defined on primary key. This tables
> is referenced using FK by hundreds of other tables using its primary key.
> I am trying to build clustered index on different column in the most
> efficient way. It looks like I have to drop PK constraint first before
> changing clustered index. This also means I have to drop/recreate all FK
> constraints which could be time consuming. I suppose disabling constraints
> wouldn't help. Is there quickest way of changing clustered index?
> Thanks,
> Igor
>|||Thanks, John. I have come up with script that drops recreates FK
automatically.
"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:%23qxCINOPFHA.1932@.tk2msftngp13.phx.gbl...
> Hi
> As there can only be one clustered index on a table I think you will need
> to drop it which would require all FKs referencing it to be dropped first,
> although alternatively you may want to create an indexed view that can
> have it's own clustered index.
> John
> "Igor Marchenko" <igormarchenko@.hotmail.com> wrote in message
> news:eftV0UGPFHA.3356@.TK2MSFTNGP12.phx.gbl...
>