FreeTDS Development Group

["Kass, Sharon" <Sharon.Kass AT gs.com>]

Thank you. This sounds on-track.

I am doing the select and not processing all of the rows because I only want
to know that row(s) do exist for the given condition. Perhaps there is a
better query for me to use. If not then I will fetchrow_array() all the rows
and see if that fixes the problem. 

(Adding finish() to the end of the query helped the problem somewhat but
hopefully fetching all the rows will be the solution although with a
performance overhead for doing all that processing (actually not a big
deal... most of my result sets will only have 1 row to process.))

Gett'n there!
I thank you!
Sharon

-----Original Message-----
From: Lowden, James K [mailto:LowdenJK AT bernstein.com] 
Sent: Monday, December 01, 2003 5:56 PM
To: 'FreeTDS Development Group'
Subject: RE: [freetds] dropped connection, I think


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


_______________________________________________
FreeTDS mailing list
FreeTDS AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds