FreeTDS Development Group

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

Excellent, I look forward to seeing this stuff checked in.  Just maybe we
can get 0.60 out the door soon.

Once, 0.60 is done, I'm going to take a bit of a hiatus from the day to
day stuff, and when I have time, I'm going to work on finally getting
domain logins working.  Talked to some of the samba guys last night, and
I've got some ideas.

> Brian,
> 
> Im dealing with this in the API layer. It's pretty straightforward.
> 
> For example in the manual page for cs_convert it says :
> srcdata - A pointer to the source data. To indicate that the source =
> data
> represents a null value, pass srcdata as NULL. If srcdata is NULL,
> cs_convert places the null substitution value for the datatype =
> indicated by
> destfmt=AEdatatype in *destdata.=20
> Table 2-14 lists the default null substitution value for each datatype. =
> An
> application can define custom null substitution values by calling =
> cs_setnull
> So thats pretty much what I've done ( I've left out the cs_null bit - =
> shit,
> those guys thought of everything...)
> I'm also dealing with "like to like" conversions in the API layer. No =
> need
> to call tds_convert for those....
> Bill
> 
> 
> 
> > -----Original Message-----
> > From:       Brian Bruns [SMTP:camber AT ais.org]
> > Sent:       Thursday, July 11, 2002 3:47 PM
> > To: TDS Development Group
> > Subject:    [freetds] RE: Bug converting NULL field in SQLBindCol?
> >=20
> > Bill,
> >=20
> > 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.
> >=20
> > Brian
> >=20
> > > Small world!
> > >=20
> > > 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!
> > >=20
> > > have patience and it will be fixed....
> > >=20
> > > Bill
> > >=20
> > > > -----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?
> > > >=20
> > > > Hi,
> > > >=20
> > > > 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).
> > > >=20
> > > > 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.
> > > >=20
> > > > 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).
> > > >=20
> > > > 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.
> > > >=20
> > > > Thanks,
> > > >           Paul Rensing
> > > >=20
> > > >=20
> >=20