Decimal arithmetic per-operator scale: SqlType.PromoteForArithmetic encodes SQL Server's per-operator precision/scale rules for + - * / %, single source of truth for both static GetSqlType and runtime DecimalArithmetic, fixes EF Core's percent-of-total LINQ shape and a latent multiplication-overflow scale bug.

RyanLamansky · RyanLamansky · commit 6fd3f6340099 · 2026-05-08T15:00:26.000-05:00
diff --git a/CLAUDE.md b/CLAUDE.md
@@ -182,6 +182,22 @@ Top-level OFFSET/FETCH (post-set-op chain) attaches alongside the top-level ORDE
 ### Aggregates
 `COUNT(*)` / `COUNT(expr)` / `COUNT(DISTINCT expr)` / `COUNT_BIG`, `SUM` / `AVG` (integer-truncating; `decimal(38, max(s, 6))` widening for AVG over decimals), `MAX` / `MIN`, statistical (`STDEV` / `STDEVP` / `VAR` / `VARP`), `STRING_AGG`, `CHECKSUM_AGG`, `APPROX_COUNT_DISTINCT`. Standalone and inside `GROUP BY` / `HAVING`.
 
+### Decimal arithmetic precision / scale
+SQL Server has per-operator scale rules for decimal that differ from the joint-envelope rule used for comparison / COALESCE / set-op type unification (probe-confirmed against SQL Server 2025, 2026-05-08):
+
+- `+` / `-`: `p = max(p1-s1, p2-s2) + max(s1, s2) + 1`, `s = max(s1, s2)`
+- `*`: `p = p1 + p2 + 1`, `s = s1 + s2`
+- `/`: `s = max(6, s1 + p2 + 1)`, `p = p1 - s1 + s2 + s`
+- `%`: `p = min(p1-s1, p2-s2) + max(s1, s2)`, `s = max(s1, s2)`
+
+When the computed precision exceeds 38, scale reduces by the excess down to a floor of `min(originalScale, 6)` and precision clips to 38. The 6-floor is what makes division stable: division always produces `s ≥ 6`, so the floor effectively becomes 6; for `+ - * %` the floor binds only when the original scale was already ≤ 6 and preserves it. `decimal(38,2) * decimal(38,2)` → `decimal(38,4)` (small scale preserved); `decimal(38,30) / decimal(38,30)` → `decimal(38,6)` (floor binds); EF Core's `decimal(10,2) * 100.0 / decimal(38,2)` → `decimal(38,24)`.
+
+Integer / money operands canonicalize to their decimal equivalent before the formulas apply (bit→(1,0) … bigint→(19,0); money→(19,4); smallmoney→(10,4)). Pure integer-pair, pure money-pair, and float-involving arithmetic skip the decimal path entirely — those produce wider integer / money / float results that match the joint-envelope `Promote`.
+
+`SqlType.PromoteForArithmetic(a, b, op)` is the single source of truth: `TwoSidedExpression.GetSqlType` calls it for the static schema, and `DecimalArithmetic` calls it for the runtime result type. The static / runtime parity is required because the row encoder rejects values whose runtime type doesn't match the schema's declared type.
+
+`SqlType.Promote` (joint-envelope, `scale = max(s1, s2); precision = min(38, max(p1-s1, p2-s2) + scale)`) is still the right rule for non-arithmetic uses (CASE, COALESCE, set ops, comparison common-type) and stays unchanged.
+
 ### Window functions
 Two shapes are modeled:
 - `ROW_NUMBER() OVER([PARTITION BY <expr-list>] ORDER BY <expr-list-with-direction>)` — for EF Core 10's top-N / Skip+Take per group. Result type `bigint`. ORDER BY is required inside OVER (parse fails otherwise — SQL Server raises Msg 4112).
diff --git a/SqlServerSimulator.Tests.EFCore/EFCoreSubquery.cs b/SqlServerSimulator.Tests.EFCore/EFCoreSubquery.cs
@@ -122,6 +122,31 @@ public void Where_ScalarComparisonAgainstSubquery_FiltersByMaxAmount()
         CollectionAssert.AreEqual(new[] { 2 }, customerIds);
     }
 
