Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Decimal in money range still string-binds on the executemany path

Đang mở
  • Có gì không ổn?
#745 1 bình luận 0 reaction 1 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 2 ngày

@bewithgaurav đang làm issue này rồi.

Từ ngày 21/9/2026.

  • #752 của @vyrnsynx — đang mở
  • #770 của @IMGillusion — đã đóng, không merge

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
48/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
python, sql
Lĩnh vực
databases

Hướng nghiên cứu

Bắt đầu bằng cách lần theo đường dẫn liên kết tham số của executemany và so sánh với các bản sửa lỗi của execute() trong #740. Tái hiện batch Decimal với numeric(5,2), sau đó tính đến độ chính xác và scale trên toàn batch, đồng thời giữ nguyên hành vi liên kết chuỗi của GH-503 và việc tính kích thước với dấu hỗn hợp của GH-557; được xem là hoàn tất khi batch được liên kết an toàn dưới dạng SQL_NUMERIC mà không có các hồi quy đó.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

area: data-types bug triage done under development
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 numeric

This 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

Ngôn ngữ chính
Python
Star
478
Fork
62
Merge trung bình
3 ngày 19 phút
Pull request đã merge (30 ngày)
28

Chuẩn bị môi trường

Mở trong Codespaces

Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của microsoft/mssql-python

Tất cả issue của microsoft/mssql-python

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.