Pull Request Checklist

• Have you added new tests to prevent regressions?
• If a documentation update is necessary, have you opened a PR to the documentation repository? — not applicable, this is an internal bugfix with no public API change.
• Did you update the typescript typings accordingly (if applicable)? — not applicable, getScale is an internal, untyped helper.
• Does the description below contain a link to an existing issue (Closes MSSQL: Query getScale calculates invalid scale #16463)?
• Does the name of your PR follow the commit conventions?

Description of Changes

Closes #16463.

getScale() (packages/mssql/src/query.js) determines how many decimal places a JS number has by repeatedly multiplying it by increasing powers of ten until Math.round stops changing it. That multiplication is itself imprecise floating-point math, so for very ordinary values whose double representation already carries a bit of rounding noise — e.g. 20.95 - 20 === 0.9499999999999993, or the value reported in #16463, 31.958508000000002 — the loop overshoots by several digits before it "settles": it returns 20 and 19 respectively, instead of the actual 16 and 15.

That inflated scale is passed straight through to tedious as typeOptions.scale. Tedious's NUMERIC encoder (generateParameterData in data-types/numeric.js) computes Math.round(Math.abs(value) * 10 ** scale) and writes the result into a fixed-size integer buffer. For the overshot cases above, that multiplication produces a number far larger than the value actually represents, which silently corrupts what ends up stored in SQL Server — the original symptom reported in #16463, and the general class of bug #12086 was trying to fix back when this code was introduced (#11962).

Fix

Compute the scale from Number#toString() instead of from repeated multiplication. Per the ECMA-262 Number::toString algorithm, toString() is defined to produce the shortest decimal string that round-trips back to the exact same double — i.e. it already tells you the true number of significant decimal digits the value has, without needing to rediscover it through lossy arithmetic. Counting the digits after the decimal point in that string gives the correct scale directly:

'20.95'.length            // regular case: count digits after '.'
(20.95 - 20).toString()   // '0.9499999999999993' -> 16 digits, not the ~20 the old loop computed

toString() switches to exponential notation for magnitudes < 1e-6 or >= 1e21. For the (common) small-magnitude case, the true scale is derivable directly from the significand's own decimals plus the (negative) exponent, so that path is handled explicitly too (and is covered by the existing 2.5e-15 test case, which still passes). Large-magnitude values that still have a fractional part are rare enough, and already imprecise enough, that this PR keeps the previous loop as a fallback for that one case rather than trying to reason about their scale.

Tests

Added a new test case to packages/core/test/unit/dialects/mssql/query.test.js reproducing the two floating-point-noise values from this issue and from the linked 20.95 - 20 example, asserting the corrected (lower) scale. Ran the full existing getSQLTypeFromJsType suite (including the pre-existing 0.30000000000000004 and 2.5e-15 cases) — all pass unchanged, confirming this isn't a behavior change for values that were already computing correctly.

DIALECT=mssql yarn mocha "test/unit/dialects/mssql/query.test.js"

  [MSSQL Specific] Query
    getSQLTypeFromJsType
      ✔ should return correct parameter type
      ✔ should return parameter type correct scale for float
      ✔ should not compute an inflated scale for values with floating-point noise (#16463)

  3 passing

Also ran the full packages/core unit suite under DIALECT=mssql (2248 passing, 6 pending, 0 failing) to confirm no other test depends on the old (incorrect) scale values.

Known residual limitation (not addressed by this PR)

This fix corrects the detection bug — it no longer invents digits that aren't there. It does not add an additional safety clamp for the (much rarer) case where a value's genuine decimal digit count, once multiplied by 10 ** scale, still exceeds Number.MAX_SAFE_INTEGER (this can happen for values whose true scale is close to 17 and whose magnitude isn't small, e.g. our own 0.9499999999999993 case still computes scale 16, and 0.9499999999999993 * 10**16 ≈ 9.5e15, just over Number.MAX_SAFE_INTEGER ≈ 9.007e15). That's a much smaller and rarer form of imprecision than the multi-digit overshoot this PR fixes, and arguably a separate, existing tradeoff of representing arbitrary-precision NUMERIC values through a JS number at all — happy to open a follow-up issue/PR for a Number.MAX_SAFE_INTEGER-aware clamp on top of this if maintainers want it, but wanted to keep this PR focused on the reported bug.

List of Breaking Changes

None expected. This only changes the computed scale for values where the previous computation was already wrong (too high); values that were already computed correctly (per the existing test suite) are unaffected.

Summary by CodeRabbit

• Bug Fixes
  • Improved numeric precision handling for MSSQL queries.
  • Correctly determines decimal scales for floating-point values, including decimal literals, subtraction results, and exponential notation.
  • Reduces issues caused by binary rounding noise in numeric query results.
  • Improves accuracy for values with very small or large magnitudes.