FIX: executemany RuntimeError when decimals change signs (GH-557)#560
Conversation
Root cause: In executemany(), Decimal values in the SMALLMONEY/MONEY range are bound as SQL_VARCHAR with column_size derived from a single sample value's formatted string length. The sample is chosen by _compute_column_type() based on precision/scale, not string length. When the sample is positive (e.g. '1.0' = 3 chars) but the batch contains a negative value (e.g. '-0.1' = 4 chars), the leading '-' makes it exceed the allocated buffer, causing the C++ layer to throw RuntimeError. Fix: After paraminfo is created for auto-detected types, scan all Decimal values in the column to find the true maximum formatted string length and adjust columnSize accordingly. This mirrors the existing pattern used for binary data sizing. Added test_executemany_decimal_sign_change covering: negative-then-positive, positive-then-negative, mixed sign batches, and data correctness verification. Closes #557
📊 Code Coverage Report
Diff CoverageDiff: main...HEAD, staged and unstaged changes
Summary
📋 Files Needing Attention📉 Files with overall lowest coverage (click to expand)mssql_python.pybind.logger_bridge.cpp: 59.2%
mssql_python.pybind.ddbc_bindings.h: 66.5%
mssql_python.row.py: 70.5%
mssql_python.pybind.logger_bridge.hpp: 70.8%
mssql_python.pybind.ddbc_bindings.cpp: 74.3%
mssql_python.pybind.connection.connection.cpp: 76.2%
mssql_python.__init__.py: 77.3%
mssql_python.ddbc_bindings.py: 79.6%
mssql_python.pybind.connection.connection_pool.cpp: 79.6%
mssql_python.connection.py: 85.2%🔗 Quick Links
|
There was a problem hiding this comment.
Pull request overview
Fixes cursor.executemany() failures when batches contain decimal.Decimal values whose formatted length differs across rows (notably due to sign changes), by ensuring the inferred parameter columnSize can accommodate the longest value in the batch. This aligns with the reported RuntimeError in GH-557 and adds regression coverage.
Changes:
- Update
executemanyparameter sizing forDecimalvalues that are bound asSQL_VARCHARby scanning the batch to find the maximum formatted length (GH-557). - Add a regression test that inserts decimal batches with sign changes and verifies inserts succeed and data is retrievable.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| mssql_python/cursor.py | Adjusts executemany auto-detected SQL_VARCHAR column sizing to avoid under-allocation when Decimal string length varies across rows. |
| tests/test_004_cursor.py | Adds a regression test covering executemany with Decimal values that change sign within/between batches (GH-557). |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
…rialized column list
…rialized column list
…rialized column list
…s://github.com/microsoft/mssql-python into jahnvi/fix-executemany-decimal-sign-change-557
bewithgaurav
left a comment
bewithgaurav
left a comment
There was a problem hiding this comment.
ran the #557 reproducer matrix on macos arm64 against sql2022, all seven cases pass on this branch ([0.1, -0.1], [-0.1, 1.0], [1.0, -12345678.9] all fail on origin/main with Input string UTF-16 length exceeds allowed column size, fixed here). hoisting max_decimal_formatted_len into _compute_column_type keeps it to a single pass, and the bump matches what gets written at the per-row format(val, "f") step, so sizing stays consistent end-to-end. diff coverage 100%, all existing reviewer threads addressed. one tiny ride-along on the test docstring inline. lgtm.
Work Item / Issue Reference
Summary
This pull request fixes an issue with inserting decimal values of varying sign (positive/negative) using
executemany, where the allocated column size could be too small if a negative value's string representation is longer than the sample used for sizing. It ensures the correct column size is used for all rows, preventing runtime errors. A new test is added to verify the fix.Bug fix for decimal handling in
executemany:mssql_python/cursor.py, when inserting decimals asSQL_VARCHAR, the code now scans all rows to determine the maximum formatted string length, ensuring the column size is large enough even when negative values are present.Testing improvements:
test_executemany_decimal_sign_changeintests/test_004_cursor.pyto cover cases where decimals change sign, verifying that no runtime error occurs and the data is correctly inserted and retrieved.