I'm aware of this clause in ASA... but we're not using ASA, we're using
ASE, which doesn't have that SQL extention available.

As indicated in my initial post, we considered temp tables and adding
an identity column, but there are a couple problems with that; one of
them being that often, an existing identity column is part of the
result set, and you can't put two identity columns on the same table.
We can't use those identity columns to achieve what we want because
they're full of gaps, and the sorting we put on the results will place
them out of order anyway. Most of these queries have joins as well,
also eliminating the possibility of using the identity key of a single
table.

The general idea was to encapsulate existing queries into some sort of
function or other mechanism so that all those queries didn't have to be
modified.. We've come up with a temporary solution that works:

query into #temp table
set rowcount <starting row - 1>
delete from #temp table
set rowcount <number of desired rows>
query from #temp table

This does force us to reload the entire result set whenever we want to
do a new query, however if we determine this to be an acceptable
permanent fix, if we keep track of where we are, we can use the
existing still-remaining data to query from, as long as we're going
forward. going backward we would of course need to rebuild the result
set. This would depend on where our transactional boundaries lie
however...

I would say the maximum number of rows being returned for a given
result set to be normally no more than 10,000. This is low enough to
be easily implemented as an application solution, but in this case
we're more concerned about network bandwidth usage than we are the
additional database server I/O, among other issues.

Thanks for your replies guys... this is a very valuable resource.