FreeTDS Development Group

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

> From: Kass, Sharon [mailto:Sharon.Kass AT gs.com]
> Sent: December 1, 2003 4:45 PM
> 
> Maybe I'm not processing properly.  
> Some of my handles look like this:
> 
>         my $sth=$db_cms_shadow->prepare("
>                 SELECT * FROM gs_location WHERE
> LOC_ID='$locationId$locationType'
>                 ");
>         $sth->execute();
>         my @row=$sth->fetchrow_array();
> 
> Is this considered complete processing?

Not in the TDS sense, no.  If the query returns results, you must read all
the rows before issuing the next query.  According to the DBI man page, @row
will be empty when you attempt to read past the last row.  So you need
something along the lines of:

        $sth->execute();
        my @row;
        do { 
                @row=$sth->fetchrow_array();
                last unless @row;
                # process row
        } while (@row);
        # check $sth->err ...

It may be that once upon a time your query would have returned just one row,
and DBD::Sybase (and/or) FreeTDS tolerated reading *only* that row, even
though you're supposed to try to read N+1 rows.  

I think what may be happening is that DBD::Sybase is continually forming new
connections and cancelling outstanding results for you.  Perhaps there's an
internal (even unintentional) limitation to how many times it can do that
correctly.  Or perhaps that logic trips on ye olde empty rowset bug.  See,
we also offer free speculation.  ;-)

> Since AutoCommit is set to 1 I assume that the processing is nearly
> immediately. I also tried putting sleeps in there (yea I was sorta
> grasping)...

It's not a matter of wall-clock timing or a race condition.  It's a matter
of the client processing everything the server sends, before issuing the
next query.  

FreeTDS maintains an internal flag marking whether or not all the results
have been read (to avoid a server protocol error).  A typical C application,
trying to send a query before its time, would get a "pending results" error
from the library, based on that flag.  DBD::Sybase is trying to Mr. Nice
Guy, letting you go ahead with Query B before you're done with Query A
(which most DBI backends don't object to); it traps that "pending results"
error and issues your query for you on a new connection.  While I think
that's a fine thing for him to do, I can't recommend you abuse the
privilege.  :-)

HTH.  

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