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