FreeTDS Development Group

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

The problem is that tds_convert shouldn't get called at all, the problem
is in SQLFetch...replace:

          if (colinfo->varaddr) {

with
          if (colinfo->varaddr && !tds_get_null(resinfo->current_row,i)) {

and a bit further down replace

          if (colinfo->column_lenbind) {
               *((SQLINTEGER *)colinfo->column_lenbind)=len;
          }

with

          if (colinfo->column_lenbind) {
               if (tds_get_null(resinfo->current_row,i)) {
                   *((SQLINTEGER *)colinfo->column_lenbind)=SQL_NULL_DATA;
               } else {
                   *((SQLINTEGER *)colinfo->column_lenbind)=len;
               }
          }


curiously enough, SQLGetData seems to have a proper implementation...Usual
caveats of possible uncompilable code apply. ;-)  I'll do a proper patch
tonight.

Brian

> 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