Skip to Content.
Sympa Menu

freetds - Re: CT lib source?

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Brian Bruns <camber AT umcc.ais.org>
  • To: TDS Development Group <freetds AT franklin.oit.unc.edu>
  • Subject: Re: CT lib source?
  • Date: Thu, 30 Sep 1999 22:01:12 -0400 (EDT)



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

On Thu, 30 Sep 1999, Mark Schaal wrote:

> >
> > As for the problem under FreeTDS, I know what the deal is with the
> > behaviour of ct_results(), I'm just trying to decide which is the right
> > way to fix it. If nothing strikes me as the the right way by tonight, I'll
> > kludge it and fix it up later.
> >
> > Brian
>
> That's the same feeling I had when I looked at it. One related thing I
> noticed is that fixing it should allow implemention of DBCMDROW for dblib
> as a side benefit.
>
> Mark
> --
> Mark J. Schaal Phone: (909)
> 620-7724
> TST On Ramp Fax: (909) 620-8174
> System Administrator E-Mail: mark AT tstonramp.com
>





Archive powered by MHonArc 2.6.24.

Top of Page