| Issue 186: | BIGINT problem on 32-bit architeture | |
| 1 person starred this issue and may be notified of changes. | Back to list |
What steps will reproduce the problem? ====================================== Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import pyodbc >>> cnx = pyodbc.connect("DSN=mytestdb") >>> cur = cnx.cursor() >>> cur.execute("CREATE TABLE t (value BIGINT)") <pyodbc.Cursor object at 0x0310D9F8> >>> cur.execute("INSERT INTO t VALUES (-430000000)") <pyodbc.Cursor object at 0x0310D9F8> >>> for i in cur.execute("select * from t"): ... print i ... (18446744073279551616L, ) Not that this value should fit in a 32bit integer. Even a signed one. Now to rule out sqlite3 problems: >>> import sqlite3 >>> cnx = sqlite3.connect("C:/tmp/testdb.db") >>> cur = cnx.cursor() >>> cur.execute("CREATE TABLE t (value BIGINT)") <sqlite3.Cursor object at 0x0311AB30> >>> cur.execute("INSERT INTO t VALUES (-430000000)") <sqlite3.Cursor object at 0x0311AB30> >>> for i in cur.execute("select * from t"): ... print i ... (-430000000,) >>> So it appears to work okay when using the sqlite3 module. I tried building pyodbc (both 32 bit and 64 bit) on solaris and tried it there and it appears that the 64-bit version will do the right thing. using isql (from unixodbc) on solaris, I can also get the right output so it seems that sqliteodbc will also do the right thing. What is the expected output? What do you see instead? ====================================================== I expect to get back the value I put into the DB. What version of the product are you using? On what operating system? ===================================================================== Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import pyodbc >>> pyodbc.version '2.1.8' Please provide any additional information below. ================================================
Jul 3, 2011
Project Member
#1
mkleehammer
Status:
NoFix
Jul 3, 2011
I just sent an email to the author of the driver. If I get a response, I'll post it here. Since I need to create a set of unit tests, I'm re-opening this with status Hold as a reminder.
Status:
Hold
Jul 3, 2011
First of all, thanks for looking at this. I'm not saying you are wrong in your conclusions, but I think SQLite3 should support signed types. From http://www.sqlite.org/datatype3.html - "INTEGER. The value is a signed integer, stored in 1, 2, 3, 4, 6, or 8 bytes depending on the magnitude of the value." That doesn't mean everything will work as expected of course. I did some more tests and ended up installing a 32-bit ubuntu (64-bit seemed to work OK and I thought I'd try to debug a little...) Anyway, when running my example on latest ubunutu 32-bit, I actually got the negative value back. So the score so far is: returning large positive value: 32-bit Solaris 10 and 32-bit Windows Vista. returning negative values: 64-bit Solaris 10, 64-bit Ubuntu 10.04 and 32-bit ubuntu 10.04. On solaris I built python, unixodbc, sqlite and sqliteodbc myself, so I will have a look at flags to see if I have missed something there. I'll follow up here if I find something of interest.
Jul 3, 2011
I agree that it supports signed. I don't think it supports unsigned. The driver is reporting the value as unsigned when it should be signed.
Jul 3, 2011
Right, my bad. :) I misunderstood what you wrote.
Jul 4, 2011
I've already tested 0.91 pre-release of the ODBC driver and it fixes the issue. Thank you Christian Werner for looking at this so quickly. I was under the impression that it was going to be released right away. Closing with Nofix now that a solution is available.
Status:
NoFix
Jul 4, 2011
Great, thanks for the help! :) |