Identity Error when replicating

I have some tables in a database that is tranactionally replicated to another
server.
Each table has a column which is the primary key as well as having the
Identity property set to Yes. The subscribing table has the same settings
for the corresponding column except that Indentity is set to 'Yes (Not for
replication)'.
When the tables replicate from an Insert transaction, everything is fine.
However, when doing an Update transaction, I get a "Cannot update identity
column 'RecordID'." error (Where RecordID is the column with the key and ID).
Is my server having mood swings?
How can I resolve this without setting the Indentity property to NO on the
subscriber?
p.s. I know that setting the subscriber column Indentity Property to Yes
isn't necessary since the publisher takes care keeping the key unique for me.
But if my publishing server ever goes down I would like a quick transition
to the subscribing server without having to change all the identity settings.
Roger,
on the subscriber there shouldn't be the identity attribute at all. You
could remove this attribute (identity - No), or edit the replication stored
procedures and comment out the second section. If you want it all to work on
failover you could use Queued Updating Subscribers, in which case the
replication stored procedures are coded differently and you won't have this
issue. Also, you'll have to consider the identity range, and the queued
updating option will do this for you if you select automatic range
management.
HTH,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||I just read the discussion between bert, Paul, and Hillary concerning this.
My scenario is not as intensive as bert's since I only have to deal with one
publisher and one subscriber.
I noticed bert was able to install SP4 beta but I couldn't find it. Is for
SQLServer2003? I am using SQLS2k.
How does one create Queued Update Subscribers? While I still be able to
retain my identity settings in my subscriber tables that use them?
"Roger Denison" wrote:

> I have some tables in a database that is tranactionally replicated to another
> server.
> Each table has a column which is the primary key as well as having the
> Identity property set to Yes. The subscribing table has the same settings
> for the corresponding column except that Indentity is set to 'Yes (Not for
> replication)'.
> When the tables replicate from an Insert transaction, everything is fine.
> However, when doing an Update transaction, I get a "Cannot update identity
> column 'RecordID'." error (Where RecordID is the column with the key and ID).
> Is my server having mood swings?
> How can I resolve this without setting the Indentity property to NO on the
> subscriber?
> p.s. I know that setting the subscriber column Indentity Property to Yes
> isn't necessary since the publisher takes care keeping the key unique for me.
> But if my publishing server ever goes down I would like a quick transition
> to the subscribing server without having to change all the identity settings.
|||Roger,
I'm not really sure what identity settings you currently have on your
subscriber. If you mean the actual Identity attribute, then queued updating
subscribers will add it (NFR). If you mean the identity value (number), then
this will be overwritten by the automatic range management unless you use a
nosync initialization. Nosync will have its ownb issues here in that you'll
have to manually reseed the subscriber tables on failover, so I'd not really
recommend it is you have a choice.
HTH,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||When you say "edit the replication stored procedures" are you talking about
the sp_MSins_TableName, sp_MSupd_TableName, etc, procs? If such is the case,
the section to comment out is after the 'else' statement?
If I go with Queued Updating, can I still keep the identity attribute
property of the column set to Yes on the subscriber?
Roger.
"Paul Ibison" wrote:

> Roger,
> on the subscriber there shouldn't be the identity attribute at all. You
> could remove this attribute (identity - No), or edit the replication stored
> procedures and comment out the second section. If you want it all to work on
> failover you could use Queued Updating Subscribers, in which case the
> replication stored procedures are coded differently and you won't have this
> issue. Also, you'll have to consider the identity range, and the queued
> updating option will do this for you if you select automatic range
> management.
> HTH,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
>
|||Roger,
yes this is the section I was referring to, but I would definitely go with
queued updating subscribers instead. The Identity property should be Yes,
Not For Replication on the publisher and it'll be transferred in this way to
the subscriber. Also don't forget to enable automatic range management to
make your life easier, otherwise you'll have to reseed each identity column
after failover.
HTH,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)