anchor.diff:  
   See the link:#connector-properties[complete list of connector properties] that can be specified in these configurations.
   
  -This configuration can be sent via POST to a running Kafka Connect service, which will then record the configuration and start up the one connector task that will connect to the MySQL database, read the binlog, and record events to Kafka topics.
  +This configuration can be sent via POST to a running Kafka Connect service, which will then record the configuration and start up the one connector task that will connect to the SQL Server database, read the transaction log, and record events to Kafka topics.
   
   
   [[connector-properties]]
  
positive.code: [[example-configuration]]
  === Example configuration
  
  Using the MySQL connector is straightforward. Here is an example of the configuration for a MySQL connector that monitors a MySQL server at port 3306 on 192.168.99.100, which we logically name `fullfillment`:
  
  [source,json]
  ----
  
negative.code: === Data types
  
  As described above, the SQL Server connector represents the changes to rows with events that are structured like the table in which the row exist.
  The event contains a field for each column value, and how that value is represented in the event depends on the SQL data type of the column. This section describes this mapping.
  
  The following table describes how the connector maps each of the SQL Server data types to a _literal type_ and _semantic type_ within the events' fields.
  Here, the _literal type_ describes how the value is literally represented using Kafka Connect schema types, namely `INT8`, `INT16`, `INT32`, `INT64`, `FLOAT32`, `FLOAT64`, `BOOLEAN`, `STRING`, `BYTES`, `ARRAY`, `MAP`, and `STRUCT`.
  