August 7, 2008 at 1:07 am
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?
September 12, 2008 at 8:48 am
How did you resync the databases.
September 15, 2008 at 10:24 pm
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
September 16, 2008 at 6:36 am
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
September 16, 2008 at 4:42 pm
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