1. Source is one service pack behind destination (2012). I know service packs can be issues here, but it looks like this is only for versions 2000 and 2005.
  2. When using sp_helptext sp_MSupd_PROC the objects uses a CASE WHEN with the binary input (last parameter) and updates or adds columns with the other parameters where the primary key column is equal to the primary key passed in. For non-SQL types reading this - is there an Entity Framework approach to this, as this entire replication process looks slow and completely outdated and I highly doubt is using efficient .NET code?
  3. Using sp_help on the objects on both the source and destination show that they're both the same. Also, I did look at this briefly, but the no specific transaction number comes with the error - so I can't do his second step.
  4. I did a quick verification on the data in the table, confirming that it matches with the parameters shown from the sp_helptext.

I haven't found anything else I can do to troubleshoot here and updating service packs right now isn't an option. Note that this replication was fine yesterday and the day before yesterday, so what would cause it to be fine for multiple days, but now not be fine. I realize that if users change or update the source or destination object, that would cause problems, but I don't see that being the case.


1 Answer 1


It sounds like the replication procedures might need to be recreated. Use the sp_scriptpublicationcustomprocs procedure on the publisher to generate the replication procs and recreate them on the subscriber.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.