Skip to Content.
Sympa Menu

freetds - Re: DBLIB function

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Brian Bruns" <camber AT ais.org>
  • To: freetds AT franklin.oit.unc.edu
  • Subject: Re: DBLIB function
  • Date: Mon, 8 Jul 2002 15:35:14 -0400


> > From: Brian Bruns [mailto:camber AT ais.org]
> > Sent: July 8, 2002 2:39 PM
> >
> > Looks like anything that sets DBPROCESS in a stateful way is
> > supposed to set the avail flag.
>
> Brian,
>
> I think your "implementation #2" conforms to what little the docs say, yes.
> And I agree with your assessment of the API. ;)
>
> Could you explain what's meant by "sets DBPROCESS in a stateful way"? In my
> mind, and maybe only there, the dbproc is almost always in a state. That
> is, it's rare in the life of a dblib program that the dbproc is available
> for a new query (or bcp load). Most of the time, the dblib calls you can
> make are very much circumscribed by what call was just made. From that
> point of view, I don't see how dbsqlexec is any more or less "stateful" than
> dbresults. But you and Sybase must have something in mind.
>

What I meant was something along the lines of what ODBC would call a
"sequence error", so while changing the error handler is stateful in that
it changes some behaviour, it is not a sequence problem to do so. Whereas
calling dbcmd() one place and then another leads to garbage. Same thing
if I screw up the binds while another thread is processing ;-) But calling
"dbsetnull()" on the other hand presents a behavioral problem but not one
of sequencing.

Er, I could have made my point clearer...but hopefully you get the drift.
If the call requires no further action but makes a state change it is
still available. If the call requires another call in sequence, then we
transition to unavailable.

dbuse() should not fall under here, but I believe that is an
implementation detail of how it is written. Case in point for the
piss-poor design of this call.

As far as I can tell the call(s) is almost useless. ;-)

> Knowing you, you'll probably have this all implemented by the time you read
> this.
>
Actually, I'm at work, otherwise... ;-)

Brian




Archive powered by MHonArc 2.6.24.

Top of Page