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 [quoted text, click to view] "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.
