| Issue 51: | SQLLEN comparisons to SQL_NULL_DATA failing, x86_64 RHEL 5 with easysoft unixODBC headers | |
| 1 person starred this issue and may be notified of changes. | Back to list |
PyODBC fails to detect SQL_NULL_DATA and therefore returns invalid data instead of "None". For example, in getdata.cpp:GetDataDouble, the comparison: if (cbFetched == SQL_NULL_DATA) will not be true even if cbFetched (of type SQLLEN) is in fact equal to SQL_NULL_DATA, thus, null data is never handled correctly. It does appear to work on other systems (windows), so the problem probably lies in easysoft's headers. Nonetheless, this is a common setup and this problem should be remedied. The problem is corrected if cbFetched is first cast to a signed type, i.e. an integer as in: if ((int)cbFetched == SQL_NULL_DATA) I have made this change in all nine SQL_NULL_DATA comparisons in getdata.cpp and confirmed that None is returned as it should be. FWIW. Bob
May 20, 2009
I'm using Red Hat Enterprise Linux 5. There appears to be some sort of 64bit configuration problem with this machine and SQLLEN. I would say you could make the change just to ensure if anyone has a similar configuration problem that the code works (for example, the jdbc-odbc bridge is able to process NULLs on this machine), but, there is certainly something nonstandard about how this box was set up. We have other RHEL5 boxes that are not exhibiting this behavior. Like I said, FWIW, if someone else sees problems then this note is here for them.
Sep 6, 2010
I believe all of this is fixed in 2.1.8, though I tested in Fedora 13 64-bit.
Status:
Fixed
Nov 21, 2010
(No comment was entered for this change.)
Status:
Complete
|
Owner: mkleehammer