FreeTDS Development Group

["Brian Bruns" <camber AT ais.org>]

Bill,

Have you decided which approach you are taking on this? NULL handling
brings up another condition, we've never expected the conversion routines
to be responsible for it, the API's differ quite a bit on this issue.

Brian

> Small world!
> 
> I am actually in the process of doing a rework on the convert functionality
> in FreeTDS.
> There are a number of shortfalls in this, of which you've just spotted one.
> I spotted the same issue as I was going through the code a couple hours ago!
> 
> have patience and it will be fixed....
> 
> Bill
> 
> > -----Original Message-----
> > From:       Paul Rensing [SMTP:paul.rensing AT att.net]
> > Sent:       Thursday, July 11, 2002 2:46 PM
> > To: TDS Development Group
> > Subject:    [freetds] Bug converting NULL field in SQLBindCol?
> > 
> > Hi,
> > 
> > I am using FreeTDS as an ODBC driver talking to a SQLServer. This is under
> > RedHat 7.3 with FreeTDS from about June 7 (one of the "current" versions).
> > 
> > My actual setup is to use Python and the mxODBC code talking to the
> > unixODBC code. Everything works pretty well except there is a problem if
> > the database entry is NULL (the column is typed as a float). When the DB
> > has a NULL, the Python code gets back the previous value that was in that
> > column; that is, it is referencing old, stale data.
> > 
> > The mxODBC code attempts to use SQLBindCol where possible. The problem
> > appears to be that tds_convert() and its children (tds_convert_flt8() in
> > this case) don't seem to check whether the NULL flag is set and thus clear
> > the data field and length. mxODBC expects the length field to be set to
> > SQL_NULL_DATA (which is -1 in sql.h).
> > 
> > So, where is the bug? I would be glad to help a little, but I am not very
> > familiar with ODBC code. If someone can let me know what the right
> > behaviour is, I can attempt a patch.
> > 
> > Thanks,
> >           Paul Rensing
> > 
> >