Occationally, my publisher and push subscribers don't matchup on a few
tables. The subscriber has a few more rowguids than Publisher even after
synching. Synch glip or conflict or such.
What is the best practice to get them matching without cascading more
oddities to other subscribers?
When I try a meaningless update, to kick in the repl trigger, it doesn't
seem to move over. Delete and reinsert? Same Guid or new?
thanks for any suggestions.
Mike
If data falls in the woods and nobody is there to see it ...... ?
This can happen in several circumstances that I know of. Most likely it's
from when you bulk insert the rows and choose the defaults, then
FIRE_TRIGGERS is false and consequently the rows are not added to
MSmerge_contents. Also, if you do a fast-load using the Transform Data task
in DTS: In all cases case, you need to run sp_addtabletocontents to include
the rows then resynchronise. Alternatively you can use sp_mergedummyupdate
for a single row. For the fast load case, in future if you deselect the
check box the triggers will fire.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Thanks Paul.
The extra rows are on my pull subscriber (server) so I used the
sp_mergedummyupdate to test. It did add a row to the msmerge_contents table
but the generation didn't transfer to the publishers _contents table.
No synch error messages/conflicts. Other data is moving fine.
The extra rows were deleted 1/2/06, reasons unknown (system delete). I
reinserted them with a std insert from a restored db. ** I kept the original
rowguid.
Mistake? I wanted to avoid getting duplicate values in the table.
The pub does have the initial delete in tombstone (orig rowguid). Would
that would filter out the rowguid for future synching?
Mike
If data falls in the woods and nobody is there to see it ...... ?
"Paul Ibison" wrote:
> This can happen in several circumstances that I know of. Most likely it's
> from when you bulk insert the rows and choose the defaults, then
> FIRE_TRIGGERS is false and consequently the rows are not added to
> MSmerge_contents. Also, if you do a fast-load using the Transform Data task
> in DTS: In all cases case, you need to run sp_addtabletocontents to include
> the rows then resynchronise. Alternatively you can use sp_mergedummyupdate
> for a single row. For the fast load case, in future if you deselect the
> check box the triggers will fire.
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
>
|||I'm a little unsure of your current situation but if the rows don't exist at
all on the publisher then I'd delete these newly added subscriber rows, then
reinsert them and let new rowguids be created.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
Showing posts with label equalize. Show all posts
Showing posts with label equalize. Show all posts
Thursday, March 29, 2012
Equalize mis-synched tables
Labels:
database,
equalize,
fewtables,
matchup,
microsoft,
mis-synched,
mysql,
occationally,
oracle,
publisher,
push,
rowguids,
server,
sql,
subscriber,
subscribers,
tables
Subscribe to:
Posts (Atom)