Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Very large integers as parameters #670

Closed
keitherskine opened this issue Jan 5, 2020 · 1 comment · Fixed by #671
Closed

Very large integers as parameters #670

keitherskine opened this issue Jan 5, 2020 · 1 comment · Fixed by #671

Comments

@keitherskine
Copy link
Collaborator

Environment

To diagnose, we usually need to know the following, including version numbers. On Windows, be
sure to specify 32-bit Python or 64-bit:

  • Python: 3.7.5
  • pyodbc: 4.0.28
  • OS: Windows 10 Pro, 64-bit
  • DB: SQL Server 2019 Express
  • driver: ODBC Driver 17 for SQL Server

Issue

Python allows integers of more-or-less any size. When inserting a very large integer to a table as a parameter (a value larger than an 8 byte integer can contain), the value of -1 is inserted instead. Oddly, an exception is also raised but not one of the standard PEP249 exceptions. I would expect a PEP249 exception to be raised by pyodbc itself and nothing written to the database. Here is the code that reproduces the issue:

import pyodbc
cnxn = pyodbc.connect(dsn='<my_DSN>', autocommit=True)
crsr = cnxn.cursor()

crsr.execute("DROP TABLE IF EXISTS T1")
crsr.execute("CREATE TABLE T1 (col1 BIGINT NULL)")

try:
    sql = "INSERT INTO T1 (col1) VALUES (?)"
    parameters = (99999999999999999999999999999999999999999999999999,)
    crsr.execute(sql, parameters)
except Exception as err:
    print('exception:', err)

rows = crsr.execute("SELECT * FROM T1").fetchall()
print('table records:', rows)

crsr.close()
cnxn.close()

This code outputs:

exception: <method 'execute' of 'pyodbc.Cursor' objects> returned a result with an error set
table records: [(-1, )]

My guess is that PyLong_AsLongLong is returning -1 (as expected) but then PyErr_Occurred() is not being checked somewhere. Here perhaps?

@v-makouz
Copy link
Contributor

Nice! Looks like a good change, hopefully @mkleehammer can merge it in

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants