You can tell that the Replication Server outbound queue for a replicate database is not being updated if you issue the Replication Server admin who,sqm command at the replicate Replication Server and the results indicate that:
The number of blocks being written in the Replication Server outbound queue for the connection in question is not changing.
The number of duplicate messages being detected is not increasing.
Problems between inbound and outbound queues are often naming problems.
Determining the reason the outbound queue is not
being updated
Verify that any Replication Server routes are active.
Refer to the Replication Server Troubleshooting Guide for route validation techniques between primary and replicate Replication Servers.
Verify that the Replication Server connection DSI thread is not down.
Issue an admin who command in the replicate Replication Server to review the status of the DSI thread for the Replication Server connection.
If the DSI thread status is down, the Replication Server is not connected to the replicate database (or ECDA gateway). Review the Replication Server log for errors and attempt to resume the connection.
Verify that the DSI thread connection is not in “Loss Detected” mode by viewing the replicate Replication Server log for “Loss Detected” messages for the DSI thread in question.
When Replication Server detects a loss, no further messages are accepted on the DSI thread connection.
Refer to the Replication Server Administration Guide for information about recovering from this error.
Verify the primary replication definition.
The primary Replication Server inbound queue can receive data, but when it cannot apply that data to any replication definition, the reason is that the name of the replication definition does not match the name presented in the Log Transfer Language (LTL) that was created by the Replication Agent. This becomes more likely when you are using different non-Sybase database types with different default character cases.
Replication Server processing of replication commands is case sensitive. In a replication system with non-ASE data servers, ensure that the LTL generated by Replication Agents matches the Replication Server connection names and replication definition object names.
Some Replication Agents always use lowercase names when they communicate with Replication Server (for example, Adaptive Server and DB2 UDB). However, the best option is to pick one character case (uppercase or lowercase) and use it consistently with all Replication Server connections, replication definitions, and subscription names.
Validating case-sensitivity is manual. You can use the rs_helprep command to verify the name of a replication definition. Then, you can then turn on LTL tracing in the Replication Agent and verify that the name provided in the LTL trace matches the spelling and character case of the name specified in the replication definition.
If the character case appears to be incorrect, review the Replication Agent documentation to verify the default character case settings and any possible configuration changes. If a name is misspelled, delete and then re-create the replication definition.
