>>You have a user that is going to read through 150000 records? 1000000 records?
>>That is just poor design.
>
>No, it is not. The program alows the user to make all Select SQL he likes, and if he sees that it's taking too much time he can interrupt, and refine its select. That's why I need to get small chunks of data any time, and loop to get more.

Another approach would be to just initially return a COUNT( ) from any query the user specifies. If that value is too high, warn the user to be more specific. And/or warn the user if returning that value takes too long.

Returning just a COUNT( ) would minimize network traffic, if that's a bottleneck. It wouldn't help with the speed of the query on the server itself. OTOH any query that post-processes the resulting data set won't be faster than COUNT( ) and could be slower e.g. ORDER BY, GROUP BY, TOP nnn etc.

If you're trying to fetch nnn result rows at a time, it probably doesn't make a lot of sense unless you have some sort of ORDER in place.

If it turns out ORDER BY, GROUP BY etc. are expensive, maybe you could at first return a COUNT( ) with those clauses omitted from the query, which might be the fastest possible.