FreeTDS Development Group

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

> 
> > - update FreeTDS tests to catch all these problems (and fix them), 
> 
> Yay!  Looks like I'm committed to helping out in that area.  

Updated raiserror.c (it do not still works correctly)

> BTW, you said
> in another post:
> 
> > To improve test accuracy I would implement a test coverage 
> script using
> > GCC... I think that many functions still lack a test.
> 
> Is there some automated way of using gcc to implement test 
> coverage?  Or
> did you mean to use autoconf somehow?  
> 

man gcov.
Briefly
- compile with -fprofile-arcs -ftest-coverage (ie "CFLAGS='-O0
-fprofile-arcs -ftest-coverage' ./configure" and make)
- go in source directory and launch gcov (ie "gcov -c cs.c")
- read cs.c...
I think there should some project to generate statistics and similar..

> > it
> > would be fine in 0.64 to read data like MS odbc do (I 
> remember a post on
> > ML that state for example that after all rows are retrieved 
> (sqlfetch
> > returned success but never no data) it can issue another 
> query (perhaps
> > this require some change in token handling...).
> 
> I remember that we need look-ahead code sometimes.  Be 
> careful, though,
> with buffering.  Buffering the whole resultset can make 
> Microsoft's driver
> annoying to use.  If the user expects 100,000 rows, why 
> should he have to
> wait until the last one arrives before fetching the first one?  
> 

In this case I would not use the word "buffering", it just read other
"trailing" tokens (parameters returned, done, return status)

freddy77