FreeTDS Development Group

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

Hmmm...

Just a follow up. Here is a debug session for 'select * from titles'
from the pubs2 database with a break point in tds_process_row()

Breakpoint 2, tds_process_row (tds=0x8079338) at token.c:517
517             info = tds->res_info;
(gdb) n
518             info->row_count++;
(gdb) n
519             for (i=0;i<info->num_cols;i++)
(gdb) n
521                     curcol = info->columns[i];
(gdb) n
522                     if(curcol->column_type == SYBTEXT) {
(gdb) n
527                             colsize = tds_get_byte(tds);
(gdb) n
528                     } else {
(gdb) n
530                     }
(gdb) n
533                     if (colsize==0) {
(gdb) n
536                             tds_clr_null(info->current_row, i);
(gdb) p tds->res_info->num_cols
$6 = 10
(gdb) p tds->res_info->columns[0]->column_offset
$7 = 2
(gdb) p tds->res_info->null_info_size
$8 = 2
(gdb)

This is showing that the first column_offset (index 0) is set to 2, which
is correct (10 columns needs 2 bytes to stored NULL indicators).  Could
you post a similar debug thread for Solaris?? Maybe we can figure out what
is going on. BTW there were some header changes with 0.45 so you must
recompile your applications (I'm assuming you did that though).

Cheers,

Brian


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.
>       
>       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
> 
>       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."
> 
> ---
> You are currently subscribed to freetds as: camber AT ais.org
> To unsubscribe, forward this message to $subst('Email.Unsub')
> 
>