FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

> From: Bill Thompson [mailto:thompbil AT exchange.uk.ml.com]
> Sent: July 8, 2002 12:35 PM
> 
> Seriously, if we need this we'll also need dbsetavail(). 
> It looks to me like these two functions support a 
> programmatic method of
> managing concurrent use of a dbprocess (rather than saying anything
> intrinsic about what is actually happening with the 
> connection, such as a
> query having results pending). is that your reading of it ? 

I modified my "dbsql" utility to:

*       display the results of dbisavail() after each dblib call
*       if it returns FALSE, call dbsetavail(). 

Here's what happened on an NT platform with MS's dblib:

$ echo select 1 union select 2 |dbsql -U LowdenJK -P %P% -S spquant -d
testdb
dbisavail = 1 after dbopen
dbisavail = 0 after dbuse
select 1 union select 2
dbisavail = 0 after dbcmd
dbisavail = 0 after dbsqlexec
dbisavail = 1 after dbresults
1 columns returned.
dbisavail = 1 after dbnextrow
dbisavail = 1 after dbcolname
dbisavail = 1 after dbdata
                column_name:
                column_type:    56
                column_size:    4
                length:         4
                data (first word):      0x2
dbisavail = 1 after dbcoltype, dbcollen, dbdatlen
dbisavail = 1 after dbnextrow
dbisavail = 1 after dbcolname
dbisavail = 1 after dbdata
                column_name:
                column_type:    56
                column_size:    4
                length:         4
                data (first word):      0x1
dbisavail = 1 after dbcoltype, dbcollen, dbdatlen
dbisavail = 1 after dbnextrow == NO_MORE_ROWS
dbisavail = 1 after dbresults == NO_MORE_RESULTS

It looks like the dbproc is automatically "unavailable" between selecting a
database and preparing the query for processing.  

Note well, it's of NO USE in coordinating threading without dbsetavail()
(because no dblib call implicitly sets the dbproc to "available").  In any
case dbisavail() possesses only rudimentary intelligence about the
"availability" of the process:  In what sense is a dbproc "available" after
calling dbresults()?   If results are pending, a severe error will occur
unless they are either fetched or cancelled.  

To implement this nonquickly, we need to add a member to DBPROCESS; its role
is similar to user_data, except that occasionally dblib will reset it.  

(Anagh, if I were you, I'd consider adding a stub implementation of
dbisvail() in you application that always returns TRUE.  Given the
braindeadness of the function, that might do.  Or, implement both in terms
of dbsetuserdata() and dbgetuserdata(), which we do support.)

Best regards, 

--jkl