View Conflicts list - automatically cleaned up?

  • 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?

  • How did you resync the databases.

  • 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

  • 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

  • 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

Viewing 5 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply