anchor.diff:  
   [WARNING]
   ====
  -If the table does not have a primary or unique key, then the change event's key will be null. This makes sense since the rows in a table without a primary or unique key constraint cannot be uniquely identified.
  +If the table does not have a primary or unique key, then the change event's key is null. This makes sense since the rows in a table without a primary or unique key constraint cannot be uniquely identified.
   ====
   endif::community[]
   
   [[sqlserver-change-event-values]]
  -==== Change Event Values
  -
  -Like the message key, the value of a change event message has a _schema_ section and _payload_ section.
  -The payload section of every change event value produced by the SQL Server connector has an _envelope_ structure with the following fields:
  -
  -* `op` is a mandatory field that contains a string value describing the type of operation. Values for the SQL Server connector are `c` for create (or insert), `u` for update, `d` for delete, and `r` for read (in the case of a snapshot).
  -* `before` is an optional field that if present contains the state of the row _before_ the event occurred. The structure is described by the `server1.dbo.customers.Value` Kafka Connect schema, which the `server1` connector uses for all rows in the `dbo.customers` table.
  -
  -* `after` is an optional field that if present contains the state of the row _after_ the event occurred. The structure is described by the same `server1.dbo.customers.Value` Kafka Connect schema used in `before`.
  -* `source` is a mandatory field that contains a structure describing the source metadata for the event, which in the case of SQL Server contains these fields: the {prodname} version, the connector name, whether the event is part of an ongoing snapshot or not, the commit LSN (not while snapshotting), the LSN of the change, database, schema and table where the change happened, and a timestamp representing the point in time when the record was changed in the source database (during snapshotting, this is the point in time of snapshotting).
  -+
  -Also a field `event_serial_no` is present during streaming.
  -This is used to differentiate among events that have the same commit and change LSN.
  -There are mostly two situations when you can see it present with value different from `1`:
  -+
  -** update events will have the value set to `2`, this is because the update generates two events in the CDC change table of SQL Server (https://docs.microsoft.com/en-us/sql/relational-databases/system-tables/cdc-capture-instance-ct-transact-sql?view=sql-server-2017[source documentation]).
  -The first one contains the old values and the second one contains new values.
  -So the first one is dropped and the values from it are used with the second one to create the {prodname} change event.
  -** when a primary key is updated, then SQL Server emits two records - `delete` to remove the record with the old primary key value and `insert` to create the record with the new primary key.
  -Both operations share the same commit and change LSN and their event numbers are `1` and `2`.
  -* `ts_ms` is optional and if present contains the time (using the system clock in the JVM running the Kafka Connect task) at which the connector processed the event.
  -
  -And of course, the _schema_ portion of the event message's value contains a schema that describes this envelope structure and the nested fields within it.
  +==== Change event values
  +
  +The value in a change event is a bit more complicated than the key. Like the key, the value has a `schema` section and a `payload` section. The `schema` section contains the schema that describes the `Envelope` structure of the `payload` section, including its nested fields. Change events for operations that create, update or delete data all have a value payload with an envelope structure. 
  +
  +Consider the same sample table that was used to show an example of a change event key: 
  +
  +[source,sql,indent=0]
  +----
  +CREATE TABLE customers (
  +  id INTEGER IDENTITY(1001,1) NOT NULL PRIMARY KEY,
  +  first_name VARCHAR(255) NOT NULL,
  +  last_name VARCHAR(255) NOT NULL,
  +  email VARCHAR(255) NOT NULL UNIQUE
  +);
  +----
  +
  +The value portion of a change event for a change to this table is described for each event type. 
  +
  +ifdef::product[]
  +* <<sqlserver-create-events,_create_ events>>
  +* <<sqlserver-update-events,_update_ events>>
  +* <<sqlserver-delete-events,_delete_ events>>
  +endif::product[]
   
   [[sqlserver-create-events]]
  -===== Create events
  -
  -Let's look at what a _create_ event value might look like for our `customers` table:
  -
  -[source,json,indent=0,subs="attributes"]
  +===== _create_ events
  +
  +The following example shows the value portion of a change event that the connector generates for an operation that creates data in the `customers` table: 
  +
  +[source,json,indent=0,subs="+attributes"]
   ----
   {
  -  "schema": {
  +  "schema": { <1>
       "type": "struct",
       "fields": [
         {
  
positive.code:           }
          ],
          "optional": false,
          "name": "io.debezium.connector.sqlserver.Source",
          "field": "source"
        },
        {
  
negative.code:       "commit_lsn": "00000027:00000db0:0007",
        "event_serial_no": "1"
      },
      "op": "d", <4>
      "ts_ms": 1559730450205 <5>
    }
  }
  ----
  
  .Descriptions of _delete_ event value fields
  [cols="1,2,7",options="header"]
  |===
  |Item |Field name |Description
  
  |1
  |`before`
  |Optional field that specifies the state of the row before the event occurred. In a _delete_ event value, the `before` field contains the values that were in the row before it was deleted with the database commit.
  
  |2
  |`after`
  | Optional field that specifies the state of the row after the event occurred. In a _delete_ event value, the `after` field is `null`, signifying that the row no longer exists.
  
  |3
  |`source`
  a|Mandatory field that describes the source metadata for the event. In a _delete_ event value, the `source` field structure is the same as for _create_ and _update_ events for the same table. Many `source` field values are also the same. In a _delete_ event value, the `ts_ms` and `pos` field values, as well as other values, might have changed. But the `source` field in a _delete_ event value provides the same metadata: 
  
  * {prodname} version
  * Connector type and name
  * Database and schema names
  * Timestamp
  * If the event was part of a snapshot
  * Name of the table that contains the new row
  * Server log offsets
  
  |4
  |`op`
  a|Mandatory string that describes the type of operation. The `op` field value is `d`, signifying that this row was deleted.
  
  |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.
  
  |===
  
  SQL Server connector events are designed to work with link:{link-kafka-docs}/#compaction[Kafka log compaction]. Log compaction enables removal of some older messages as long as at least the most recent message for every key is kept. This lets Kafka reclaim storage space while ensuring that the topic contains a complete data set and can be used for reloading key-based state.
  
  [[sqlserver-tombstone-events]]
  .Tombstone events
  When a row is deleted, the _delete_ event value still works with log compaction, because Kafka can remove all earlier messages that have that same key. However, for Kafka to remove all messages that have that same key, the message value must be `null`. To make this possible, after {prodname}’s SQL Server connector emits a _delete_ event, the connector emits a special tombstone event that has the same key but a `null` value.
  
  [[sqlserver-transaction-metadata]]
  === Transaction Metadata
  