Problem:
Using Transactional replication, our customized replication procs are sometimes overwritten on the subscriber with the standard MS replication procs for no apparent reason.
Impact:
This is causing business impact due to time to the extra time it takes to address and correct the problem - especially in Development and Test environments where data isn't always up to date.
Platform:
Microsoft SQL Server 2005 - 9.00.3282.00 (X64) Aug 5 2008 00:48:00 Copyright (c) 1988-2005 Microsoft Corporation Enterprise Edition (64-bit) on Windows NT 5.2 (Build 3790: Service Pack 2)
--AND--
Microsoft SQL Server 2008 (SP1) - 10.0.2723.0 (X64) Jul 9 2009 23:46:07 Copyright (c) 1988-2008 Microsoft Corporation Enterprise Edition (64-bit) on Windows NT 5.2 <X64> (Build 3790: Service Pack 2)
Scenario:
A new transactional replication publication is created with one article to one subscriber using a "@Sync_Type = NONE" subscription (due to large table size and the data already existing on the subscriber). By default, the MS replication procs are created on the subscriber in the subscription database (ie. sp_MSins_tablename). I overwrite the default replication procs with my own customized replication procs and all is good.
Some time later, maybe a day, maybe a month or more, replication fails with a data consistency error like "Row was not found at the subscriber when applying replicated command…". I look at the replication procs and see that they are the default MS replication procs and my custom procs have been overwritten by the system at some point, even though there were no alterations to the published table. Please ignore the fact there is a data consistency error - remember this affects us most in development where the data isn't always pristine. Part of the purpose of the custom repl procs is to deal with that type of error without having to ignore those errors.
I would expect the procs to get overwritten with default procs in the event that the published article was altered, but there is no evidence of this.
Looking at the system trace, I can see where SQL Server dropped and recreated the procs, but there is no supporting DML change that would have triggered this behavior.
As a stop-gap measure, I have turned off bit 2 of the Schema_Option column in sysarticles on the publisher. This is the equivalent of the GUI setting "Copy INSERT, UPDATE and DELETE stored procedures = FALSE" in the article properties, but this should not be necessary. The system shouldn't overwrite the custom replication procs for no reason. I'm sure there is a reason, but I can't figure out what it is.
Has anyone else experienced this behavior and effectively dealt with it?