Skip to Content.
Sympa Menu

freetds - Re: Ack...token.c question...

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Brian Bruns <camber AT umcc.ais.org>
  • To: TDS Development Group <freetds AT franklin.oit.unc.edu>
  • Subject: Re: Ack...token.c question...
  • Date: Tue, 6 Jul 1999 22:35:07 -0400 (EDT)




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."
>





Archive powered by MHonArc 2.6.24.

Top of Page