A Merge Subscription Has Expired and Changes Must Be Uploaded
If a subscription to a merge publication expires, and you want to upload changes from the Subscriber to the Publisher, you must do so manually.
Explanation
Merge replication uses the publication retention period (the @retention and @retention_period_unit parameters of sp_addmergepublication (Transact-SQL) to determine when a subscription expires. Replication cleans up metadata in the publication and subscription databases after the retention period is reached. For more information, see Subscription Expiration and Deactivation. You cannot upload changes from an expired subscription, because the metadata relating to the rows at the Subscriber is no longer present at the Publisher.
User Action
To upload changes to the Publisher:
Use the tablediff utility to determine which rows are different between the Publisher and Subscriber. For information about using this utility on replicated tables, see How to: Compare Replicated Tables for Differences (Replication Programming).
Upload changes from the Subscriber manually or by using one of the following approaches:
Re-create the subscription, specifying that the snapshot should not be applied at the Subscriber. For more information, see Initializing a Merge Subscription Without a Snapshot. After the subscription is created, perform a dummy update for each row that should be uploaded to the Publisher: either perform a manual dummy update such as:
UPDATE Sales.SalesOrderHeader SET RevisionNumber = RevisionNumber WHERE SalesOrderID > 4100
or execute sp_mergedummyupdate for each row. For more information, see sp_mergedummyupdate (Transact-SQL).
Use the tablediff utility to generate a Transact-SQL script to bring the data into convergence. For more information, see tablediff Utility. The Transact-SQL script overwrites all non-convergent data at the destination (in this case the Publisher), so this option should only be used if uploading data from the Subscriber takes precedence over preserving data at the Publisher.