CT lib source?
mark at champ.tstonramp.com
Fri Oct 1 18:07:10 EDT 1999
> Basically it is simple for single result queries. tds->res_info is
> defined if there are results. However, this structure has to hang around a
> while after the results are processed so things like row counts, retrun
> statses, and all that garbage can be checked. So, for multi result
> queries and subsequent calls to tds_process_result_tokens() after
> everything is done we can't clear it (until the next query is sent).
> 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?
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.
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:
token_167 (some compute token)
token_168 (compute col_info?)
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.
Mark J. Schaal Phone: (909) 620-7724
TST On Ramp Fax: (909) 620-8174
System Administrator E-Mail: mark at tstonramp.com
More information about the FreeTDS