asked
Merge Replication Error
I was in a task of configuring Merge replication on SQL Server 2005. But unfortunately, during the synchronization(took around 8 hours) i encountered an error stating "The Merge Agent failed to enumerate retry information. This can occur when there is too much activity on the tempdb system database. Increase the -QueryTimeOut parameter and restart the synchronization." what does it mean? why it happened? How i can resolve it? Updated(2010-11-18) : Initially i tired ti configured a pull subscription and got the error. When i tried Push subscription, that issue was resolved. Now i m in to a new problem, I got the following issues 1. When i checked the "view Synchronization status" can see the message "The server 'X' is not a Subscriber. (.Net SqlClient Data Provider)". 1. When i checked the replication monitor, the synchronization is on progress, but i got the following error message Error messages: - The merge process was unable to access row metadata at the 'Subscriber'. When troubleshooting, restart the synchronization with verbose history logging and specify an output file to write to, or use SQL Profiler to determine the source of the failure. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147200996)Get help: http://help/MSSQL_REPL-2147200996 - TCP Provider: An existing connection was forcibly closed by the remote host. (Source: MSSQLServer, Error number: 10054) Get help: http://help/10054 - Communication link failure (Source: MSSQLServer, Error number: 10054) Get help: http://help/10054 - The process was successfully stopped. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147199481) Get help: http://help/MSSQL_REPL-2147199481 My publisher is running under non trusted environment and my subscriber is on trusted.
This might happen if you have records in the child tables referencing subscriber parent records which no longer exist. You can try to run the agent with -output [some_file_path] -OutputVerboseLevel desired_level The output verbose level should be 0, 1, or 2: - 0 to print only error messages - 1 to print all progress report messages - 2 (default and most useful when debugging) to print all error and report messages. It goes without saying that these switches have a very negative impact on performance, but in your case, they might be useful to identify the actual source of the problem as it is entirely possible that the problem has nothing to do with FK integrity violations and could be something else. I don't believe though that it has anything to do with the tempdb activity (despite what the error message says). Oleg
