FreeTDS Development Group

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

On Wed, 26 Jan 2000, Geoff Winkless wrote:

> Ok, so I set up CVS on my development machine...
> 
> read.c:
> 
>       /* FIX ME -- get the exact err num and text */
>       tds_client_msg(tds,10018, 9, 0, 0, "The connection was closed");
> 
> Hmm.
> 
> 10018 was the message number I got from ISQL/w when I disconnected the
> server...
Ok, I wasn't sure of this one, so I wanted to try it against Sybase dblib
and see...mostly just a note to self kinda thing.

> 
> I note that you removed the extern for tds_client_msg.
I moved the prototype to the header file...that way we don't have to add
it to each file that needs it. I dropped the extern on the function
declaration on accident, my bad.

> 
> Nothing in tds_process_result_tokens also - did you figure out a different
> way to do this? As far as I could tell if you set tds->s to 0 as is,
> tds_get_byte just returns 0, which gets treated as a marker (and you get the
> dreaded "Unknown marker: 0" message in a loop...)
>
I moved this stuff to tds_process_default_tokens() (which is called from
tds_process_result_tokens() if he doesn't recognize the marker).  This 
is a little better since it'll work not only for ...results_tokens() but
also all the other process functions without dupping the code. This was
the part I was unsure of getting the behaviour right.

> In dblib...
> 
> In dblib.c, dbresults_r() -- you're checking for dbproc->tds_socket->s in
> hard code -- would it not be better to have a layer of abstraction and call
> DBDEAD()?
This is something that was done prior to receiving your patch, but you are
probably right. Although I'd like to see a macro in the TDS layer so both
dblib, ctlib and ODBC can take advantage of it.

> 
> Also the same in dbwritetext().
> 
> I'm also a bit dubious as to whether you should check for the
> connection -after- calling tds_process_result_tokens rather than before --
> since tds_process_result_tokens may change the state of the connection and
> return failure (which could then probably be (incorrectly) interpreted as
> NO_MORE_RESULTS?).
Technically, I suppose it should check after each and every read, but boy
that makes the code ugly. :-)

> 
> Thoughts appreciated
> 
> Geoff
> 
>