FreeTDS Development Group

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

hey brian,

I have had to add a couple of bits and pieces to the TDSSOCKET already
(including a counter similar to the one you suggest), but it doesn't get us
round these issues - the compute rows piece was a bit more complicated than
it looked at first sight. First up, for each query you process, you not only
get 1 normal resultinfo message, you can get any number of varied resultinfo
messages - one for each COMPUTE clause on the query . You don't know how
many of these you're going to get until you read them. 
Then as you process the rows, you get COMPUTE rows for any or all of the
COMPUTE clauses as the "breaks" in the "report" happen. You then have to tie
these back to the relevant resultinfo message using the "compute id" you get
on each row. phew!
 
But you didn't *really* want to know any of that did you ?
Hope all is well with your other project :-)

Bill
    
> -----Original Message-----
> From: Brian Bruns [SMTP:camber AT ais.org]
> Sent: Tuesday, September 24, 2002 6:58 PM
> To:   TDS Development Group
> Subject:      [freetds] RE: coding advice, please...
> 
> Bill,
> 
> I'm not following the thread too closely (other priorities), but question
> for you, can this stuff be inferred by having a num_compute_rows field in
> TDSSOCKET?
> 
> Brian
> 
> > James,
> > 
> > > Bill, 
> > > 
> > > Since you asked , I'll agree with Steve, since he's so agreeable.  
> > > 
> > > The simple fact is, as I see it, that tds_process_row_tokens() has
> more to
> > > say than yea/nae, so it should say it.  Making libtds better is good.
> > > Omelettes and eggs and all that.  
> > > 
> > 
> > I think this may be turning into the mother of all omelettes! 
> > My travails with tds_process_row_tokens() are a vicar's tea party
> compared
> > with the prospect of rewriting the "row buffering" functionality in
> > dblibrary to handle compute rows that are liberally and randomly
> > interspersed with data rows!
> > 
> > > While I don't advocate gratuitous changes to libtds, neither should we
> let
> > > the tail wag the dog.  It's there for us, to help us create the client
> APIs,
> > > and anything we do to it toward that end will benefit many people,
> 1000
> > > times more (I mean that literally) people than those inconvenienced.
> We can
> > > make it work now and make excuses later.  :)
> > 
> > I agree. Thanks!
> > 
> > > 
> > > BTW, I think your compute-row handling may overlap with Frediano's
> output
> > > parameter handling.  Cf. dbretdata().  I don't know what you'll find
> on the
> > > wire; I'm speculating.  
> > >
> > 
> > It should be a different token stream. Freddy, I can help with the
> streams
> > for this data if you like ( markers 0x79 and 0xac ? )
> > 
> > Bill
> 
> ---
> You are currently subscribed to freetds as: [thompbil AT exchange.uk.ml.com]
> To unsubscribe, forward this message to
> $subst('Email.Unsub')