How build a grid to get away from the 9999 record limit on a subfile

[charles.wilt]

I understand that I can build a database driven grid that's not limited to 9999 records like a subfile driven grid would be.

However, how can I had a "Option" field supporting multiple options to such a grid?

I've not been able to find any such examples.

scenario: existing load all subfile program starts hitting the 9999 limit. We could change it to a page at a time, but we'd lose the scroll bar. Wondering if we can change it to use a DB driven grid instead.

Thanks!

[Scott Klement]

The biggest problem with a grid that has more than 9999 rows is performance... if all of these rows are loaded up front, this can take a lot of time, especially on a slower network link.

The database-driven grid is really a page-at-a-time grid. We run your SQL statement with SELECT COUNT(*) FROM (statement) to get the total number of rows, first... and then set up the scrollbar for that many rows. Each time you scroll, it connects to the IBM i and requests the next page of data, so only one page is transferred at a time. That is why you can't see the rows while you're scrolling through them, because it doesn't load the new page of rows until you stop scrolling.

Database-driven grids are not input-capable since there is nowhere to send the input. The RPG program doesn't know that it's a subfile, so doing READ/CHAIN/READC on the subfile isn't possible for database-driven grids. If you inserted input elements (which is possible using HTML or JavaScript) you would need to write your own code to send it back to the server.

It's very unusual for an application to need to load 9999 rows, since users typically will never scroll through that much data. For comparison, if you do a Google Search, no matter how many hits Google finds, it'll never return more than 1000 of them. Almost nobody knows this, since no user ever scrolls through 1000 results! And you're talking about 10 times that many...

Personally, I would take a hard look at this. Do you really need that many results, or can you subset it? If you really need that many results, I would use a page-at-a-time subfile.

[charles.wilt]

Thanks Scott!

I was thinking that might be the case, but wanted to confirm.

Yeah, 10000 is a lot. Unfortunately, in this case the screen is used to review records to be imported. So the users do scroll through (theoretically anyways ;)

We'll probably end up changing it to a page at a time subfile....unless I can convince product that the process needs to be reconsidered.

Thanks again!