Well, you are kind of stuck and kind of not...
The obvious answer is to abandon client-interactivity. In such a case getting more rows/more data means a server round-trip to fetch a new page with the additional info.
If you have a requirement to support browsers beyond IE this may be where things end. But if you are developing for an intranet or other "closed community" where you can dictate recent versions (say, 5.5+) of IE you have other options.
These can range all over the place. But it depends on what you are really trying to achieve, if you DHTML to manipulate data, you have to get the data to the browser in some manner.
If what you really have is a case where a request of the server returns a bunch of rows of data to be browsed by the user and you just want to "page" through the stuff dynamically, the easiest IE-way to do this is to have the server return the actual data as a CSV file. Then in your HTML you make use of the Tabular Data Control (TDC) and an IE feature called data-bound tables, which can have a page-size less than the full number of rows yet with a little DHTML you can give the users page-ahead, page-back buttons.
The TDC cannot post any changes back to the server though, it is only an info-display device.
Another alternative is RDS. RDS offers another IE data-binding Data Source Object (DSO) behaving something like the TDC, but potentially bi-directional (allowing updates) and with a more generalized object model - more like ADO objects. RDS is actually considered part of ADO.
RDS relies on special components installed server-side that it talks to, to make it look almost like your browser code has a connection to the database server itself. It actually
does but through proxy components running under IIS.
RDS is a big topic, and there are several serious security considerations to examine.
Then you have the newer XML options to look at. There are several XML components designed for client-side use, and most of them can fetch data from an ASP host, and several can even post updated data back where desired. Some of them expose an IE DSO interface, so once again they can be used for data binding in IE.
This is also another big topic.
Adding more than a little interactivity at the client side requires a
lot of work. You need to keep in mind that web browsers are really designed to display static information and handle simple forms in a request/response mode of operation. They were never intended to work like a desktop application.
You might be better off cutting back your client-side expectations and do more at the server, living with the clunky round-tripping that HTTP is all about. On a LAN this is less of a handicap than over slow dial connections, and you will be "walking a development road" that is well traveled (in terms of getting help, finding useful books, etc). It also makes it easier to support more browsers, since you are not requiring a lot of "smarts" at the client-side.
Here are a few links:
To go much beyond this you might try the ASP Forum.