September 25, 2008 at 6:19 pm
Dear All,
My Replication monitor is failing with the following messages on the Distribution Agent?
Last command:
{CALL sp_MSupd_tblContractor_Or_Employee (NULL,NULL,NULL,NULL,N'Grundabirds Pty Ltd',N'Wayne Bird',NULL,NULL,N'12 Hoop Pine Road',NULL,NULL,NULL,NULL,NULL,N'(04) 0958 9429',NULL,NULL,NULL,NULL,NULL,NULL,N'251325952263',NULL,NULL,2008-08-22 00:00:00,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,1970-07-15 00:00:00,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,N'(02) 6672 2
Transaction sequence number and command ID of last execution batch are 0x0000E3C300001072000100000000 and 1.
Error message:
'The row was not found at the Subscriber when applying the replicated command.'
Error details:
The row was not found at the Subscriber when applying the replicated command.
(Source: VICGCSQL03 (Data source); Error number: 20598)
---------------------------------------------------------------------------------------------------------------
Would anybody please have a suggestion on what I can do to get this replication going again?
Many thanks guys!
Ryan
September 29, 2008 at 9:31 am
What version of SQL Server are you using? What type of replication are you using? I'm guessing transactional.
This message means that the record that replication is trying to update in the tblContractor_Or_Employee is not there, so the update statement is failing.
There are a few different ways to get past this that I have used in the past. Which one you choose depends on your business rationale for having replication and also you should do a little research covered below.
Option 1. Manually insert the record into the tblContractor_Or_Employee table and restart replication.
Option 2. Generate a profile to ignore replication errors, change to it and restart the distribution agent. This will ignore these errors then finish replicating the changes.
Option 3. Can you regenerate your subscription database from a backup of the publisher or generate and apply a new snapshot?
Option #1 is the safest but can be tedious if there are a lot of updates to deleted records. (Replication could fail again shortly after with another removed record.) I'd still go this route first, esp if Option 3 isn't a possibility.
Option 3 may not be a possibility due to db size, latency and possibly not being able to take down the subscriber db but will ensure that your dbs end up in sync.
Before taking action, you may also want to research who removed the record(s) and why. There are a few other commands you can run on the distributor to research what else is sitting in the queue, such as sp_browsereplcmds. You can use this to determine if there are a whole bunch of replication commands that will fail, in which case Option #2 might be preferable. IF you do go with option #2, I'd recommend you consider disabling the profile after everything is back in sync. The risk in this option is that you could end up with inconsistencies between Publisher and Subscriber. If you have to go this route, I'd also recommend using a db comparison tool to compare the two databases and see if they're in sync.
Hope this helps.
Chris.
Chris.
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply