We have three distinct environments that a databse resides in: a lab
environment, merge replicated with other lab servers, a production
environment, merge replicated with other production servers, and a
development environment not replicated anywhere. We do not want day-to-day
development (schema and data changes) to effect either the lab or production
environments, however periodically would like to take these changes and apply
them to the lab environment. Unfortunately, all tools that we have used to
copy these schema changes from development to lab fail since replication is
not configured in the development environment (and therefore schema migration
fails due to the lack of row guids and/or default value differences). How
can we easily and routinely (but manually) package schema changes from a
non-replicated database and push them into a replicated database, without
breaking replication itself? Once the schema is migrated, moving data seems
trivial.
It seems that your problem is due to the guids and related metadata not
being present in the dev environment. I think the best way to do this would
be to either merge publisher the dev environment, or to add the guid columns
with the unique indexes on each table you are replicating like this:
alter table MyTable
add [rowguid] [uniqueidentifier] ROWGUIDCOL
NOT NULL
CONSTRAINT [MSmerge_df_rowguid_MyTable] DEFAULT (newid())
Hilary Cotter
Director of Text Mining and Database Strategy
RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.
This posting is my own and doesn't necessarily represent RelevantNoise's
positions, strategies or opinions.
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Zer0Day" <Zer0Day@.discussions.microsoft.com> wrote in message
news:2B2E7210-1416-482D-AC33-31DD7CEA1A67@.microsoft.com...
> We have three distinct environments that a databse resides in: a lab
> environment, merge replicated with other lab servers, a production
> environment, merge replicated with other production servers, and a
> development environment not replicated anywhere. We do not want
> day-to-day
> development (schema and data changes) to effect either the lab or
> production
> environments, however periodically would like to take these changes and
> apply
> them to the lab environment. Unfortunately, all tools that we have used
> to
> copy these schema changes from development to lab fail since replication
> is
> not configured in the development environment (and therefore schema
> migration
> fails due to the lack of row guids and/or default value differences). How
> can we easily and routinely (but manually) package schema changes from a
> non-replicated database and push them into a replicated database, without
> breaking replication itself? Once the schema is migrated, moving data
> seems
> trivial.
Friday, March 23, 2012
Merge Replication Schema Changes
Labels:
database,
databse,
distinct,
environments,
lab,
labenvironment,
merge,
microsoft,
mysql,
oracle,
productionenvironment,
replicated,
replication,
resides,
schema,
server,
servers,
sql
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment