Oversized decimal in SQLGetData reports SQLSTATE 07006 instead of 22003

[David-Engel]

Describe the bug

An oversized decimal/numeric value converted through SQLGetData into a numeric C type reports SQLSTATE 07006 ("restricted data type attribute violation") instead of 22003 ("numeric value out of range").

07006 means the requested C type is not a legal target for this SQL type. But decimal → SQL_C_SLONG is a legal pairing — it is this particular value that will not fit. An application branching on SQLSTATE to distinguish "I asked for the wrong type" from "this row had a value too big for the buffer I gave you" gets the wrong answer, and the first is not retryable per-row while the second is.

The root cause is that numeric_source in mssql-odbc/src/api/fetch_convert.rs returns Option, so two distinct conditions collapse into the same None:

ColumnValues::Decimal(d) | ColumnValues::Numeric(d) => {
    let m = i128::try_from(d.magnitude()?).ok()?;   // <- both failures return None
    ...
}

and the sole caller maps every None to 07006:

numeric_source(value).ok_or(ConvError::Restricted)   // fetch_convert.rs:255

None legitimately means 07006 for a binary or GUID column, which has no numeric interpretation at all. For a decimal column it means the value overflowed. Swapping the error at the Decimal arm alone is not enough — numeric_source needs to distinguish the two, e.g. by returning Result<NumericSource, ConvError> or by having the decimal arm signal out-of-range separately.

The same function already returns 22003 for the analogous character-source case (fetch_convert.rs:250), so fixing this also makes the function self-consistent.

This is reachable from the wire, not only through FFI. Two failure modes reach the ?:

1. d.magnitude() returns None for more than four significant words. After Guard decimal magnitude reassembly against 128-bit shift overflow #237 the wire decoder caps the count at 4, so this one is FFI-only.
2. i128::try_from fails for a four-word magnitude above i128::MAX. The wire decoder validates the word count, not that the magnitude fits the column's declared precision, so a 17-byte payload — a legal length — carrying a magnitude in (i128::MAX, u128::MAX] is accepted by the decoder and fails here. A valid decimal(38, s) never exceeds 10^38 - 1 ≈ 2^126.2, so this is a malformed or hostile payload, but it is one a server can send.

Case 2 also means the string and typed paths disagree about the same value: SQL_C_CHAR renders it, SQL_C_SLONG reports the conversion as illegal.

Steps to reproduce

Verified against mssql-odbc at 39532382 with a temporary unit test (since case 2 needs a malformed payload a real server will not normally send):

use mssql_tds::datatypes::decoder::DecimalParts;

// A 17-byte wire payload of all 0xFF: 4 words, legal length, magnitude u128::MAX.
let d = DecimalParts {
    is_positive: true,
    scale: 0,
    precision: 38,
    int_parts: vec![-1, -1, -1, -1],
};

let mut out: i64 = 0;
let mut ind: SqlLen = 0;
let err = unsafe {
    convert_integer_c(
        &ColumnValues::Decimal(d),
        SQL_C_SBIGINT,
        (&mut out as *mut i64).cast(),
        &mut ind,
    )
};

Observed output:

magnitude       = Some(340282366920938463463374607431768211455)
i128::try_from  = false
Display         = 340282366920938463463374607431768211455
convert result  = Err(Restricted)      // -> SQLSTATE 07006

Equivalently over a live connection: have a server send a decimal(38, 0) column whose 16-byte magnitude exceeds i128::MAX, then SQLGetData that column into SQL_C_SBIGINT.

Expected behavior

SQLGetData returns SQL_ERROR with SQLSTATE 22003, "Numeric value out of range" — the conversion is legal, the value does not fit.

07006 should remain reserved for source/target pairings that are genuinely illegal, such as a binary or GUID column into a numeric C type.

Actual behavior

SQLGetData returns SQL_ERROR with SQLSTATE 07006, "Restricted data type attribute violation", implying decimal cannot be fetched as an integer at all.

Internally: ConvError::Restricted rather than ConvError::OutOfRange.

Version

