FreeTDS Development Group

["ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>]

> > 
> > At http://freetds.sourceforge.net/out/test/out.html you can find
> > tests results for current CVS. As you can see all tests passed
> > without errors (only some error detected in glibc by valgrind but
> > they are glibc/valgrind problems). IMO we should start to think
> > about a 0.64 release. OTL now works flawlessly (I used an old test
> > from ML).
> 
> I would like to disturb the error message stack first, before 
> releasing
> 0.64.  I'm expecting to have some time this month, and I think I know
> what to do.  
> 
> Are you satisfied that ODBC now correctly handles
> resultset-error-resultset packet sequences?  I haven't tested 
> it lately
> because I thought you were still working on it.  
> 
> Thanks for all your hard work, Freddy.  It just keeps getting 
> better.  
> 

Don't mind, I didn't ask a release for tomorrow :) Just to start
stabilizing things and do not break all...
Well, ODBC work quite fine (last change in this direction is some months
old) however I'm not satisfied with the complexity. Current complexity
suggest me that perhaps current code is too much composed by fixes over
fixes. So I started searching how proprietary libraries behave to
various conditions. Now I discovered that dblib is quite different. I
think that my test demonstrate that proprietary library behave
consistensively but differently. It reads some tokens before our library
and make connection idle some time before. For example in a simple
select you can post a query just after dbnextrow return NO_MORE_ROWS (is
not required to call dbresults). I think that even ODBC require some
adjustment in this direction... for example I don't like test for
TDS_SP_EXECUTE or the duplication beetween SQLMoreResults and
_SQLExecute.
I don't know if this stuff is related to
http://sourceforge.net/tracker/index.php?func=detail&aid=1209286&group_i
d=33106&atid=407806.

freddy77