sybperl-l Archive

From: David C Worenklein <dcw at gcm dot com>
Subject: Re: Queries n rows at a time
Date: Jul 22 1998 7:48PM

>>>>> "Michael" == Michael Peppler  writes:
    Michael>  Simon Yaminian writes:
    >> The hangup is that when the query is put together in the dbcmd,
    >> the dbsqlexec call does not return until the query is completed
    >> and this may take a while. The catch is to break the dbsqlexec
    >> call for instance into a set of "current" and "next" exec calls
    >> so we can have a break in the processing time while also having
    >> some data to work with. Again put all query semantics
    >> aside. The idea may seem complicated but it is in really
    >> simple. The key is to maintain a reference point (by Sybperl)
    >> in the submitted query.
    Michael>  The if the query takes time to complete you should
    Michael> consider modifying it, or adding indexes. The time
    Michael> dbsqlexec() takes to return is not necessarily linked
    Michael> with the number of rows the query will ultimately return.

I just hit a similar problem.

Turns out that Sybase is trying for network efficiency in addition to
everything else.

I thought that saying "select ... where ..." would spit out rows as it 
comes to them.  Turns out that Sybase caches output until it has a
packetful of data and sends you that packet.  (I'm guessing this kind
of packet is different from an IP packet, but I'm not sure.)

I came across it where I was doing a table scan.  I'd set rowcount to
1 and it would come back right away.  I'd then set rowcount to 2 and
expect to get the first row right away and wait a while for the second 
row.  Not so - I had to wait for both rows.