+    [TestMethod]
+    public void Projection_PercentOfTotal_DecimalDivisionScalePreserved()
+    {
+        // EF Core emits `s.Amount * 100m / (correlated SUM(...))` for the
+        // percent-of-total LINQ shape. The chained multiply+divide produces
+        // a wide-scale decimal at runtime (d(38,24)) that the static
+        // schema must agree with — otherwise the row encoder rejects on
+        // schema mismatch.
+        using var context = SeededContext();
+        var rows = context.CustomerOrders
+            .OrderBy(o => o.Id)
+            .Select(o => new
+            {
+                o.Id,
+                Pct = o.Amount * 100m / context.CustomerOrders.Where(x => x.CustomerId == o.CustomerId).Sum(x => x.Amount),
+            })
+            .ToArray();
+        Assert.HasCount(3, rows);
+        // Customer 1: orders 10 + 20 = 30. Pct for amount=10 → 33.33...; for amount=20 → 66.66...
+        // Customer 2: order 30 → 100%.
+        Assert.AreEqual(decimal.Round(10m * 100m / 30m, 6), decimal.Round(rows[0].Pct, 6));
+        Assert.AreEqual(decimal.Round(20m * 100m / 30m, 6), decimal.Round(rows[1].Pct, 6));
+        Assert.AreEqual(100m, rows[2].Pct);
+    }
+
     [TestMethod]
     public void Projection_DistinctCorrelatedCount_EmitsCorrelatedDerivedTable()
     {
diff --git a/SqlServerSimulator.Tests/DecimalTests.cs b/SqlServerSimulator.Tests/DecimalTests.cs
@@ -175,6 +175,70 @@ public void DecimalArithmetic_OverflowOnMultiplicationRaisesMsg8115()
         AreEqual("Arithmetic overflow error converting expression to data type numeric.", ex.Message);
     }
 
