June 29, 2007 at 8:39 am
Hello all.
I am working on our company's BCP and have come across an issue with identity columns in the replicated database.
First of all, let me explain our topology. We are using transactional replication with a single publisher and a single pull subscriber.
I have a number of tables in my database that have a column with an IDENTITY constraint. I am using the NOT FOR REPLICATION option for these.
Here is the issue. In my testing, I want to use the replicated database. Bascially, I am restoring the replicated database to another server and pointing my app to it. I am finding that the current identity value for the tables in this database is 1.
I realize I can use DBCC CHECKIDENT to reset the current identity to the required value but I just wondered if I have missed something. Is using DBCC CHECKIDENT the correct way to go here?
We are running SQL Server 2005 sp2.
Thanks.
July 2, 2007 at 10:19 am
Why are you worried about the current_identity value on the replica if it is supposed to be read-only ?
* Noel
July 2, 2007 at 10:27 am
Hi Noel.
I am trying to conduct a test of our BCP. We replicate the database using transactional replication so that we have a backup.
In the event that we have a disaster, we will have to use this replicated database. I want to be sure I understand what is needed before it can be used.
I am not clear if synching up the current identity is a normal step in such situations or if I have not set up replication properly.
Hope this makes sense.
- Mike
July 2, 2007 at 11:48 am
Ok Because of that *same* reason we don't use IDENTITY columns. But if your recovery time allows you to run dbcc checkident, that, is how you do it. We just don't have that luxury though
* Noel
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply