Michael Peppler
Sybase Consulting
Sybase on Linux
Install Guide for Sybase on Linux
General Sybase Resources
General Perl Resources
BCP Tool
Bug Tracker
Mailing List Archive
Downloads Directory
Sybase on Linux FAQ
Sybperl FAQ
Michael Peppler's resume

sybperl-l Archive

Up    Prev    Next    

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.