Queued updating allows snapshot replication and transactional replication Subscribers to modify published data without requiring an active network connection to the Publisher.
When you create a publication with the queued updating option enabled and a Subscriber performs INSERT, UPDATE, or DELETE statements on published data, the changes are stored in a queue. The queued transactions are applied asynchronously at the Publisher when network connectivity is restored.
Because the updates are propagated asynchronously to the Publisher, the same data may have been updated by the Publisher or by another Subscriber and conflicts can occur when applying the updates.
Conflicts are detected and resolved according to a conflict resolution policy that is set when creating the publication. The transaction is then propagated to other Subscribers using typical replication mechanisms (loopback detection avoids sending the update to the Subscriber that originated the transaction).
Queued updating is most appropriate for applications where users mostly read data and only occasionally update data. Subscribers should be connected most of the time, but if they are offline, updates can continue without interruption.
Both queued updating and merge replication allow updates while offline; however, there are significant differences between the two features. For more information, see Merge Replication or Updatable Subscriptions.