I have been reading up on how replicating schema changes work, but I must be missing something. When I configured a database for replication, it added a rowguid column to each table. This I understand.
I want to test making a schema change and replicating that change. For example, I tried to add a column to an existing table. When I tried to save the table i get the following error:
"Error validating the default for column rowguid".
"- Unable to modify table.
It is invalid to drop the default constraint on the rowguid column that is used by merge replication.
The DDL operation failed inside merge DDL replication manipulation.
The transaction ended in the trigger. The batch has been aborted."
So, what am I missing? Do i need to drop the rowguid column, add the new column, and then re-add the rowguid column?
Many thanks...
Well, it works if you do it via T-SQL. So, my question now is, what does the GUI (SSMS) do that T-SQL does not that let's T-SQL add a column to a table that is marked for replication?|||It's documented in BOL that schema changes via SSMS is not supported. See BOL topic "Making Schema Changes on Publication Databases", http://msdn2.microsoft.com/en-us/library/ms151870.aspx.
|||Thanks Greg. I figured out schema changes via SSMS was not supported, but I was wondering why. And I know that SSMS drops and re-creates the table for any changes. So my question was more out of curiosity than anything, wondering why SSMS does that and T-SQL doesn't.
Thanks again...
|||You should post that question in the Tools forum then |||The current SSMS design is that when you alter a table, it will drop and re-create the table underneath. Now one cannot drop a table when it is replicated. Because of this reason when SSMS is trying to drop the constraint/table, it throws up this error.
To workaround you can continue to make changes in TSQL.
No comments:
Post a Comment