View Conflicts list - automatically cleaned up?

SQLServerCentral is supported by Red Gate Software Ltd.

Popular Topics

Home

Members

Calendar

Who's On

Home » SQL Server 2005 » SS2K5 Replication » View Conflicts list - automatically cleaned...

View Conflicts list - automatically cleaned up?

Rate Topic

Display Mode

Topic Options

Author

Message

Adrian Robertson-459741

Posted Thursday, August 07, 2008 1:07 AM

Forum 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

TRACEY-320982

Posted Friday, September 12, 2008 8:48 AM

Right there with Babe

Group: General Forum Members
Last Login: Friday, May 03, 2013 9:01 AM
Points: 722, Visits: 996

How did you resync the databases.

Post #568590

Adrian Robertson

Posted Monday, September 15, 2008 10:24 PM

Grasshopper

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

TRACEY-320982

Posted Tuesday, September 16, 2008 6:36 AM

Right there with Babe

Group: General Forum Members
Last Login: Friday, May 03, 2013 9:01 AM
Points: 722, Visits: 996

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

Adrian Robertson

Posted Tuesday, September 16, 2008 4:42 PM

Grasshopper

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 (21 views, 124.00 KB)

Post #570679

« Prev Topic | Next Topic »

Permissions