A Merge Agent rollback message is usually the final result of an earlier failure, not the root cause. Capture a verbose agent log and find the first constraint, trigger, conflict, permission, or schema error that occurred before the rollback.
Last updated: October 30, 2026.
replmerg.exe -Publisher SQLPUB -PublisherDB Sales -Publication SalesMerge -Subscriber SQLSUB -SubscriberDB SalesReplica -Output C:\Temp\replmerg.log -OutputVerboseLevel 2 -HistoryVerboseLevel 2Run the agent under the same account and connection settings used by the failing job. Store the output in a protected directory because replication logs can contain server, database, article, and row details.
Start with the first specific error
Microsoft documents the Merge Agent logging parameters for increasing output detail. Search the log from the beginning of the failed batch. The useful line is often a foreign-key or check-constraint violation, a duplicate key, an identity-range failure, a trigger error, or a schema mismatch.
Do not focus first on the later inactive-agent alert. That alert only reports that the agent stopped making progress after the database operation failed.
Check conflicts and database-side logic
Microsoft’s merge-conflict documentation explains that constraint violations can prevent a change from being propagated and can cause the replication trigger to roll back the transaction. Review Replication Monitor and the publication conflict tables for the affected article and row.
Compare constraints, triggers, defaults, and article schemas at Publisher and Subscriber. Test custom triggers with representative replication changes and avoid manually deleting replication metadata. After correcting the first database error, rerun the agent and confirm normal synchronization. Continue with deploying replicated schema changes, verifying SQL Server backups, and reading SQL Server failure diagnostics.
