Issue 51: SQLLEN comparisons to SQL_NULL_DATA failing, x86_64 RHEL 5 with easysoft unixODBC headers
Status:  Complete
Owner:
Closed:  Sep 2010
Reported by bbro...@gmail.com, May 19, 2009
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
Project Member #1 mkleehammer
Wow.  Thanks for catching this and providing a fix.

On Windows, SQLLEN is an int64 and SQL_NULL_DATA is (-1).  Assuming the 64-bit driver
is correctly putting a 64-bit -1 in the field, it should work.

What is in the easysoft headers for:

  1) SQLLEN
  2) SQL_NULL_DATA

I agree we should make the fix as you've done, but I'd really like to put some
comments in to explain why.  Also, if we determine that the easysoft headers could be
improved, I'd like to make that suggestion to them.

Finally, what system are you using?  Most Linux systems are using the unixODBC or
iODBC headers.  Is this for OS/X?

Thanks.


Status: Investigating
Owner: mkleehammer
May 20, 2009
#2 bbro...@gmail.com
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
Project Member #3 mkleehammer
I believe all of this is fixed in 2.1.8, though I tested in Fedora 13 64-bit.

Status: Fixed
Nov 21, 2010
Project Member #4 mkleehammer
(No comment was entered for this change.)
Status: Complete