Skip to Content.
Sympa Menu

freetds - Re: CT lib source?

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Mark Schaal <mark AT champ.tstonramp.com>
  • To: freetds AT franklin.oit.unc.edu
  • Subject: Re: CT lib source?
  • Date: Fri, 1 Oct 1999 15:07:10 -0700 (PDT)


>
>
> Mark,
>
> 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?
>
> 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.

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.

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



  • Re: CT lib source?, Mark Schaal, 10/01/1999

Archive powered by MHonArc 2.6.24.

Top of Page