Hi Shiva,
I read back your first post on this thread, and I think I get what you mean.
Definitively: "select reserve_identity()" is never replicated as is, because it is a "Select" statement.
The reserved identity value is/are expected to be replicated by the "Insert" statement following in the same transaction.
In your case, if you issue "select reserve_identity("myID", 1)" over a user table named "myID" having the identity column and never fire the "Insert" statement on that user table, but only on others ones, yes, this will lead to the Standby side not be aware/updated of what could be the
next valid identity value (it will be fine for the others user tables).
I’m not sure you could get a nice solution because of the way you use “reserve_identity()” (which is not what it aim to).
Without setting the store procedure for replicate, the issue will be when you will “switch active”. In
such case you may have to add an additional step in your “switch” process and process a call to
“dbcc set_identity_burn_max(dbname, objname, option)” in order to set the next identity value you want on the Standby side (which is in process to became the Active)
Having the store procedure set for replicate (instead of only the table), the risk is to get the store
procedure call not replicated in same order than at primary (transaction are replicated in “commit” order).
But I do not really see/get why you hit “Duplicate Key” error in such case, the user table populated inside the store procedure, is it also populated outside the store procedure? (which can explain)
Do you have a way to avoid this?
Regards
Yvan