Describe the bug
#740 fixed money-range Decimal binding on both execute() routes (the native C++ path and the Python legacy path used when setinputsizes() covers fewer positions than parameters). executemany() is the one remaining path that still carries the money-range VARCHAR shortcut, so a money-range Decimal compared through executemany can still overflow:
cur.executemany("UPDATE t SET x = 1 WHERE v = ?", [(Decimal("12345.6789"),)])
# against v numeric(5,2): Arithmetic overflow error converting varchar to data type numericThis is a non-shape in practice (executemany runs the statement per row and discards results, so nobody runs a comparison-SELECT through it), and it is not reachable from Django, which is why it is lower priority than #740.
Why it was scoped out of #740
executemany declares one parameter type for the whole batch and lets the server coerce each row's formatted string (GH-503). Switching money-range Decimals to SQL_NUMERIC there needs a single NUMERIC(precision, scale) that fits every row in the batch, which the code does not compute today — it tracks max string length, not max precision and scale. A naive switch regresses a mixed-sign batch (the GH-557 shape) with a string-truncation error.
Suggested fix
Add batch-wide precision/scale derivation in executemany so it can bind money-range Decimals as SQL_NUMERIC (like both execute() paths) without breaking the GH-503 batch string binding or the GH-557 mixed-sign column sizing.
Further technical details
mssql-python version: reproduces on the main branch alongside #740.
SQL Server version: SQL Server 2022
Operating system: driver-side, OS-independent
Describe the bug
#740 fixed money-range
Decimalbinding on bothexecute()routes (the native C++ path and the Python legacy path used whensetinputsizes()covers fewer positions than parameters).executemany()is the one remaining path that still carries the money-range VARCHAR shortcut, so a money-rangeDecimalcompared throughexecutemanycan still overflow:This is a non-shape in practice (
executemanyruns the statement per row and discards results, so nobody runs a comparison-SELECT through it), and it is not reachable from Django, which is why it is lower priority than #740.Why it was scoped out of #740
executemanydeclares one parameter type for the whole batch and lets the server coerce each row's formatted string (GH-503). Switching money-range Decimals toSQL_NUMERICthere needs a singleNUMERIC(precision, scale)that fits every row in the batch, which the code does not compute today — it tracks max string length, not max precision and scale. A naive switch regresses a mixed-sign batch (the GH-557 shape) with a string-truncation error.Suggested fix
Add batch-wide precision/scale derivation in
executemanyso it can bind money-range Decimals asSQL_NUMERIC(like bothexecute()paths) without breaking the GH-503 batch string binding or the GH-557 mixed-sign column sizing.Further technical details
mssql-python version: reproduces on the
mainbranch alongside #740.SQL Server version: SQL Server 2022
Operating system: driver-side, OS-independent