Monday, March 19, 2012

Hexadecimal condition check and Identity columns

hi , i am using transactional replication between two Sql server 2000 . my
tables have identity columns as the primary keys with the identity property
set to Yes( not for replication). Now when I am generating the replication
intrinsic stored procs for the subscriber , I have a problem with the update
stored procs which are generated at the subscriber side. Each of these Update
command SPs ( which are each for a table) have two update statements in them
and a IF statement which chooses one of the udpate statements to run
depending on a binary hexa decimal field. If the condition satifies , it run
the first update query which unlike the second update query updates the
identity column as well and this update query is always selected by the
Update statement to run. The second if stement is run when the hexadicmal
conditions is not met and the funny part is that it never ever happens. I had
to comment out the part of the first update query which tried to update the
identity column. Now my queston are
1.why is replication trying to update the identity columns when it know
that they can not be updated.
2.What is the binary hexadecimal field used for, why is this the condition
in each and every case select statement in every field?
Please help me with this hexadecimal paradigm
The IF statement checks to see if the PK is being updated, and if so
executes the update statement differently. This is not related to identity
columns. If you have an identity column on the subscriber, compilation of
this procedure may fail. That's because the identity attribute shouldn't be
there - it's implicitly treated as read-only. If you had queued updating
subscribers the logic in these sps is different and there is no update or
insert into the identity columns because the identity attribute is expected
on the subscriber.
HTH,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)

No comments:

Post a Comment