Queued updating subscriptions

I undid again, which reverted them all back to 'for replication', then generated but did not run a publication script (with SQL Server Management Studio's GUI), and executed each command one at a time, checking the state of the "not for replication" setting along the way.

When published data is changed at either the Publisher or the Subscriber, the row receives a new globally unique identifier (GUID) to indicate that a new row version exists.

This is because set updates made at the Subscriber are propagated by replication as individual UPDATE statements for each row affected.

When data is updated at a Subscriber, it is first propagated to the Publisher and then propagated to other Subscribers.

Conflicts are detected and resolved according to a conflict resolution policy that is set when creating the publication.

When the conflict resolution policy is set to Subscriber Wins, updates to primary keys should be made with caution.

I configured Queued updatable subscriptions in transactional replication.