Skip to Content.
Sympa Menu

freetds - Re: null handling

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Thompson, Bill D (London)" <ThompBil AT exchange.uk.ml.com>
  • To: "'TDS Development Group'" <freetds AT franklin.oit.unc.edu>
  • Subject: Re: null handling
  • Date: Fri, 27 Sep 2002 15:13:32 +0100


Brian, Freddy,

I was starting to work on row buffering.

My problem is the compute rows which I am now able to process.
These may be interspersed with the data data rows which they summate.

having taken a look at it, I reckoned that the row buffering logic assumed
the following:

1) that all the rows it would be buffering would be of the same type, and
2) that they could all be described by the "resinfo" structure.

I was thinking of reworking the buffer to be a linked list of structures.
Those structures being roughly :

struct rowbuffer {
int rowtype; /* regular row or compute row */
int compute_id; /* which compute statement does this entry relate to */
byte *data;
struct rowbuffer *nextptr;
}

would this type of approach handle Freddy's problem ?


Bill
> -----Original Message-----
> From: Brian Bruns [SMTP:camber AT ais.org]
> Sent: Friday, September 27, 2002 3:07 PM
> To: TDS Development Group
> Subject: [freetds] Re: null handling
>
> Freddy,
>
> The problem is row buffering. you may store many rows in the row buffer
> and expect there null values to reflect that row as you traverse through
> them. This applies only to dblib, and perhaps row buffering in dblib
> needs to take on this responsibility in order to keep libtds as clean as
> possible. Any of you dblib folks working on row buffering? I think Craig
> did the orignal implementation.
>
> row buffering is also broken for blob types for the same reason.
>
> Brian
>
> > I don't understand the reason to store null bool bit into current_row...
> > Perhaps past implementation do not store field information (like size of
> > pointer to data) into TDSCOLINFO and store all in current_row.
> > I think the fastest way to store null flag is to initialize
> > column_cur_size to -1... not require extra space...
> >
> > The problem came with params. When returning params we don't know how
> > many params are present in result, so we extend current_row for every
> > params arrived. Current implementation do not take into account null
> > flags (not allocated or handled) while RPC can return null params...
> > I'm implementing code to handle null bit but I think storing in
> > TDSCOLINFO is simple...
> >
> > freddy77
>
> ---
> You are currently subscribed to freetds as: [thompbil AT exchange.uk.ml.com]
> To unsubscribe, forward this message to
> $subst('Email.Unsub')





Archive powered by MHonArc 2.6.24.

Top of Page