June 15, 2017 at 6:11 pm
Hi Community
There is one table in our replication environment. We have transaction replication configured
The data on subscribers for some rows (~4000 rows) mismatch on the subscribers from the publisher
I don't want to remove the table from replication and re-snap it
I was trying noupdate update on the table like below
update tblProduct
Set
<
Field 1 = Field 1,
Field 2 = Field 2,
.
.
.
.
>
I ran this on publisher. But I see that the subscribers didn't get the data
Does noupdate update work this way ?
What am I missing here ?
June 19, 2017 at 11:31 am
I can see a non-update like that being optimized to a NOP. You may need to use a function or two in a non-intrusive way to get the updates across. Maybe updating an int field by converting it to BIGINT. This should make the update a non-trivial update, but would result in an effective re-initialization of that table.
update table
set field1 = field1,
intfield = convert(bigint, intfield),
.
.
.
4000 rows does not sound like a lot. Why not reinitialize the publication? As for making sure this does not happen again, you may want to lock down the permissions on the table in the subscription database to make sure no one is updating it.
June 19, 2017 at 8:41 pm
Thanks for the reply.
The worst case would be reinitialize the complete table. We wanted to avoid it because the table was one of the core tables in our production environment
Re initialization would mean dropping and recreating the tables on subscribers, which would mean business outage.
June 20, 2017 at 4:29 am
Could you check settings on the article for UPDATE? u using SCALL for updates?
Here is more info:
https://docs.microsoft.com/en-us/sql/relational-databases/replication/transactional/transactional-articles-specify-how-changes-are-propagated
BartL
Replication Blog
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply