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:       "commit_lsn": "00000027:00000758:0005",
        "event_serial_no": "1"
      },
      "op": "c",
      "ts_ms": 1559729471739
    }
  }
  ----
  
  If we look at the `schema` portion of this event's _value_, we can see the schema for the _envelope_, the schema for the `source` structure (which is specific to the SQL Server connector and reused across all events), and the table-specific schemas for the `before` and `after` fields.
  
  [NOTE]
  ====
  The names of the schemas for the `before` and `after` fields are of the form _logicalName_._schemaName_._tableName_.Value, and thus are entirely independent from all other schemas for all other tables.
  This means that when using the Avro Converter, the resulting Avro schemas for _each table_ in each _logical source_ have their own evolution and history.
  ====
  
  If we look at the `payload` portion of this event's _value_, we can see the information in the event, namely that it is describing that the row was created (since `op=c`), and that the `after` field value contains the values of the new inserted row's' `id`, `first_name`, `last_name`, and `email` columns.
  
  [NOTE]
  ====
  It may appear that the JSON representations of the events are much larger than the rows they describe.
  This is true, because the JSON representation must include the _schema_ and the _payload_ portions of the message.
  It is possible and even recommended to use the to dramatically decrease the size of the actual messages written to the Kafka topics.
  ====
  
  [[sqlserver-update-events]]
  ===== Update events
  The value of an _update_ change event on this table will actually have the exact same _schema_, and its payload is structured the same but will hold different values.
  Here's an example:
  
  [source,json,indent=0,subs="attributes"]
  ----
  {
    "schema": { ... },
    "payload": {
      "before": {
        "id": 1005,
        "first_name": "john",
        "last_name": "doe",
        "email": "john.doe@example.org"
      },
      "after": {
        "id": 1005,
        "first_name": "john",
        "last_name": "doe",
        "email": "noreply@example.org"
      },
      "source": {
        "version": "{debezium-version}",
        "connector": "sqlserver",
        "name": "server1",
        "ts_ms": 1559729995937,
        "snapshot": false,
        "db": "testDB",
        "schema": "dbo",
  
negative.code: }
  ----
  
  === Change data events
  
  The {prodname} SQL Server connector generates a data change event for each row-level `INSERT`, `UPDATE`, and `DELETE` operation. Each event contains a key and a value. The structure of the key and the value depends on the table that was changed. 
  
  {prodname} and Kafka Connect are designed around _continuous streams of event messages_. However, the structure of these events may change over time, which can be difficult for consumers to handle. To address this, each event contains the schema for its content or, if you are using a schema registry, a schema ID that a consumer can use to obtain the schema from the registry. This makes each event self-contained. 
  
  The following skeleton JSON shows the basic four parts of a change event. However, how you configure the Kafka Connect converter that you choose to use in your application determines the representation of these four parts in change events. A `schema` field is in a change event only when you configure the converter to produce it. Likewise, the event key and event payload are in a change event only if you configure a converter to produce it. If you use the JSON converver and you configure it to produce all four basic change event parts, change events have this structure: 
  
  [source,json,index=0]
  ----
  {
   "schema": { //<1>
     ...
    },
   "payload": { //<2>
     ...
   },
   "schema": { //<3> 
     ...
   },
   "payload": { //<4>
     ...
   },
  }
  ----
  
  .Overview of change event basic content
  [cols="1,2,7",options="header"]
  |===
  |Item |Field name |Description
  
  |1
  |`schema`
  |The first `schema` field is part of the event key. It specifies a Kafka Connect schema that describes what is in the event key's `payload` portion. In other words, the first `schema` field describes the structure of the primary key, or the unique key if the table does not have a primary key, for the table that was changed. +
   +
  It is possible to override the table's primary key by setting the {link-prefix}:{link-sqlserver-connector}#sqlserver-property-message-key-columns[`message.key.columns` connector configuration property]. In this case, the first schema field describes the structure of the key identified by that property.
  
  |2
  |`payload`
  |The first `payload` field is part of the event key. It has the structure described by the previous `schema` field and it contains the key for the row that was changed. 
  
  |3
  |`schema`
  |The second `schema` field is part of the event value. It specifies the Kafka Connect schema that describes what is in the event value's `payload` portion. In other words, the second `schema` describes the structure of the row that was changed. Typically, this schema contains nested schemas. 
  
  |4
  |`payload`
  |The second `payload` field is part of the event value. It has the structure described by the previous `schema` field and it contains the actual data for the row that was changed.
  
  |===
  
  By default, the connector streams change event records to topics with names that are the same as the event's originating table. See {link-prefix}:{link-sqlserver-connector}#sqlserver-topic-names[topic names].
  
  [WARNING]
  ====
  The SQL Server connector ensures that all Kafka Connect schema names adhere to the link:http://avro.apache.org/docs/current/spec.html#names[Avro schema name format]. This means that the logical server name must start with a Latin letter or an underscore, that is, a-z, A-Z, or \_. Each remaining character in the logical server name and each character in the database and table names must be a Latin letter, a digit, or an underscore, that is, a-z, A-Z, 0-9, or \_. If there is an invalid character it is replaced with an underscore character.
  
  This can lead to unexpected conflicts if the logical server name, a database name, or a table name contains invalid characters, and the only characters that distinguish names from one another are invalid and thus replaced with underscores.
  ====
  
  [[sqlserver-change-event-keys]]
  ==== Change Event Keys
  
  A change event's key contains the schema for the changed table's key and the changed row's actual key. Both the schema and its corresponding payload contain a field for each column in the changed table's primary key (or unique key constraint) at the time the connector created the event.
  
  Consider the following `customers` table, which is followed by an example of a change event key for this table. 
  
  .Example table
  [source,sql,indent=0]
  ----
  CREATE TABLE customers (
  