FreeTDS Development Group

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

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