FreeTDS Development Group

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

On Tue, 6 Jul 1999, Kevin wrote:

> Quick question...in libtds v0.45, there's a function called
> tds_clr_null().
> Since we're runnin' it off our Solaris box, and just recently upgraded,
> I was running some tests against it and noticed a strange problem with
> each call to 
> tds_clr_null.
>

This was added in the 0.45 version.  Basically, the row buffer is not
cleared between rows, so clr_null was used if it was a non-null value.
Probably the better was to do it would be to memset it to 0 and the call
set_null for null values...it'll be quicker that way anyway.

But that doesn't explain why it's failing ;)

One change that was made for NULLs was to add an area at the front of the
row buffer equal to 'number of columns' / 8, which stores the NULL
information one bit per column. The tds->cols[0]->column_offset (or
whatever its called, I'm at my wifes machine and doing this from memory)
should be set to the start of the actual data. 
        
>       Within the for loop of tds_process_row, the tds_clr_null() function
> gets called each time the column value for the current row is not null.
> With a five column select, no columns which were null, I got the
> following behavior printing out the first 2 bytes of
> tds->res_info->current_row which should have a value of NE
> 
>       Processing column 1 of 5:
>               before clr_null: 00 00
>               after  clr_null: 00 00
>       Processing column 2 of 5:
>               before clr_null: 4E 45
>               after  clr_null: 4C 45
>       Processing column 3 of 5:
>               before clr_null: 4C 45
>               after  clr_null: 48 45
>       Processing column 4 of 5:
>               before clr_null: 48 45
>               after  clr_null: 40 45
>       Processing column 5 of 5:
>               before clr_null: 40 45
>               after  clr_null: 40 45
>
This looks essentially right, except for the the fact that the first
column is going into bytes 0 and 1 of the row buffer.  It should have a 1
byte (for 5 columns) area preceding the data for NULL indicators.  That
is, tds_set_null and tds_clr_null seem to be working correctly, something
with the row buffer is amiss. From what I remember, changes were made
to tds_alloc_row() and tds_process_row() and some other place to
support this.  Look for something like offset = xxx.  I'll check it out
later tonight (once I get back up to my office), do you have a code sample
and table definition that this happens with?

> Once I commented out the current_row[bytenum] &= mask line, the problems
> went away. 
>       Is the tds_clr_null function a necessary one for some reason? I havn't
> been able to figure out it's purpose...
> 
> -- 
> Kevin Lyons                                      Programmer for Nebrask@
> Online
> Phone: 402-471-7870                                       e-mail:
> kevin AT nol.org
> -------------------------------------------------------------------------------
> "I didn't say it was your fault...I said I was going to blame it on
> you."
>