One Page at Time subfile and multiple record selection/deletion

[Filip Drzewiecki]

Hello,

I'm just thinking how to handle this properly and can't figure it out :/ (at least not in a clever way). Not sure if this should be posted in subfile directory.
Let's imagine this: I have an 100 pages subfile (one page at time). I can easily handle paging up and down but what I can't handle properly is for example selecting two record on first page (for processing) and then paging down few times and select another few records. When I page up, I should still see the records which I've selected at the beginning(which will be marked in RED as selected for further processing). After I've selected all records which I wanted to process, I can press some Function Key and start processing.

This would be really easy with self expanding subfile but then I'm limited by RRN. I don't think that user will scroll through 9998 record (approximately 769 pages) but I just would like to do One Page at Time.
What I thought is that when user will select "any" record on the first page and then try page down, I will put pageNumber and RRN (or ID or record from database) to array data structure and if user will page up to previous page where he selected something for processing, I will just look into array data structure to see if anything on this page was selected.

Again, this would be much simpler with self expanding subfile or maybe I'm just not clever enough.

[Vectorspace]

The problem with suing page number and rrn is what if, as you are paging up and down, records are added or deleted from the file? Then the page number/rrn relationship changes. If the table that is driving the subfile has a unique key, I would use that instead. I would probably also use an SQL table in QTEMP instead of an array DS.

The shop I first worked at (until 2016) was all green screen We had a standard subfile template that used a hybrid subfile - part page-at-a-time, and part self-expanding. The idea was this:

The subfile had a position to field for the primary key (like you get in a PDM view). Typing a value in here would reload the subfile, starting at that record, and only a single page. The unique key of the first and last records are stored. We also had filters on a number of subfile columns to let users return a more precise selection of records (more relevant records in less subfile pages)

If you page down, then new records are added to the subfile (starting with the record after the stored end-of-page key) - i.e. self-expanding. You are free to page up and down within the loaded records, and any selected fields would remain selected.

But if you tried to page up beyond the first page, then it would empty the subfile and load a new page (read x records back from the stored start-of-subfile key then write those) - it became page at a time. Any selections would be lost

We never had a problem with users complaining that selections were being lost because of excessive paging in either direction. They found it quicker and easier to work one record at a time (position to/filter for a specific record, select it, process it, repeat) than to page up/down through hundreds of pages to select each individual record to process in bulk. This may not apply to your situation for all I know, but it's worth considering.

[Scott Klement]

I agree with Vectorspace, you should not use the page number, that's not reliable.

Most applications using page-at-a-time subfiles that I've worked with will simply process the selections before loading the next page. For example, if you select to "change" two rows, and then hit page down, the "change" screen appears for each selected row immediately (when hitting page down, not waiting for enter to be pressed) and then the new page is loaded. That way it doesn't have to keep track of all selected entries.

I've also seen applications where processing the selected rows immediately wasn't possible (the application's requirements were that the processing HAD to be done all at once at the end). For these, information about the selected rows was kept in an array in the RPG program. It did not use the page or RRN, but instead, there'd be a "unique key" or similar type of identification for the record shown in that row that would be saved into the array. When each page was loaded, it would check to see if the key was in the array, and if so, would put the option the user selected onto the screen, so if the user paged forward, then back again, it would show the selections they had previously made. The array would not need to be as big as the possible subfile size since it only had to store the options the user selected. At the end, when the user hit enter, it would use the array to determine what was selected. The code to handle all of this properly can get fairly complex, which is why it's much less commonplace than just processing the selections immediately.

Finally... I wanted to mention that in your example, you said there were 100 pages of data. Even if you had a full 24 rows on the screen, that's only 2400 records, which is less than the 9999 limit, so would work just fine with a load all subfile. Probably 100 wasn't accurate in your initial description, and there are really far more rows than would fit... but, I wanted to mention this in case you didn't realize it. In my experience it's extraordinarily unusual for a user to page through more than 9999 rows. I've had applications where there were millions of records, but I only loaded 9999, and the user never noticed. You might want to conisder whether a page-at-a-time is really needed here.

[Rocky]

You can write a page at a time. When the user presses page down on the last page in the subfile read to see if they made any selections and change the attributes for those records, add the next page and display the subfile. You essentially build the subfile with all of the pertinent records but one page at a time.

[Whitecat27]

Greetings Filip!

According to your question, and the details involved, I believe that the solution is contained within the selection of records that get loaded into the subfile tha is the actually displayed to the user.

Vectorspace, Scott, and Rocky have all written excellent opinions on how to approach the basic question of "how can I show the user only the records they might need to change... while taking into account the subfile records displayed in a high activity file for update". Actually, that's not exactly what you asked, however, that is how I am approaching my answer. to your question,

As an example, I had a file that contained records for individual trucks from a third party "satellite tracking system" that went through each truck in the company fleet for each and every truck the company operated. These tracking records were (to say) added during the last 30 minutes... one record per truck over 24 hours, 7 days, for every freaking truck that was active at that moment in time. This file included the customer order number, driver number, record creation timestamp, type of report, and on and on and on, ad nauseum. Talk about Scott's reference to "millions of records"...

(Especially since Company Management never allowed us to be archiving anything in the "current file" earlier than 10 years ago into local "history" data files.)

So, now by "intelligent selection" (by the user) of subfile records I want to allow the user to update the subfile fields into the "current file" transaction record(s)... I accomplished it by letting the user be "smart enough to know what they want in their own selection process" for the displayed subfile.

There is no "any" option into the Load Subfile selection portion process... Of the few selection options available, there should no collective set of chosen options that could allow a user to select "a God-like, everything under the sun" set of records for the subfile. It is never a good idea to assume the users to be silly or stupid (even if they are trying to find selection options that provide anything other than valid selection data in this respect). Our users should at least understand and know the basic parameters of their search possibilities and what will result. God help you with that if you get it wrong..

So, after my rant here... the secret to the answer is to have a method where your subfile shows only records that relate to the singular update request you are wanting them to see.

Now.... it is also to be mentioned that if two users are looking for the "exact same set of records in their subfile"... the added logic of having "locked or unlocked" records may come into consideration here.


Best Regards,

Fred Williams