SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


View Conflicts list - automatically cleaned up?


View Conflicts list - automatically cleaned up?

Author
Message
Adrian Robertson-459741
Adrian Robertson-459741
Forum Newbie
Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)

Group: General Forum Members
Points: 3 Visits: 11
After I have resolved a insert type conflict and re-synched the DBs, when I click on View Conflicts it is still there. Going into the details of this I can see that is was for previous synchronisations, when it was conflicting.

Does this tidy itself up, or do I have to manually remove them from the list?

Is there some form of Maintenance Plan that takes care of this, or similar?
TRACEY-320982
TRACEY-320982
SSCertifiable
SSCertifiable (6.2K reputation)SSCertifiable (6.2K reputation)SSCertifiable (6.2K reputation)SSCertifiable (6.2K reputation)SSCertifiable (6.2K reputation)SSCertifiable (6.2K reputation)SSCertifiable (6.2K reputation)SSCertifiable (6.2K reputation)

Group: General Forum Members
Points: 6202 Visits: 1014
How did you resync the databases.
Adrian Robertson
Adrian Robertson
SSC Veteran
SSC Veteran (255 reputation)SSC Veteran (255 reputation)SSC Veteran (255 reputation)SSC Veteran (255 reputation)SSC Veteran (255 reputation)SSC Veteran (255 reputation)SSC Veteran (255 reputation)SSC Veteran (255 reputation)

Group: General Forum Members
Points: 255 Visits: 107
TRACEY (9/12/2008)
How did you resync the databases.


First of all I needed to resolve the conflicts, which I did manually (there weren't all that many)

Then I just manually started a synchronisation via Replication Monitor > Subscription Watch List > double clicked the appropriate subscription and just set it off from the Actions menu

You should just be able to kick of the job under SQL Server Agent jobs from the Publisher also (assuming it's a push subscription)

Or do you mean how did I re-synch in the scenario that a replicated table does not have the same records in it (Subscriber compared to Publisher) even though there is no row filtering occuring? I had this happen to me too, so just trying to figure out what the problem you're having is
TRACEY-320982
TRACEY-320982
SSCertifiable
SSCertifiable (6.2K reputation)SSCertifiable (6.2K reputation)SSCertifiable (6.2K reputation)SSCertifiable (6.2K reputation)SSCertifiable (6.2K reputation)SSCertifiable (6.2K reputation)SSCertifiable (6.2K reputation)SSCertifiable (6.2K reputation)

Group: General Forum Members
Points: 6202 Visits: 1014
Yes basically how did you determine the two were out of sync i.e Publisher table was 100 and the subscription table was 90.

So did you use the script - tablediff but that just for one table.

Then did you just run this in the subscription.


(Now the watch list part you mentioned what was this for).

Thanks
Adrian Robertson
Adrian Robertson
SSC Veteran
SSC Veteran (255 reputation)SSC Veteran (255 reputation)SSC Veteran (255 reputation)SSC Veteran (255 reputation)SSC Veteran (255 reputation)SSC Veteran (255 reputation)SSC Veteran (255 reputation)SSC Veteran (255 reputation)

Group: General Forum Members
Points: 255 Visits: 107
The way I determined what was out of synch was by using the Validate Subscription option

If you open Replication Monitor > click on the Subscription Watch List Tab > double click on the relevant subscription > select Validate Subscription from the Action menu, and then the next time the replication job takes place the system will validate the replicated tables on the Publisher / Subscriber (see attachment)

It will then list out for you any tables that are not in synch

You have two options when selecting Validate Subscription:
As a basic row count (so this is fairly quick)
Check the data within the rows (never done this, but expect it to take a lot longer)

That at least gives you an idea of the scope of the problem, if you don't already know

As mentioned in the other thread though, I don't know of any way of having the tablediff utility go through and check all tables within the replication model

When I had a problem with un-synched tables, I had only about 6 tables out of synch so it was no biggie to run tablediff 6 times

If you have hundreds of tables out of synch, then you may have bigger issues than what tablediff is designed for
Attachments
Doc1.doc (36 views, 124.00 KB)
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum







































































































































































SQLServerCentral


Search