A PRELOGIN message: its options, in order.

One option of a PRELOGIN message.

How much of the connection is encrypted (connectEncryption). The first four are the values of the ENCRYPTION option of PRELOGIN, where the client and the server negotiate. EncryptStrict is TDS 8.0, which never negotiates.

A LOGIN7 message, which putLogin7 writes; start from defaultLogin7.

A LOGIN7 feature extension. MS-TDS 2.2.6.4 FeatureExt

Tell the server we can handle UTF-8 collations.

Federated authentication with an access token the caller obtained (MS-TDS calls the library "Security Token", 0x01): the token, UTF-16 encoded, goes in LOGIN7 and the server validates it; there is no further exchange, unlike the MSAL library's, where the server first names the token issuer (FEDAUTHINFO).

The first argument echoes the server's PRELOGIN answer to the FEDAUTHREQUIRED option (the client must send that option to use this feature), and the last is the nonce from that answer, if the server sent one, which it only does when the client sent one.

TDS 7.4, 4096-byte packets, empty names, and the UTF-8 feature.

Fails (with error) if there is a login7Problem.

Why putLogin7 can't encode this login, if it can't: its strings (host, user, password, application, server, library, language and database names) are located by 16-bit offsets from the start of the message, so together they must end by byte 65535. (Written modulo 65536 instead, a long application name would shift where the server reads the following fields from.) The server's own limit of 128 characters per field is left to the server. The message gives the length of each field but the password's.

Swap the nibbles of each byte, then XOR with 0xA5.

ALL_HEADERS with a single Transaction Descriptor header. MS-TDS 2.2.5.3 Packet Data Stream Headers

The server's packet-count limit for a SQL batch. Most text fits using its UTF-8 byte count as a bound, avoiding a separate whole-text scan.

One RPC: the procedure, the option flags and the parameters.

The procedure an RPC calls: by its identifier (procSpExecuteSql is sp_executesql) or by name.

A parameter of an RPC.

Status flag: the parameter is an output parameter.

Status flag: use the procedure's default value.

One or more RPCs in a single request, separated by the 0xFF batch flag.

Fails (with error) if rpcRequestProblem finds a problem; callers check first. (Writing a name or value length modulo the size of its length prefix would make the server read the rest as further fields: a 300-character parameter name would go out as a 44-character name followed by what the server takes for the parameter's type and value.)

The bytes of putRpcRequest: fails (with error, when forced) if rpcRequestProblem finds a problem.

Build a checked request's bytes with the same Builder used for sending.

The writer of these requests. In-memory requests can be sent any number of times. Requests with lazy or effectful values can be sent once: the writer takes them out of a reference as it starts, so the request no longer keeps a lazy value's head alive while it is sent, and a value is read once no matter how many threads try. A query builds a new writer per send.

Write requests whose types, names and values have been validated at construction, in order, with one separator between requests.

Why putRpcRequest can't encode this RPC, if it can't: a procedure name of 65535 or more UTF-16 code units (NameLenProcID is a USHORT, and 0xFFFF announces a procedure ID instead), or an rpcParamProblem.

Why a parameter can't be sent, if it can't: a name of more than 255 UTF-16 code units (a B_VARCHAR; SQL Server's own limit is 128 characters, which it reports itself), a typeInfoProblem, or a valueProblem.

The body of a Transaction Manager request that begins a transaction (MS-TDS 2.2.6.9, TM_BEGIN_XACT): ALL_HEADERS, the request type (5), the isolation level (0 keeps the session's; 1 READ UNCOMMITTED, 2 READ COMMITTED, 3 REPEATABLE READ, 4 SERIALIZABLE, 5 SNAPSHOT, which the session then keeps after the transaction), and an empty transaction name.