+    [TestMethod]
+    public void DecimalArithmetic_StaticSchemaMatchesRuntimeForDivision()
+    {
+        // The EF percent-of-total shape: (s.Amount * 100.0) / (sum). Before
+        // the per-operator-arithmetic fix, the static schema computed via
+        // joint-envelope Promote diverged from the per-operator runtime
+        // type, causing the RowEncoder to reject the value with a
+        // "decimal(38,N) vs decimal(38,M)" mismatch. The probed result is
+        // d(38,24); confirming both schema and value land at scale 24.
+        var simulation = new Simulation();
+        _ = simulation.ExecuteNonQuery("create table sales (region varchar(10), amount decimal(10,2))");
+        _ = simulation.ExecuteNonQuery(
+            "insert into sales values ('east', 100), ('east', 200), ('east', 150), ('west', 300), ('west', 500), ('west', 50)");
+        using var connection = simulation.CreateOpenConnection();
+        using var reader = connection.CreateCommand(
+            "select s.region, s.amount, s.amount * 100.0 / (select sum(s0.amount) from sales as s0 where s0.region = s.region) from sales as s")
+            .ExecuteReader();
+        AreEqual("decimal", reader.GetDataTypeName(2));
+        var pcts = new List<(string Region, decimal Amount, decimal Pct)>();
+        while (reader.Read())
+            pcts.Add((reader.GetString(0), reader.GetDecimal(1), reader.GetDecimal(2)));
+        // east totals 450; west totals 850. Verify a couple per region.
+        var (_, _, east100Pct) = pcts.Single(p => p.Region == "east" && p.Amount == 100m);
+        var (_, _, west500Pct) = pcts.Single(p => p.Region == "west" && p.Amount == 500m);
+        AreEqual(decimal.Round(100m * 100m / 450m, 6), decimal.Round(east100Pct, 6));
+        AreEqual(decimal.Round(500m * 100m / 850m, 6), decimal.Round(west500Pct, 6));
+    }
+
+    [TestMethod]
+    public void DecimalArithmetic_38CapPreservesSmallScaleForMultiplication()
+    {
+        // d(38,2) * d(38,2): formula gives p=77, s=4. The 38-cap reduces
+        // precision but the scale floor is min(originalScale, 6) = 4 (not
+        // 0 — that was a latent bug in the old non-division path). SQL
+        // Server returns d(38,4); verify the runtime value carries scale 4.
+        var v = ExecuteScalar("select cast(123 as decimal(38,2)) * cast(456 as decimal(38,2))");
+        AreEqual(56088.0000m, v);
+    }
+
+    [TestMethod]
+    public void DecimalArithmetic_38CapForDivisionFloorsAtSix()
+    {
+        // d(38,30) / d(38,30): formula gives p=107, s=69. The 38-cap with
+        // floor 6 lands at d(38,6).
+        AreEqual(1.000000m, ExecuteScalar("select cast(1 as decimal(38,30)) / cast(1 as decimal(38,30))"));
+    }
+
+    [TestMethod]
+    public void DecimalArithmetic_ChainedExpressionPropagatesScale()
+    {
+        // (d(10,2) * d(10,2)) * d(10,2) — first step yields d(21,4); next
+        // step yields d(32,6) per the multiplication formula. Ensures the
+        // schema/runtime parity holds through chaining.
+        AreEqual(8.000000m, ExecuteScalar("select cast(2 as decimal(10,2)) * cast(2 as decimal(10,2)) * cast(2 as decimal(10,2))"));
+    }
+
+    [TestMethod]
+    public void DecimalArithmetic_ModuloPreservesMaxScale()
+    {
+        // d(10,2) % d(5,2) → d(5,2): p = min(p1-s1, p2-s2) + max(s1,s2)
+        // = min(8, 3) + 2 = 5; s = max(s1, s2) = 2.
+        AreEqual(1.50m, ExecuteScalar("select cast(7.5 as decimal(10,2)) % cast(3.0 as decimal(5,2))"));
+    }
+
     [TestMethod]
     public void Promote_DecimalAndStringInComparison()
     {
diff --git a/SqlServerSimulator/Parser/Expressions/TwoSidedExpression.cs b/SqlServerSimulator/Parser/Expressions/TwoSidedExpression.cs
@@ -21,7 +21,7 @@ public sealed override SqlValue Run(Func<MultiPartName, SqlValue> getColumnValue
     protected abstract SqlValue Run(SqlValue left, SqlValue right);
 
     public sealed override SqlType GetSqlType(Func<MultiPartName, SqlType> resolveColumnType) =>
-        SqlType.Promote(left.GetSqlType(resolveColumnType), right.GetSqlType(resolveColumnType));
+        SqlType.PromoteForArithmetic(left.GetSqlType(resolveColumnType), right.GetSqlType(resolveColumnType), this.Operator);
 
     /// <summary>
     /// Numeric binary-operator dispatcher. Despite the name, this is the
@@ -84,68 +84,19 @@ private static NotSupportedException UnsupportedNumericPair(SqlValue left, SqlVa
         new($"Operator '{op}' currently supports only integer operands; got {left.Type} and {right.Type}.");
 
     /// <summary>
-    /// Decimal arithmetic with SQL Server's per-operator precision/scale
-    /// formulas (verified against SQL Server 2025):
-    /// <list type="bullet">
-    /// <item><c>+</c>/<c>-</c>: <c>p = max(p1-s1, p2-s2) + max(s1,s2) + 1</c>,
-    /// <c>s = max(s1, s2)</c></item>
-    /// <item><c>*</c>: <c>p = p1+p2+1</c>, <c>s = s1+s2</c></item>
-    /// <item><c>/</c>: <c>s = max(6, s1+p2+1)</c>,
-    /// <c>p = p1-s1+s2+s</c></item>
-    /// <item><c>%</c>: <c>p = min(p1-s1, p2-s2) + max(s1,s2)</c>,
-    /// <c>s = max(s1, s2)</c></item>
-    /// </list>
-    /// Computed precision is capped at 38; excess scale is dropped, with a
-    /// floor of 6 for division. Integer operands canonicalize to their
-    /// equivalent decimal form (bit→(1,0), tinyint→(3,0), smallint→(5,0),
-    /// int→(10,0), bigint→(19,0)) before the formulas apply.
+    /// Decimal arithmetic. The result-type computation is delegated to
+    /// <see cref="SqlType.PromoteForArithmetic"/> (which encodes the same
+    /// per-operator scale formulas verified against SQL Server 2025), so
+    /// the static <see cref="GetSqlType"/> path and this runtime path
+    /// always agree on the schema. Integer / money operands canonicalize
+    /// to their decimal equivalent before the .NET-decimal compute step.
     /// </summary>
     private protected static SqlValue DecimalArithmetic(SqlValue left, SqlValue right, char op)
     {
-        var (p1, s1) = AsDecimalPrecisionScale(left.Type);
-        var (p2, s2) = AsDecimalPrecisionScale(right.Type);
-
-        int resultPrecision, resultScale;
-        switch (op)
-        {
-            case '+' or '-':
-                resultPrecision = Math.Max(p1 - s1, p2 - s2) + Math.Max(s1, s2) + 1;
-                resultScale = Math.Max(s1, s2);
-                break;
-            case '*':
-                resultPrecision = p1 + p2 + 1;
-                resultScale = s1 + s2;
-                break;
-            case '/':
-                resultScale = Math.Max(6, s1 + p2 + 1);
-                resultPrecision = p1 - s1 + s2 + resultScale;
-                break;
-            case '%':
-                resultPrecision = Math.Min(p1 - s1, p2 - s2) + Math.Max(s1, s2);
-                resultScale = Math.Max(s1, s2);
-                break;
-            default:
-                throw new NotSupportedException($"Operator '{op}' on decimal operands isn't implemented.");
-        }
+        var resultType = (DecimalSqlType)SqlType.PromoteForArithmetic(left.Type, right.Type, op);
+        var resultPrecision = (int)resultType.precision;
+        var resultScale = (int)resultType.scale;
 
-        // 38-cap with scale-truncation. Division enforces a min scale of 6
-        // (SQL Server's documented division behavior — verified
-        // <c>d(38,30)/d(38,30) → d(38,6)</c>). Other operators allow scale
-        // to drop to 0; precision is always capped first.
-        if (resultPrecision > 38)
-        {
-            var minScale = op == '/' ? 6 : 0;
-            var excess = resultPrecision - 38;
-            resultScale = Math.Max(minScale, resultScale - excess);
-            resultPrecision = 38;
-        }
-        // Defensive clamp: scale shouldn't exceed precision (theoretically the
-        // formulas keep this invariant, but if the 38-cap dropped scale below
-        // zero, normalize back).
-        if (resultScale < 0)
-            resultScale = 0;
-
-        var resultType = SqlType.GetDecimal(resultPrecision, resultScale);
         if (left.IsNull || right.IsNull)
             return SqlValue.Null(resultType);
 
@@ -190,11 +141,6 @@ private protected static SqlValue DecimalArithmetic(SqlValue left, SqlValue righ
             : SqlValue.FromDecimal(resultType, rounded);
     }
 
-    private static (int Precision, int Scale) AsDecimalPrecisionScale(SqlType type) =>
-        type is DecimalSqlType d ? (d.precision, d.scale)
-        : SqlType.IsMoneyCategory(type) ? SqlType.MoneyAsDecimal(type)
-        : SqlType.IntegerAsDecimal(type);
-
     private static decimal ToDecimal(SqlValue v) =>
         v.Type is DecimalSqlType ? v.AsDecimal
         : SqlType.IsMoneyCategory(v.Type) ? v.AsMoney
diff --git a/SqlServerSimulator/Storage/SqlType.cs b/SqlServerSimulator/Storage/SqlType.cs
@@ -308,7 +308,8 @@ private static SqlType PromoteFromRowVersion(SqlType other) =>
     /// <summary>
     /// Joint-envelope decimal promotion used by comparison / COALESCE-style
     /// common-type decisions. Per-operator arithmetic precision/scale rules
-    /// (multiplication, division, etc.) live in the binary-expression layer.
+    /// (multiplication, division, etc.) live in
+    /// <see cref="PromoteForArithmetic"/>.
     /// </summary>
     private static SqlType PromoteDecimalPair(DecimalSqlType a, DecimalSqlType b)
     {
@@ -317,6 +318,125 @@ private static SqlType PromoteDecimalPair(DecimalSqlType a, DecimalSqlType b)
         return GetDecimal(Math.Min(38, integerPart + scale), scale);
     }
 
+    /// <summary>
+    /// Per-operator type promotion for binary arithmetic — the rules SQL
+    /// Server applies to <c>+</c> / <c>-</c> / <c>*</c> / <c>/</c> / <c>%</c>
+    /// when computing the result type. Differs from
+    /// <see cref="Promote"/> only in the decimal-involving cases: each
+    /// operator has its own precision / scale formula (probed against SQL
+    /// Server 2025), and the 38-precision cap reduces scale by the excess
+    /// down to <c>min(originalScale, 6)</c> — effectively "never below 6
+    /// for division (which always produces scale ≥ 6 anyway)" and "never
+    /// below the original scale for the other operators when the original
+    /// was already ≤ 6". Non-decimal categories (integer × integer, money
+    /// × money, float × *, etc.) reuse <see cref="Promote"/> since their
+    /// arithmetic result type matches the joint-envelope rule.
+    /// </summary>
+    /// <remarks>
+    /// Decimal scale formulas (verified against SQL Server 2025, 2026-05-08):
+    /// <list type="bullet">
+    /// <item><c>+</c>/<c>-</c>: <c>p = max(p1-s1, p2-s2) + max(s1,s2) + 1</c>,
+    /// <c>s = max(s1, s2)</c></item>
+    /// <item><c>*</c>: <c>p = p1+p2+1</c>, <c>s = s1+s2</c></item>
+    /// <item><c>/</c>: <c>s = max(6, s1+p2+1)</c>,
+    /// <c>p = p1-s1+s2+s</c></item>
+    /// <item><c>%</c>: <c>p = min(p1-s1, p2-s2) + max(s1,s2)</c>,
+    /// <c>s = max(s1, s2)</c></item>
+    /// </list>
+    /// Integer / money operands canonicalize to their decimal equivalent
+    /// (bit→(1,0), tinyint→(3,0), smallint→(5,0), int→(10,0), bigint→(19,0),
+    /// money→(19,4), smallmoney→(10,4)) before the formulas apply. Pure
+    /// integer-pair and money-pair arithmetic skips the decimal path entirely
+    /// — those produce wider integer / money results that match
+    /// <see cref="Promote"/>.
+    /// </remarks>
+    public static SqlType PromoteForArithmetic(SqlType a, SqlType b, char op)
+    {
+        // Bitwise operators (&, |, ^) don't have per-operator scale rules
+        // and don't accept decimal operands anyway — fall through to the
+        // joint-envelope rule for type unification (decimal × bitwise will
+        // raise the unsupported-numeric-pair error at runtime instead).
+        if (op is '&' or '|' or '^')
+            return Promote(a, b);
+
+        // Float / real win over everything else, same as the joint-envelope
+        // path; no decimal-style scale dance needed.
+        if (a.Category == SqlTypeCategory.Approximate || b.Category == SqlTypeCategory.Approximate)
+            return Promote(a, b);
+
+        // Decimal-involving cases: the per-operator formula applies. Money
+        // and integer canonicalize to their decimal equivalent so the
+        // formula sees a uniform (precision, scale) pair on both sides.
+        var aIsDecimal = a is DecimalSqlType;
+        var bIsDecimal = b is DecimalSqlType;
+        if (aIsDecimal || bIsDecimal)
+        {
+            var (p1, s1) = AsDecimalPrecisionScale(a);
+            var (p2, s2) = AsDecimalPrecisionScale(b);
+            return ComputeDecimalArithmeticResultType(p1, s1, p2, s2, op);
+        }
+
+        // Pure integer / money / date / string pairs: arithmetic result type
+        // matches the joint-envelope rule (e.g., int + bigint → bigint;
+        // money + money → money; int + int → int).
+        return Promote(a, b);
+    }
+
+    /// <summary>
+    /// Computes a decimal arithmetic result type from raw (p1, s1, p2, s2)
+    /// quadruples. Public to <see cref="Storage"/> via
+    /// <see cref="PromoteForArithmetic"/>; the binary-expression layer
+    /// reuses this directly so the static (GetSqlType) and runtime
+    /// (DecimalArithmetic) paths share one formula.
+    /// </summary>
+    internal static DecimalSqlType ComputeDecimalArithmeticResultType(int p1, int s1, int p2, int s2, char op)
+    {
+        int p, s;
+        switch (op)
+        {
+            case '+' or '-':
+                p = Math.Max(p1 - s1, p2 - s2) + Math.Max(s1, s2) + 1;
+                s = Math.Max(s1, s2);
+                break;
+            case '*':
+                p = p1 + p2 + 1;
+                s = s1 + s2;
+                break;
+            case '/':
+                s = Math.Max(6, s1 + p2 + 1);
+                p = p1 - s1 + s2 + s;
+                break;
+            case '%':
+                p = Math.Min(p1 - s1, p2 - s2) + Math.Max(s1, s2);
+                s = Math.Max(s1, s2);
+                break;
+            default:
+                throw new NotSupportedException($"Decimal arithmetic operator '{op}' isn't supported.");
+        }
+
+        // 38-precision cap: scale reduces by the excess, but never below
+        // min(originalScale, 6). For division s is always ≥ 6 so the floor
+        // effectively becomes 6; for the other operators the floor binds
+        // only when the original scale was already ≤ 6, preserving it.
+        if (p > 38)
+        {
+            s = Math.Max(s - (p - 38), Math.Min(s, 6));
+            p = 38;
+        }
+        if (s < 0) s = 0;
+        return (DecimalSqlType)GetDecimal(p, s);
+    }
+
+    /// <summary>
+    /// Canonicalizes any decimal-arithmetic-eligible operand type to its
+    /// (precision, scale) pair. Decimals return their declared p/s; money
+    /// and integers map to documented equivalents.
+    /// </summary>
+    private static (int Precision, int Scale) AsDecimalPrecisionScale(SqlType type) =>
+        type is DecimalSqlType d ? (d.precision, d.scale)
+        : IsMoneyCategory(type) ? MoneyAsDecimal(type)
+        : IntegerAsDecimal(type);
+
     private static DecimalSqlType IntegerAsDecimalType(SqlType integer)
     {
         var (p, s) = IntegerAsDecimal(integer);
