Revision Summary Date Revision History Revision Comments 8/7/2009 0.1 Major First release. 11/6/2009 0.2 Minor Clarified the meaning of the technical content. 3/5/2010 0.2.1 Editorial Changed language and formatting in the technical content. 4/21/2010 0.2.2 Editorial Changed language and formatting in the technical content. 6/4/2010 0.2.3 Editorial Changed language and formatting in the technical content. 9/3/2010 0.2.3 None No changes to the meaning, language, or formatting of the technical content. 2/9/2011 0.3.0 Minor Clarified the meaning of the technical content. 7/7/2011 1.0 Major Updated and revised the technical content. 11/3/2011 1.0 None No changes to the meaning, language,
or formatting of the technical content. 1/19/2012 1.0 None No changes to the meaning, language, or formatting of the technical content. 2/23/2012 1.0 None No changes to the meaning, language, or formatting of the technical content. 3/27/2012 1.0 None No changes to the meaning, language, or formatting of the technical content. 5/24/2012 1.0 None No changes to the meaning, language, or formatting of the technical content. 6/29/2012 1.0 None No changes to the meaning, language, or formatting of the technical content. 7/16/2012 1.0 None No changes to the meaning, language, or formatting
technical content. 2/11/2014 2.0 Updated and revised the technical content. 5/20/2014 2.0 None No changes to the meaning, language, or formatting of the technical content. 5/10/2016 2.0 None No changes to the meaning, language, or formatting of the technical content. 8/16/2017 3.0 Significantly changed the technical content.
Messages The formal syntax of all messages is specified in Augmented Backus-Naur Form (ABNF); for more details, see . Transport The TDS 4.2 protocol does not prescribe a specific underlying transport protocol to use on the Internet or on other networks. This protocol only presumes a reliable transport that guarantees in-sequence delivery of data. The chosen transport can be either stream-oriented or message-oriented. If a message-oriented transport is used, then any TDS 4.2 packet sent from a TDS 4.2 client to a TDS 4.2 server MUST be contained within a single transport data unit. Any additional mapping of TDS 4.2 data onto the transport data of the protocol in question is outside the scope of this specification. The TDS 4.2 protocol has implementations over the following transports: TCP. For more details, see . Named Pipes in message mode. For more details, see .<1> Optionally, the TDS 4.2 protocol has implemented TLS (for more details, see ) and SSL on top of the preceding transports, in case TLS/SSL encryption is negotiated. Message Syntax Character data, such as , within a TDS 4.2 message is in multi-byte character set (MBCS) format (for more information, see ). Character counts within TDS 4.2 messages are specified as byte counts. Client Messages Messages sent from the client to the server are as follows: A A A (in any language that the server will accept) A followed by its associated binary data (for example, the data for a bulk load SQL statement) A () An A These are briefly described in the subsections under this section; detailed descriptions of message contents are included in section . Pre-Login Before a login occurs, a handshake-denominated pre-login message exchange occurs between client and server, setting up contexts such as encryption. See section for additional details.
datetime is represented in the following sequence: One 4-byte signed integer that represents the number of days since January 1, 1900. Negative numbers are allowed to represent dates since January 1, 1753. One 4-byte unsigned integer that represents the number of one three-hundredths of a second (300 counts per second) elapsed since 12 A.M. that day. Type Info Rule Definition The TYPE_INFO rule applies to several messages used to describe column information. For columns of data length, the type is all that is required to determine the data length. For columns of a variable-length type, TYPE_VARLEN defines the length of the data contained within the column. PRECISION and SCALE have to occur if the type is NUMERIC, NUMERICN, DECIMAL, or DECIMALN. TYPE_INFO = FIXEDLENTYPE / (VARLENTYPE, TYPE_VARLEN [PRECISION SCALE]) Data Buffer Stream Tokens The tokens defined as follows are used as part of the token-based . For more details about the way each token is used inside the data stream, see section . ALTFMT_TOKEN = %xA8 ALTNAME_TOKEN = %xA7 ALTROW_TOKEN = %xD3 COLFMT_TOKEN = %xA1 COLINFO_TOKEN = %xA5 COLNAME_TOKEN = %xA0 DONE_TOKEN = %xFD DONEPROC_TOKEN = %xFE DONEINPROC_TOKEN = %xFF ENVCHANGE_TOKEN = %xE3 ERROR_TOKEN = %xAA INFO_TOKEN = %xAB LOGINACK_TOKEN = %xAD OFFSET_TOKEN = %x78 ORDER_TOKEN = %xA9 RETURNSTATUS_TOKEN = %x79 RETURNVALUE_TOKEN = %xAC ROW_TOKEN = %xD1 SSPI_TOKEN = %xED TABNAME_TOKEN = %xA4 Packet Header Message Type Stream Definition Bulk Load BCP Stream Name BulkLoadBCP Stream Function
Change Tracking This section identifies changes that were made to this document since the last release. Changes are classified as Major, Minor, or None. The revision class Major means that the technical content in the document was significantly revised. Major changes affect protocol interoperability or implementation. Examples of major changes are: A document revision that incorporates changes to interoperability requirements. A document revision that captures changes to protocol functionality. The revision class Minor means that the meaning of the technical content was clarified. Minor changes do not affect protocol interoperability or implementation. Examples of minor changes are updates to clarify ambiguity at the sentence, paragraph, or table level. The revision class None means that no new technical changes were introduced. Minor editorial and formatting changes may have been made, but the relevant technical content is identical to the last released version. The changes made to this document are listed in the following table. For more information, please contact . Section Description Revision class Appendix A: Product Behavior SQL Server 2016 and SQL Server 2017 to the list of applicable products. Major
Index A Abstract data model 72 72 67 78 78 12 14 94 Attention signal 22 21 B 31 33 C 12 100 Client 72 73 73 74 77 overview ( 67, 72) 74 77 73 Client details 72 13 13 80 67 D 30 Data model - abstract 72 78 Data streams 26 25 25 26 Data types 26 27 26 66 21 21 E 66 16 Example 94 83 86 82 91 92 89 90 95 94 96 Examples 82 22 F 12 Final state ( 77, 81) 26 20 G 7 Grammar definition 23 23 23 H Higher-layer triggered events 73 73 67 79 79 I 97 97 16 9 79 Initialization 73 73 79 79 7 L 80 76