Replication is one of the trickiest things in SQL Server and especially when you don’t know the solution of the issue. One such issue we faced a few days back which we were able to solve using a small trick. Here is what happened.:
Snapshot got generated on publisher but failed to apply on subscriber. Below was the error message in replication monitor-
The stored procedure gets an XML variable (or a constant or a literal) and a datatype's name.
For example:
EXECUTE dbo.StoredProcedure
@XMLParameter = '<Parameter val = "812"/>',
@DataType = 'NUMERIC(16,2)'
(Transaction sequence number: 0x0040B83700058F4B01C000000000, Command ID: 16813)
Error messages:
· Missing end comment mark '*/'. (Source: MSSQLServer, Error number: 113)
Get help: http://help/113
· Missing end comment mark '*/'. (Source: MSSQLServer, Error number: 113)
Get help: http://help/113
Initially, we thought to be problem with a particular stored procedure and tried to exclude that SP while running snapshot. But this error then came for some another SP.
We searched google with this error message and found that there is some missing comment “*/” in the SP. Based on our findings, we parsed all the stored procedures and found them to be perfectly fine.
To troubleshoot the issue, we tried one workaround. We went to replication snapshot folder, which could be something like “X:\Program Files\Microsoft SQL Server\<instance>\MSSQL\ReplData”.
In this folder we searched the file created for that stored procedure. For e.g., in the error message shown above, the stored procedure for which it failed was “dbo.storedprocedure”. We then Manually edited that file by removing any comments marked under /* ———–*/.
Additionally, we created those stored procedures manually on the subscriber database using original code.
Due to this, snapshot agent when tried to apply any snapshot file on subscriber, it didn’t find and missing end comment mark ‘*/’ and since that stored procedure was already present on subscriber, it was skipped and not reapplied.
Please note that we also tried creating stored procedures manually on subscriber and not amending files in “ReplData” folder, unfortunately that didn’t work.
It seemed that SQL before checking the presence of any object on subscriber, check the file in ReplData folder.
With this workaround, we were able to fix this strange replication issue.
Happy Learning!