Well - for this error in the log reader agent "Cannot insert duplicate key row in object..." there's some some bad news - I've faced this error before and had...

The behaviour of @@ERROR (and TRY...CATCH) depends on the scope of the error (check http://www.sommarskog.se/error-handling-I.html#whathappens)

For example:

BEGIN TRY

-- statement termination error

SELECT 1/0

END TRY

BEGIN CATCH

DECLARE @ErrMsg nvarchar(2048)

SET @ErrMsg = ERROR_MESSAGE()

SELECT @ErrMsg

END CATCH

GO

BEGIN...

From the script - are there any articles where the UndelivCmdsInDistDB is not 0 - the snippet you posted is for articles that have no (undelivered) data in the distribution...

One option - try re-installing OWC from http://www.microsoft.com/downloads/en/details.aspx?FamilyID=7287252c-402e-4f72-97a5-e0fd290d4b76&DisplayLang=en

Note - this might end up messing things up further (it is OWC after all hehe) but it might help as a last...

ah - looks to be in the correct forum now...I posted a reply to this information on the other thread http://www.sqlservercentral.com/Forums/Topic212720-110-1.aspx

So - there's no errors in replication monitor or in the distribution agent job history but the data doesn't seem to be flowing into the subscriber.

What happens when you open...

[edit]: Realized after just posting this that this is the SQL 7,2000 forum - the queries below run in my SQL 2008 environemnt and I don't know if they will...

It looks like there's an update to a row on the publisher that is failing as the appropriate row cannot be found on the subscriber...

Your options are:

a) Skip these kinds...

Some tools that I would recommend (which are available for free) are:

RML utilities -> 32 bit is available for download here http://www.microsoft.com/downloads/en/details.aspx?FamilyId=7EDFA95A-A32F-440F-A3A8-5160C8DBE926&displaylang=en and 64 bit is available for download here...

I don't see you selecting columns from the TVF in the view - there is a join to the TVF but you aren't selecting any of the TVF columns in...

nope - changing #tmp to tempdb.dbo.#tmp will not work...like I said - the issue is that the estimated execution plan (and I'm guessing the tuning advisor) cannot resolve temp tables...

If you're using the "Display Estimated Execution Plan" then the following will fail:

SELECT * INTO #T1 FROM sys.objects WHERE 1=2

-- uncomment the following line and use display estimated execution plan...

>>Set 'allow initialization through backup' on.

Did you turn this off on the publisher after the subscriber got synched with the publisher? It is not needed to be turned on once...

What kind of errors are you normally seeing happen with the proc?

You can try something like this -> create another SP that will return the row-count or an error...

You can find some useful information about the Initialize with Backup at http://gnawgnu.blogspot.com/2009/11/sql-2008-transactional-replication-and.html

) What is the purpose of the snapshot agent job when replication is done with "initialize with backup"?

>>...