FreeTDS Development Group

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

On Fri, 1 Oct 1999, Mark Schaal wrote:

> > Perhaps, what is needed is a tds->results_exist similar to the
> > res_info->rows_exist that is used for DBROWS()? This would allow you to
> > always know whether the previous result processing found anything or not
> > and could be cleared on a call to tds_process_row_tokens already in the
> > TDS_COMPLETED state, allowing ct_results to tell the difference without
> > the hokey 'empty_res_hack' flag I just introduced.
> > 
> > What do you think?
> > 
> > Brian
> 
> I think tds_process_result_token() needs to be redesigned slightly, 
> but I'm not sure what are the needed/correct changes.  The current
> ct_results() hack isn't pretty.  If we need a hack I'd prefer having
> it in the TDS layer rather than the client libraries.
> 
> One thing is that I suspect tds_process_result_token() ideally should
> return twice on an empty select query - once after the result setup
> information (col_names,col_info) and once for the end token.  Well,
> I know it returns twice now so I should say the returns should better
> reflect the actual token reads.  Currently for an empty result the end
> token is read in the first call but for a non-empty result the end token
> is read in the second call.  This complicates the logical flow, e.g.
> this means we can't free res_info on an end token since it might really
> have been a col_names+col_info+end_token instead.

Can't free res_info on an end token anyway, it is legal for the client to
check dbhasstat() dbretstat() and others after the query is completely
processed.

>
This is how things used to work, then something (PHP I think) needed
DBROWS() implemented. The problem is that when tds_process_result_tokens
returns the first time it needs to know whether there are rows or not,
which means it needs to read the next message. (Granted it could probably
do an unget after it reads the next token.

So the the stream must be read until 1) a row token 2) another result
token 3) an end token. Now that I'm looking at it, I want to say there was
once an tds_unget_byte() after reading an end token in the
process_result_tokens loop.  It definately doesn't look right the way it
is now.

> Of course I'm being influenced by how ctlib views things and need to
> check dblib compatability.
> 
> Another thing is that I keep hearing this whisper in the back of my mind
> that says "what about compute results?" and that adds complications.
> For a while I was considering a tds->result_type or res_info->result_type
> which could be set to REGULAR, COMPUTE, NONE, etc., but when I ran what I
> hoped would be a simple compute query "select id from items compute max(id)"
> I got something like:
>       col_names
>       col_info
>       token_167       (some compute token)
>       token_168       (compute col_info?)
>       regular rows...
>       compute row
> which interleaves regular and compute info which I didn't expect.  I don't
> know if anyone much uses "compute" but I'd like to at least make it easy
> for future support.
>
Interesting. I have some preliminary stuff in there that works for simple
computes, but by no means a complete implementation.

> Mark
> -- 
> Mark J. Schaal                                        Phone:      (909) 
> 620-7724
> TST On Ramp                                   Fax:        (909) 620-8174
> System Administrator                          E-Mail: mark AT tstonramp.com
>