anchor.diff:  }
   ----
   
  -=== Events
  -
  -All data change events produced by the SQL Server connector have a key and a value, although the structure of the key and value depend on the table from which the change events originated (see {link-prefix}:{link-sqlserver-connector}#sqlserver-topic-names[Topic names]).
  +=== 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_ are http://avro.apache.org/docs/current/spec.html#names[valid Avro schema names].
  -This means that the logical server name must start with Latin letters or an underscore (e.g., [a-z,A-Z,\_]),
  -and the remaining characters in the logical server name and all characters in the schema and table names must be Latin letters, digits, or an underscore (e.g., [a-z,A-Z,0-9,\_]).
  -If not, then all invalid characters will automatically be replaced with an underscore character.
  -
  -This can lead to unexpected conflicts when the logical server name, schema names, and table names contain other characters, and the only distinguishing characters between table full names are invalid and thus replaced with underscores.
  -====
  -
  -{prodname} and Kafka Connect are designed around _continuous streams of event messages_, and the structure of these events may change over time.
  -This could be difficult for consumers to deal with, so to make it easy Kafka Connect makes each event self-contained.
  -Every message key and value has two parts: a _schema_ and _payload_.
  -The schema describes the structure of the payload, while the payload contains the actual data.
  +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
   
  -For a given table, the change event's key will have a structure that contains a field for each column in the primary key (or unique key constraint) of the table at the time the event was created.
  -
  -Consider a `customers` table defined in the `inventory` database's schema `dbo`:
  -
  +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 (
  
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:           }
          ],
          "optional": true,
          "name": "server1.dbo.customers.Value", <2>
          "field": "before"
        },
        {
  