anchor.diff:        "commit_lsn": "00000027:00000758:0005",
         "event_serial_no": "1"
       },
  -    "op": "c",
  -    "ts_ms": 1559729471739
  +    "op": "c", <7>
  +    "ts_ms": 1559729471739 <8>
     }
   }
   ----
   
  -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.
  -====
  +
  +.Descriptions of _create_ event value fields
  +[cols="1,2,7",options="header"]
  +|===
  +|Item |Field name |Description
  +
  +|1
  +|`schema`
  +|The value's schema, which describes the structure of the value's payload. A change event's value schema is the same in every change event that the connector generates for a particular table. 
  +
  +|2
  +|`name`
  +a|In the `schema` section, each `name` field specifies the schema for a field in the value's payload. In this example: 
  +
  +* `server1.dbo.customers.Value` is the schema for the payload's `before` and `after` fields. This schema is specific to the `customers` table.
  +
  +* `io.debezium.connector.sqlserver.Source` is the schema for the payload's `source` field. This schema is specific to the SQL Server connector. The connector uses it for all events that it generates. 
  +
  +* `server1.dbo.customers.Envelope` is the schema for the overall structure of the payload, where `server1` is the connector name, `dbo` is the database schema name, and `customers` is the table.
  +
  +Names of schemas for `before` and `after` fields are of the form `_logicalName_._database-schemaName_._tableName_.Value`, which ensures that the schema name is unique in the database. This means that when using the {link-prefix}:{link-avro-serialization}[Avro converter], the resulting Avro schema for each table in each logical source has its own evolution and history.
  +
  +|3
  +|`payload`
  +|The value's actual data. This is the information that the change event is providing. 
  +
  +It may appear that the JSON representations of the events are much larger than the rows they describe. This is because the JSON representation must include the schema and the payload portions of the message.
  +However, by using the {link-prefix}:{link-avro-serialization}[Avro converter], you can significantly decrease the size of the messages that the connector streams to Kafka topics.
  +
  +|4
  +|`before`
  +| An optional field that specifies the state of the row before the event occurred. When the `op` field is `c` for create, as it is in this example, the `before` field is `null` since this change event is for new content. 
  +
  +|5
  +|`after`
  +| An optional field that specifies the state of the row after the event occurred. In this example, the `after` field contains the values of the new row's `id`, `first_name`, `last_name`, and `email` columns.
  +
  +|6
  +|`source`
  +a| Mandatory field that describes the source metadata for the event. This field contains information that you can use to compare this event with other events, with regard to the origin of the events, the order in which the events occurred, and whether events were part of the same transaction. The source metadata includes: 
  +
  +* {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
  +
  +|7
  +|`op`
  +a| Mandatory string that describes the type of operation that caused the connector to generate the event. In this example, `c` indicates that the operation created a row. Valid values are: 
  +
  +* `c` = create
  +* `u` = update
  +* `d` = delete
  +* `r` = read (applies to only snapshots)
  +
  +|8
  +|`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.
  +
  +|===
   
   [[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"]
  +===== _update_ events
  +
  +The value of a change event for an update in the sample `customers` table has the same schema as a _create_ event for that table. Likewise, the event value's payload has the same structure. However, the event value payload contains different values in an _update_ event. Here is an example of a change event value in an event that the connector generates for an update in the `customers` table: 
  +
  +[source,json,indent=0,subs="+attributes"]
   ----
   {
     "schema": { ... },
     "payload": {
  -    "before": {
  +    "before": { <1>
         "id": 1005,
         "first_name": "john",
         "last_name": "doe",
         "email": "john.doe@example.org"
       },
  -    "after": {
  +    "after": { <2>
         "id": 1005,
         "first_name": "john",
         "last_name": "doe",
         "email": "noreply@example.org"
       },
  -    "source": {
  +    "source": { <3>
         "version": "{debezium-version}",
         "connector": "sqlserver",
         "name": "server1",
  -      "ts_ms": 1559729995937,
  +      "ts_sec": 1559729995937,
         "snapshot": false,
         "db": "testDB",
         "schema": "dbo",
  
positive.code: );
  ----
  
  If the `database.server.name` configuration property has the value `server1`,
  every change event for the `customers` table while it has this definition will feature the same key structure, which in JSON looks like this:
  
  [source,json,indent=0]
  ----
  {
      "schema": {
          "type": "struct",
          "fields": [
              {
                  "type": "int32",
                  "optional": false,
                  "field": "id"
              }
          ],
          "optional": false,
          "name": "server1.dbo.customers.Key"
      },
      "payload": {
          "id": 1004
      }
  }
  ----
  
  The `schema` portion of the key contains a Kafka Connect schema describing what is in the key portion. In this case, it means that the `payload` value is not optional, is a structure defined by a schema named `server1.dbo.customers.Key`, and has one required field named `id` of type `int32`.
  If you look at the value of the key's `payload` field, you can see that it is indeed a structure (which in JSON is just an object) with a single `id` field, whose value is `1004`.
  
  Therefore, you can interpret this key as describing the row in the `dbo.customers` table (output from the connector named `server1`) whose `id` primary key column had a value of `1004`.
  
  ifdef::community[]
  [NOTE]
  
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 (
  