SQLLEN comparisons to SQL_NULL_DATA failing, x86_64 RHEL 5 with easysoft unixODBC headers

[GoogleCodeExporter]

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

Original issue reported on code.google.com by bbro...@gmail.com on 19 May 2009 at 10:34

[GoogleCodeExporter]

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.

Original comment by mkleehammer on 20 May 2009 at 4:46

• Changed state: Investigating

[GoogleCodeExporter]

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.

Original comment by bbro...@gmail.com on 20 May 2009 at 10:44

[GoogleCodeExporter]

I believe all of this is fixed in 2.1.8, though I tested in Fedora 13 64-bit.

Original comment by mkleehammer on 6 Sep 2010 at 6:04

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by mkleehammer on 21 Nov 2010 at 4:44

• Changed state: Complete