mssql-odbc 0.1.0, commit 39532382 (branch for #237)

Affected crate

mssql-odbc

Note: mssql-odbc is not in the "Affected crate" dropdown in .github/ISSUE_TEMPLATE/bug_report.yml, which still lists only mssql-tds, mssql-js, mssql-tds-cli, mssql-mock-tds, and mssql-py-core. Worth adding separately.

Additional context

Came out of review discussion on #237 (comment). The 07006 behavior arrived with #217; #237 made numeric_source the single shared entry point for both the string and typed paths, so the fix is now in one place rather than two.

Notes for whoever picks this up:

• Not a drive-by change. A returned SQLSTATE is observable behavior an application can branch on, which is why it was deliberately kept out of Guard decimal magnitude reassembly against 128-bit shift overflow #237. It deserves its own PR.
• One unit test pins the current behavior: decimal_limbs_are_reassembled_and_bounded in fetch_convert.rs asserts ConvError::Restricted for vec![1, 0, 0, 0, 1]. It will need updating, and it is the right place to add a case for the wire-reachable i128::MAX boundary above, which nothing currently covers.
• I grepped for 07006 across mssql-odbc: no ODBC e2e test pins it for the decimal path, so the blast radius is that one unit test. bind_param.rs's unsupported_conversion_returns_07006 is a different code path and unaffected.
• Worth checking msodbcsql parity while in here — the pipeline already runs a parity comparison against the reference driver, so it can confirm which SQLSTATE msodbcsql returns for the same input rather than reasoning from the spec alone.
• Consider whether the decoder should also range-check a decimal magnitude against its declared precision, which would close case 2 at the wire instead of at the conversion. That is arguably a separate mssql-tds issue, and is related in spirit to mssql-tds: SQL_VARIANT narrows a u32 data length to u8, desynchronizing the token stream #280.

[David-Engel]

Already fixed — closing as a duplicate of #235.

To untangle the history, since this one came out of the #237 review and the framing shifted along the way:

• Guard decimal magnitude reassembly against 128-bit shift overflow #237 (merged 2026-08-13) fixed the decimal decode overflow — limb-count cap and safe u128/BigUint magnitude reassembly. The SQLSTATE change was deliberately kept out of it, which is why this issue exists.
• Report 22003 for an unrepresentable numeric column value #284 "Report 22003 for an unrepresentable numeric column value" (merged 2026-08-14) is the actual fix. It made exactly the change this issue said was required: numeric_source now returns Result<NumericSource, ConvError> rather than Option, so "this column has no numeric interpretation" (07006) and "this value cannot be represented" (22003) no longer collapse into the same None, and numeric_source_or_parse propagates instead of re-wrapping so the character-column arms (22018 / 22003) are unchanged.
• Report 22003 for an unrepresentable numeric column value #284 linked mssql-odbc: an out-of-range numeric value reports 07006 instead of 22003 #235, an earlier duplicate filed against the same line, so that one auto-closed and this one was left open. Nothing was missed in the fix; only the link.

Both failure modes described here are covered as of ec3b7958:

• Magnitude wider than 4 words (the FFI-only case): d.magnitude().ok_or(ConvError::OutOfRange)? → 22003.
• Four words above i128::MAX (the wire-reachable case this issue added): no longer an error at all. It has no exact scaled form, but it is a real number, so it degrades to the f64 reading — a float target converts, matching msodbcsql's ConvertToFloat accumulating all four words into a double, and an integer target reports 22003 from the ordinary range check. That also resolves the string-vs-typed divergence noted here: SQL_C_CHAR and SQL_C_SLONG no longer disagree about the same value.

The parity question raised here was answered in #284 rather than assumed from the spec: sqlcprot.h maps CVT_PREC → IDS_22_003 and CVT_ILLEGAL → IDS_07_006, and sqlccnvt.cpp ConvertToFixed returns CVT_PREC from its range checks while reserving CVT_ILLEGAL for its default: arm — the same split now drawn in numeric_source, and cited in the code comment.

decimal_limbs_are_reassembled_and_bounded was updated as predicted, plus wide_decimal_into_float_target_matches_msodbcsql and oversized_decimal_into_float_target_is_out_of_range.

Two follow-ups raised here were not covered by #284 and are still open questions:

1. Whether the decoder should range-check a decimal magnitude against its declared precision, closing the wire-reachable case at the source instead of at the conversion. Report 22003 for an unrepresentable numeric column value #284 handled it at the conversion layer only. Related in spirit to mssql-tds: SQL_VARIANT narrows a u32 data length to u8, desynchronizing the token stream #280.
2. mssql-odbc is still missing from the "Affected crate" dropdown in .github/ISSUE_TEMPLATE/bug_report.yml.

Happy to file either separately if they are worth tracking.