FreeTDS Development Group

["James K. Lowden" <jklowden AT freetds.org>]

ZIGLIO, Frediano, VF-IT wrote:
> I think is a very big idea... that is good, feasible but very
> complicated and far from fixing done processing... your change is... a
> lot of change...
> - token handling, separate each token handling with different function
> - token processing, put more processing on libTDS
> - library change, change all libTDS interface
> But if you are able to work on a document you already think enough :)

        :-)

I spent most of Friday reading db-lib.  I want to get rid of
dbresult_state.  It's only used to communicate state information from
dbresults to dbnextrow.  It's very complicated and, I think, unnecessary. 


Problem is, I need a scalpel, not an ax.  It's tricky work.  

After writing my "big idea" and reading the code some more, I came to this
conclusion about row processing:

0.  Definition: "post results" is anything the server sends after a result
set, i.e., output parameters, compute rows, and return status.  (Note that
there need not be any resultset.[1])
1.  dbresults (and SQLMoreResults) read metadata from the server.  
2.  If there are no metadata (no results), they should read any PARAM
packets and any return status.  
3.  dbnextrow (and SQLFetch), of course, read a row.  They should stop at
the first of A) the before next ROW token or B) after the last DONE
packet.  
4.  Metadata should be freed with row data.  
5.  Compute rows should be freed on the first of A) new metadata or B)
sending new query.  
6.  Return status is not malloc'ed, but should be reset on sending a new
query. 

IOW, for the convenience of the application and reliability of the
library, we should read post results as soon as possible and keep them as
long as possible.  

As you can see from my last commits, I added more logging to try to track
the interaction between db-lib and libtds.  I'm going to try to make
db-lib behave as above, and see if that helps our "done processing".  

Regards, 

--jkl


[1]     CREATE PROCEDURE @maxtype sysname OUTPUT
        as 
        SELECT @maxtype = max(name) FROM systypes
        RETURN 1