Unlike transactions, an error that occurs while executing a refresh request on the master database does not cause the entire message to stop. Instead, the error is reported back to the replica database in the result set of the messaging statement. The error code is returned in the ERRCODE column of the result set. Similarly, the error text can be found from the ERRSTR column of the result set.

The result set of the messaging statements should always be fetched and the ERRCODE checked. All non-zero values mean that an error has occurred during the message execution in the master database.

One possible source of error is that the version of the publication has changed in the master database. If the publication was dropped and then re-created, a subscription to the original version of the publication must be dropped in the replica database prior to subscribing to the new version. You can drop a subscription by using the DROP SUBSCRIPTION statement, see DROP SUBSCRIPTION.

When a subscription is dropped, all data for that subscription is deleted from the replica database. Subscribing to a new version of the subscription, and then requesting a refresh results in the full publication being sent to the replica.

In many cases, you can avoid this problem by using the OR REPLACE option of the CREATE PUBLICATION statement when you need to update a publication. If you update a publication by using the CREATE [OR REPLACE] PUBLICATION statement, rather than by dropping and re-creating the publication, then you might not need to drop and re-create the subscriptions. If you do not need to re-create the subscriptions then, in some cases, the master database can send the replica databases an incremental refresh rather than a full refresh, and reduce network traffic.