August 8, 2006 at 7:08 pm
I recently added a new column named 'timestamp' (SQL Server default name) and data type timestamp, null to a table on our publisher DB expecting the new column to be replicated to all subscribers as I have done several times before for different data types.
This caused catastrophic problems and all subscriptions failed with schema imbalance errors despite the fact that, eventually, the new column DID appear on the subscriber tables. The insert, update and delete SPs which get altered when a new column is added to a published table did not address the new column which was the cause of our problems.
Does anyone know if the timestamp data type is a problem in merge replication (SQL Sever 2000) or is the root of my problem the fact that I called it 'timestamp' ?
I dropped the column from the published table and all returned to normal.
August 8, 2006 at 7:25 pm
My experience has been that the timestamp data type column is supported in merge replication - the exception being that its literal timestamp values are not replicated, that is, a new timestamp value is created at the time the records are updated at the subscribers.
If you add a new column using a SQL Server keyword like 'timestamp', I will make sure the SET QUOTED_IDENTIFIER ON setting is used with the replication (ins, upd, del) stored procedures for that particular article. Check that this is the case at each subscribing databases.
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply