FreeTDS Development Group

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

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
>