Skip to Content.
Sympa Menu

freetds - Re: Patches

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Brian Bruns <camber AT umcc.ais.org>
  • To: TDS Development Group <freetds AT franklin.oit.unc.edu>
  • Subject: Re: Patches
  • Date: Wed, 26 Jan 2000 08:14:40 -0500 (EST)




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
>
>




  • Re: Patches, Geoff Winkless, 01/26/2000
    • <Possible follow-up(s)>
    • Re: Patches, Brian Bruns, 01/26/2000
    • Re: Patches, Craig Jackson, 01/26/2000

Archive powered by MHonArc 2.6.24.

Top of Page