FreeTDS Development Group

["Thompson, Bill D (London)" <ThompBil AT exchange.uk.ml.com>]

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')