Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

View Conflicts list - automatically cleaned up? Expand / Collapse
Author
Message
Posted Thursday, August 07, 2008 1:07 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Wednesday, August 13, 2008 9:56 PM
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?

Post #548032
Posted Friday, September 12, 2008 8:48 AM
Right there with Babe

Right there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with Babe

Group: General Forum Members
Last Login: Sunday, March 02, 2014 4:34 PM
Points: 724, Visits: 1,001
How did you resync the databases.
Post #568590
Posted Monday, September 15, 2008 10:24 PM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Sunday, October 11, 2009 3:17 PM
Points: 23, 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
Post #569920
Posted Tuesday, September 16, 2008 6:36 AM
Right there with Babe

Right there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with Babe

Group: General Forum Members
Last Login: Sunday, March 02, 2014 4:34 PM
Points: 724, Visits: 1,001
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
Post #570153
Posted Tuesday, September 16, 2008 4:42 PM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Sunday, October 11, 2009 3:17 PM
Points: 23, 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



  Post Attachments 
Doc1.doc (25 views, 124.00 KB)
Post #570679
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse