FreeTDS Development Group

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

> From: Bill Stewart [mailto:bstewart AT verio.net]
> Sent: April 4, 2003 11:00 AM
> 
> I hope this is an appropriate type of thing to pose to this 
> list. If not please excuse me.

Entirely appropriate, Bill.  Welcome.  

> The company I work for is interested in using freetds on our 
> servers. We 
> have a fairly sizable existing Perl code base that uses dbmorecmds in 
> Sybperl. Apparently this function has not yet been implemented in 
> Freetds. All other aspects of Freetds seem to work very well.

dbmorecmds() looks feasible but not trivial.  If I understand it, it could
be implemented as a wrapper around dbresults().  There are some pitfalls,
though.  

Basic result processing looks like this:

        while (dbresults == SUCCEED) {
                do {
                        dbnextrow
                } while REG_ROW  
        }

IOW, when dbnexrow() returns NO_MORE_ROWS, call dbresults() again.  It
returns SUCCEED if there's another result set in the pipe, else
NO_MORE_RESULTS.  

It looks like dbmorecmds() would be inserted something like this:

        while (dbresults == SUCCEED) {
                do {
                        dbnextrow
                } while REG_ROW 

                if (NO_MORE_ROWS) {
                        if (dbmorecmds == FAIL)
                                break;
                }
        }

The trick, from db-lib's point of view, is to learn what dbresults() learns
-- which requires reading the stream -- without doing (or seeming to do)
what dbresults() does.  Unfortunately, it's impossible to do that without
reading the stream, so it's necessary to do at least some of what
dbresults() does, and to update the DBPROCESS accordingly.  

Looking at src/dblib/dblib.c::dbresults_r(), the only thing I can see to do
is have dbmorecmds() actually call dbresults(), interpret its return code
and return SUCCEED or FAIL.  In addition, it would mark the DBPROCESS with a
flag "we did this once already"; when dbresults() is next called, it clears
the flag and "re-returns" the same thing it did before.  

The pitfall to that approach is that *erroneous* use might oddly exhibit
working behavior: you could skip the subsquent call to dbresults(),
proceeding directly to dbnextrow() and no one would be the wiser.  Unless we
added logic to dbnextrow() (and any other logical successor to dbresults())
looking for the uncleared "did this already" flag.  

That's my analysis.  If it's wrong, I hope someone will correct me.  If
somebody wants to jump in and do it, that's great.  I'm focused on UTF-8
handling right now, and wouldn't expect to be able to get to this until
that's working satisfactorily. 

Regards, 

--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 we do not accept account orders and/or
instructions by e-mail, and therefore will not be responsible for carrying
out such orders and/or instructions.