A conversion of one whole value, given exactly its bytes; where they lay in the packets is the parser's concern. They may be a slice of a receive buffer, so a reader must copy any it keeps.

The bytes of a short Put of (at most, or it is slower) n bytes, in a buffer of that size: how a parameter's value is encoded by the put* functions below. binary's own runPut starts with a 4 KiB buffer, a large object of its own, and toStrict then copies the few bytes out of it: about 100 ns and 4 KiB per value.

Resolution of 1/10000, matching money and smallmoney.

A money or smallmoney value: a fixed-point number with four decimal places, exactly as the server stores it.

Fails (with error) outside the smallmoney range (money4Problem).

Fails (with error) outside the money range (money8Problem) rather than sending the value modulo 2^64.

smallmoney (4 bytes) or money (8 bytes), by the value's length. A money value is two little-endian DWORDs, the high half first.

A money or smallmoney value as its count of 1/10000ths.

Likewise for smallmoney (-214,748.3648 through 214,748.3647).

Why a Money value doesn't fit in money (a signed 64-bit count of 1/10000ths: -922,337,203,685,477.5808 through 922,337,203,685,477.5807), if it doesn't. Money itself is unbounded.

Rounds to the nearest minute (1900-01-01 through 2079-06-06).

Rounds to the nearest 1/300 s (1753-01-01 through 9999-12-31).

smalldatetime, passing the day and the picoseconds since midnight to the function (localTimeOf, utcTimeOf).

datetime, passing the day and the picoseconds since midnight (rounded down) to the function.

A datetimeoffset value: an instant plus the UTC offset it was recorded with.

The same instant as a ZonedTime in the value's offset.

An offset beyond the range of Int16 is clamped to it rather than wrapped (so it stays outside the ±14:00 a datetimeoffset allows, and putDateTimeOffset rejects it).

Why a time, datetime2 or datetimeoffset (named) can't have this scale, if it can't: MS-TDS 2.2.5.4.2 allows 0 through 7. Every exported function here that takes a scale checks it with this.

Number of bytes used for the time portion at a given scale (5 for any scale above 4, including invalid ones: see scaleProblem).

0001-01-01 through 9999-12-31.

Rounds to the nearest unit, but never past 23:59:59.(9...) at the scale.

Rounds to the nearest unit, carrying into the next day.

Rounds like putDateTime2. The offset must be within ±14:00, and both the UTC and the local time must be in range.

date: 3-byte count of days since 0001-01-01.

time(scale): a count of units of 10^-scale seconds since midnight.

datetime2(scale): the time units, then the date.

datetimeoffset(scale): the time units and the date, both in UTC, then the offset as a signed count of minutes.

date, passing the day to the function.

time(scale), passing the picoseconds since midnight to the function.

datetime2(scale), passing the day and the picoseconds since midnight to the function.

datetimeoffset(scale), passing the UTC day, the picoseconds since UTC midnight and the offset in minutes to the function. The value is checked as readDateTimeOffset checks it: the offset within ±14:00, and the local date within 0001-01-01 through 9999-12-31.

A LocalTime, evaluated, from a day and picoseconds since midnight.

A UTCTime, evaluated, from a day and picoseconds since midnight.

A time of day from picoseconds since midnight (less than a day).

Length of the magnitude (excluding the sign byte) for a given precision.

A decimal at the precision and scale, rounded to the scale: the sign byte and precisionToLength bytes of magnitude.

decimal and numeric: a sign byte (0 negative, 1 positive) followed by a little-endian unsigned magnitude of 4, 8, 12 or 16 bytes (MS-TDS 2.2.5.5.1.3). The magnitude is usually precisionToLength bytes, but SQL Server doesn't always send that: a decimal(10,0) zero read from a table has 4, and a decimal(1,0) in a sql_variant has 16. So any of the four lengths is accepted, as SqlClient accepts them, and the value is checked against the precision instead. Another length, another sign byte, or a magnitude with more digits than the precision allows is a Left.

decimal and numeric, checked as readDecimal checks them, passing the value's parts to the function: whether it is negative, the high and low 64 bits of its magnitude, and the scale. A zero is never negative, though the wire can carry one.

The layout of readGuid, written.

uniqueidentifier. The first three groups are little-endian on the wire, unlike RFC 4122.

MS-TDS 2.2.5.1.2 Collation Rule Definition. Kept opaque: the LCID, flags and version share a DWORD, followed by the sort ID byte.

The five bytes of a collation at an offset.

The five bytes of a collation.

Decode UTF-16LE text from the server, never failing.

SQL Server stores and sends UCS-2 code units without validating them, so a value can hold unpaired surrogates (NCHAR(0xD800), a reversed pair, a high surrogate cut off at the end of a string). Following the Unicode Standard's recommended practice ("U+FFFD Substitution of Maximal Subparts", ch. 3), each ill-formed code unit becomes exactly one U+FFFD and every well-formed scalar value decodes unchanged. A trailing odd byte (a truncated code unit) also becomes one U+FFFD.

text's own decodeUtf16LE throws on such input, and its decodeUtf16LEWith resynchronizes byte by byte, emitting one U+FFFD per byte and then misreading the following units.

One pass writing UTF-8 into the Text array, eight ASCII units at a time (Hmssql.Tds.Utf16).

Write text as UTF-16LE without a length prefix.

B_VARCHAR: one-byte character count followed by UCS-2 text. Fails (with error) for text of more than 255 UTF-16 code units, which the length byte can't count; check with ucs2Length first.

US_VARCHAR: two-byte character count followed by UCS-2 text. Fails (with error) for text of more than 65535 UTF-16 code units.

The length of text in UTF-16 code units, which is what B_VARCHAR and US_VARCHAR count (a character outside the BMP is two).