freetds AT lists.ibiblio.org
Subject: FreeTDS Development Group
List archive
- From: "Lowden, James K" <LowdenJK AT bernstein.com>
- To: "'TDS Development Group'" <freetds AT franklin.metalab.unc.edu>
- Subject: RE: coding advice, please...
- Date: Tue, 24 Sep 2002 12:01:51 -0400
> From: Bill Thompson [mailto:thompbil AT exchange.uk.ml.com]
> Sent: September 24, 2002 9:52 AM
> dbnextrow() needs in turn to return either:
>
> REG_ROW (a normal data row has been returned)
> NO_MORE_ROWS (there ain't no more data...)
> FAIL
> BUF_FULL
> a "compute id" (to tie back this compute data to its "result"
> information)
>
> as dbnextrow() is a thinnish wrapper around
> tds_process_row_tokens(), the
> latter needs to pass similar information back to the former.
>
> As I see it I could either:
>
> keep the existing returns from tds_process_row_tokens()
> (SUCCEED or FAIL essentially), and add extra output
> parameters for returning extra information.
>
> or:
>
> amend the return codes from tds_process_row_tokens() to
> roughly match the dbnextrow() returns.
Bill,
Since you asked , I'll agree with Steve, since he's so agreeable.
The simple fact is, as I see it, that tds_process_row_tokens() has more to
say than yea/nae, so it should say it. Making libtds better is good.
Omelettes and eggs and all that.
While I don't advocate gratuitous changes to libtds, neither should we let
the tail wag the dog. It's there for us, to help us create the client APIs,
and anything we do to it toward that end will benefit many people, 1000
times more (I mean that literally) people than those inconvenienced. We can
make it work now and make excuses later. :)
BTW, I think your compute-row handling may overlap with Frediano's output
parameter handling. Cf. dbretdata(). I don't know what you'll find on the
wire; I'm speculating.
--jkl
The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above. If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that for certain accounts we do not accept
orders and/or instructions by e-mail, and for those accounts we will not be
responsible for carrying out such orders and/or instructions. Kindly refrain
from sending orders or instructions by e-mail unless you have confirmed that
we accept such communications for your account. Please also note that to
satisfy regulatory requirements we review the outgoing and incoming e-mail
correspondence of staff members serving certain functions.
-
coding advice, please...,
Bill Thompson, 09/24/2002
- <Possible follow-up(s)>
- Re: coding advice, please..., Steve Langasek, 09/24/2002
- Re: coding advice, please..., Bill Thompson, 09/24/2002
- Re: coding advice, please..., stephen . hsu, 09/24/2002
- Re: coding advice, please..., Castellano, Nicholas, 09/24/2002
- Re: coding advice, please..., Chad Enney, 09/24/2002
- RE: coding advice, please..., Lowden, James K, 09/24/2002
- RE: coding advice, please..., Bill Thompson, 09/24/2002
- RE: coding advice, please..., Brian Bruns, 09/24/2002
- RE: coding advice, please..., Thompson, Bill D (London), 09/24/2002
Archive powered by MHonArc 2.6.24.