February 18, 2009 at 12:08 pm
We have a couple of articles being replicated that were created using transactional replication with updateable subscriptions. This works fine EXCEPT for certain columns which are columns that were added after the initial publication and subscription were created. We have tried to rebuild the sync triggers and procedures but to no avail. The interesting thing is that this uses a bitmask type converter for these updates which my guess is that it is not working right.
I do believe we can just re-snapshot and recreate the subscription but we don't want to have to do that. I do also know that we can use other methods of replication for this but there is more than one publication this could be affecting and I would like to get to the root cause of it.
If anyone has experienced this before and / or has any thoughts on this I would greatly appreciate hearing them. We are going to start a case with MS shortly if we can't figure it out so, if there is nothing out there I will post back what I find here.
Thanks in advance.
David
@SQLTentmaker“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
February 18, 2009 at 12:40 pm
These columns were propagated to the subscribers using ddl command replication ?
* Noel
February 18, 2009 at 12:43 pm
Yes, I believe so. I can't guarantee as I don't handle all object changes but that is our standard and they are set to replicate DDL changes.
David
@SQLTentmaker“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
February 18, 2009 at 1:19 pm
DavidB (2/18/2009)
Yes, I believe so. I can't guarantee as I don't handle all object changes but that is our standard and they are set to replicate DDL changes.
If the entire system was not quiesce at that time you got the Problem!
From BOL:
If the publication supports immediate updating or queued updating subscriptions, the system must be quiesced before making schema changes: all activity on the published table must be stopped at the Publisher and Subscribers, and pending data changes must be propagated to all nodes. After the schema changes have propagated to all nodes, activity can resume on the published tables.
To solve it you could try to drop the article only and then add it back.
* Noel
February 18, 2009 at 1:31 pm
Thanks Noel! I had totally read right over that. Appreciate you taking a look at this and following up! Truly appreciated.
If ever in Upstate NY feel free to drop me a line and I will buy lunch!
David
@SQLTentmaker“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
February 18, 2009 at 1:38 pm
Sure! 😀
* Noel
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply