anchor.diff:  
   |5
   |`ts_ms`
  -a|Optional field that displays the time at which the connector processed the event. The time is based on the system clock in the JVM running the Kafka Connect task.  +
  +a| Optional field that displays the time at which the connector processed the event. 
  +In the event message envelope, the time is based on the system clock in the JVM running the Kafka Connect task. +
    +
  -In the `source` object, `ts_ms` indicates the time that the change was made in the database. By comparing the value for `payload.source.ts_ms` with the value for `payload.ts_ms`, you can determine the lag between the source database update and {prodname}.
  -
  +In the `source` object, `ts_ms` indicates the time when the change was committed to the database. 
  +By comparing the value for `payload.source.ts_ms` with the value for `payload.ts_ms`, you can determine the lag between the source database update and {prodname}.
   
   |===
   
  
positive.code: |
  | Timezone of the server.
  
  This is used to define the timezone of the transaction timestamp (ts_ms) retrieved from the server (which is actually not zoned). Default value is unset. Should only be specified when running on SQL Server 2014 or older and using different timezones for the database server and the JVM running the {prodname} connector. +
  When unset, default behavior is to use the timezone of the VM running the {prodname} connector. In this case, when running on on SQL Server 2014 or older and using different timezones on server and the connector, incorrect ts_ms values may be produced. +
  Possible values include "Z", "UTC", offset values like "+02:00", short zone ids like "CET", and long zone ids like "Europe/Paris".
  
  
negative.code: |[[sqlserver-property-snapshot-isolation-mode]]<<sqlserver-property-snapshot-isolation-mode, `snapshot.isolation{zwsp}.mode`>>
  |_repeatable_read_
  |Mode to control which transaction isolation level is used and how long the connector locks tables that are designated for capture.
  The following values are supported:
  
  * `read_uncommitted`
  * `read_committed`
  * `repeatable_read`
  * `snapshot`
  * `exclusive` (`exclusive` mode uses repeatable read isolation level, however, it takes the exclusive lock on all tables
  to be read). +
  
  The `snapshot`, `read_committed` and `read_uncommitted` modes do not prevent other
  transactions from updating table rows during initial snapshot. 
  The `exclusive` and `repeatable_read` modes do prevent concurrent updates. +
  
  Mode choice also affects data consistency. Only `exclusive` and `snapshot` modes guarantee full consistency, that is, initial
  snapshot and streaming logs constitute a linear history.
  In case of `repeatable_read` and `read_committed` modes, it might happen that, for instance, a record added appears
  twice - once in initial snapshot and once in streaming phase. Nonetheless, that consistency level should do for
  