FreeTDS Development Group

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

Frediano Ziglio wrote:
> I fixed this test (the test was just broken).
> However I noted debugging the buffering seems to work not correctly. It
> simply do not buffer. After dbresults I would expect that dblib prefetch
> some rows in buffer but this does not occur. More over calling dbnextrow
> it simply copy the row in buffer then "return" the row. On next call
> store another row in buffer and return it. I don't understand if this is
> correct or not...

There may be errors, of course, but it is correct.  Under db-lib
buffering, rows aren't pre-fetched.  As new rows are fetched, old ones are
placed in a buffer (size defined by user), so that they can be
re-feteched.  It's a primitive form of client-side cursor.  

http://www.freetds.org/reference/a00336.html#a13

The basic approach is:

        dbsetopt(DBBUFFER)
        dbnextrow() // fetch row 1
        dbnextrow() // fetch row 2
        dbnextrow() // fetch row 3
        dbsetrow(1)
        dbnextrow() // re-fetch row 1
        dbnextrow() // re-fetch row 2
        dbnextrow() // re-fetch row 3
        dbnextrow() //    fetch row 4

[I never use it, btw.  I think it's an artifact of C (no containers) and
vendor competition ("my library's better than your library").  I always
fetch the data into C++ std containers (std::vector, std::deque), and
never think of going back to get the same row again.]

Thank you for fixing the test.  Were you able to test with Sybase's
libraries?  I'm not set up to do that.  

--jkl