Trans. Replication failing -- "Cannot update identity column ..." -- unable to use sp_browsereplcmds to view statement

Question

All, I'm trying fix an issue with transactional replication where replication monitor is showing the push to the subscriber is failing because of the error, "Cannot update identity column."  I've tried to use sp_browsereplcmds to pull up the
command that's failing based on the xact_seqno but when I try that I get the error:
Number: 102, State: 1, Procedure: , LineNumber: 0, Server: , Source: .Net SqlClient Data Provider
Message: Incorrect syntax near '┻'.
I'd like to fix the issue without having to rebuild replication during a maintenance window.  I know you cannot publish tables with primary keys, but I'm wondering if dropping the identity column on this table might fix the issue.  I'm considering
that but I would prefer to be able to pull the command that's trying to update the identity column, throw in SET IDENTITY_INSERT ON and remove the commands from the distribution database, but if that doesn't work I'm open to ideas of just dropping the primary
key on the replicated table.  I think that should be fine.
Does anyone have any recommendations on how to view the command that's failing?
Or if dropping the primary key on the subscriber table would create issues with the publisher (since it is also the primary key)?
Or, know of any other ways in which to address this issue?  Thanks.

Answer 1

Unfortunately, no.  The error was a bit of a red herring.  In the end the subscriber was missing all of the stored procedures needed to update data in the published tables (i.e., the procedures for performing inserts/updates/deletes were missing
for every table in the subscriber database).  Additionally, I could not recreate these stored procedures using sp_scriptpublicationcustomprocs
because another procedure which was required for that proc to work was also missing. In short, there were hundreds of missing stored procedures in the subscriber database on which transactional replication is dependent in order to replicate DML changes and
function normally and this includes system sprocs which would've been used to recreate the missing DML procs. In short, the subscriber was badly damaged and deemed to be unrecoverable within a reasonable time frame.
The solution was to tear down and start over, which we did successfully later in the evening.