q***@yahoo.co.uk
2007-04-18 14:24:39 UTC
Hi,
SQL 2000 ENT; SP4.
Thre setup here is two databases, each with over 600 tables. Each
table has a UID column that is an IDENTITY (1,1) column. Thge
databases are on a SQL Cluster and we want to replicte to a DR Server.
I setup transactional replication and create a publication and
subscription for each database and this works fine. The issue is when
we come to test the databases on the DR server. We stop replication
and try and edit some data however it is messed up as the IDENTITY on
each UID column has not been copied across, nor has the primary key.
I have tried to use NOT FOR REPLICATION however this has not worked.
1. Do I need to run a script before we start editing data on the
subscriber (after we have stopped replication) so that I can reapply
the primary keys and identity?
2. Can transactional replication copy across a column's identity?
3. When I setup a subscription and select the "subscriber already has
schema and data" the replication doesn't work and I get a "cannot find
sp_msins<tablename>" error.
I have also just found out about the following in SP4:
5.2.20 New Schema Option for Replicating Identity Columns in
Transactional Publications
Introduced in SP4
In previous releases, identity columns in transactional publications
were replicated as the
base data type, such as int, without the identity property set. This
approach is
appropriate for applications that do not allow inserts at the
Subscriber. SQL Server 2000
SP4 introduces a new schema option (0x4) for transactional
publications, which is used to
replicate the identity column as an identity column. This is useful in
a number of cases,
including bidirectional replication and using the Subscriber as a warm
standby server. In
these cases, inserts can occur at the Subscriber, and the inserts
result in the identity
column being incremented.
To specify that an identity column should be replicated as an identity
column:
When creating the table at the Publisher, specify the NOT FOR
REPLICATION option for the
identity column. This ensures that only user inserts, not replication
agent inserts,
increment the identity column. For more information, see "CREATE
TABLE" in SQL Server Books
Online.
When adding an article with an identity column, set the option 0x4 for
the @schema_option
parameter of sp_addarticle. For more information about this parameter,
see "sp_addarticle"
in SQL Server Books Online.
After initializing the Subscriber, execute DBCC CHECKIDENT for each
table with an identity
column. This allows you to specify a starting value for inserts into
the identity column at
the Subscriber, so that the values inserted will not be the same as
those inserted at the
Publisher. For example, you could specify that inserts at the
Subscriber should start at
1,000,000:
USE Northwind
GO
DBCC CHECKIDENT ('Employees', RESEED, 1000000)
GO
For more information, see DBCC CHECKIDENT in SQL Server Books Online.
Given the above steps would I have to create publication via scripts
since I have to specify the option 0x4 in sp_addarticle?
Please help!
Thanks
Scott
SQL 2000 ENT; SP4.
Thre setup here is two databases, each with over 600 tables. Each
table has a UID column that is an IDENTITY (1,1) column. Thge
databases are on a SQL Cluster and we want to replicte to a DR Server.
I setup transactional replication and create a publication and
subscription for each database and this works fine. The issue is when
we come to test the databases on the DR server. We stop replication
and try and edit some data however it is messed up as the IDENTITY on
each UID column has not been copied across, nor has the primary key.
I have tried to use NOT FOR REPLICATION however this has not worked.
1. Do I need to run a script before we start editing data on the
subscriber (after we have stopped replication) so that I can reapply
the primary keys and identity?
2. Can transactional replication copy across a column's identity?
3. When I setup a subscription and select the "subscriber already has
schema and data" the replication doesn't work and I get a "cannot find
sp_msins<tablename>" error.
I have also just found out about the following in SP4:
5.2.20 New Schema Option for Replicating Identity Columns in
Transactional Publications
Introduced in SP4
In previous releases, identity columns in transactional publications
were replicated as the
base data type, such as int, without the identity property set. This
approach is
appropriate for applications that do not allow inserts at the
Subscriber. SQL Server 2000
SP4 introduces a new schema option (0x4) for transactional
publications, which is used to
replicate the identity column as an identity column. This is useful in
a number of cases,
including bidirectional replication and using the Subscriber as a warm
standby server. In
these cases, inserts can occur at the Subscriber, and the inserts
result in the identity
column being incremented.
To specify that an identity column should be replicated as an identity
column:
When creating the table at the Publisher, specify the NOT FOR
REPLICATION option for the
identity column. This ensures that only user inserts, not replication
agent inserts,
increment the identity column. For more information, see "CREATE
TABLE" in SQL Server Books
Online.
When adding an article with an identity column, set the option 0x4 for
the @schema_option
parameter of sp_addarticle. For more information about this parameter,
see "sp_addarticle"
in SQL Server Books Online.
After initializing the Subscriber, execute DBCC CHECKIDENT for each
table with an identity
column. This allows you to specify a starting value for inserts into
the identity column at
the Subscriber, so that the values inserted will not be the same as
those inserted at the
Publisher. For example, you could specify that inserts at the
Subscriber should start at
1,000,000:
USE Northwind
GO
DBCC CHECKIDENT ('Employees', RESEED, 1000000)
GO
For more information, see DBCC CHECKIDENT in SQL Server Books Online.
Given the above steps would I have to create publication via scripts
since I have to specify the option 0x4 in sp_addarticle?
Please help!
Thanks
Scott