FreeTDS Development Group

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

Craig,

Ok, I was a little confused about when the unittests code was expecting
errors and when it was not.  Here's the story as it appears to me:

dbnextrow() must be called once more than the number of rows, so that you
get a NO_MORE_ROWS return code.

dbresults() does not work the same it can be called once time for 1
result set for instance.  I knew this, but somehow it never occurred to
me when I wrote it as I always write a while(dbresults()) {} loop in my
code.

So, I changed a few things. I ditched the pending flag in TDSRESULTINFO
and there is now a field called 'state' which can be TDS_PENDING,
TDS_COMPLETED, etc... tds_process_row_tokens() used to read up to the end
marker, but not process it. It now processes it and sets the flag.  !If!
tds_process_result_tokens() is called it checks the state and returns or
proceeds appropriately. Submitting a new query resets state.

Test 4 -> 7 now work (or at least report that they do). 8 fails, is it in
working condition? I didn't look too hard (It's getting late here), but I
wasn't sure if it's supposed to be working.

I'm thinking of maybe thursday or friday for the release. I think the
byte-order issues are ok (I'm running on PowerPC/AIX with no problems),
but autoconf is failing for Solaris.  So I'm hoping someone will send a
patch, but I'm not going to hold the release up for it. We can always put
out a 0.42.  

Oh, BTW I did get DBD::Sybase to compile and link (er whatever perl calls
it). some tests passed, some failed, but it's a step forward.

I'm cc'ing back to the list.

Brian

On Mon, 11 Jan 1999, Craig Spannring wrote:

> Brian Bruns writes:
> 
>  > Hmmm...from my recollection, the behaviour is correct on these. It 
> outputs
>  > a 'results pending' message and the program subsequently exits because of
>  > the failure. What is the behaviour under real dblib?
>