However, there are some ways to speed things up.

In SLQRPG, NEVER select from logical files. SQL does not like logical files. See this article to find out why:

http://www.itjungle.com/fhg/fhg040908-story01.html

See THIS article to see how to make sure that your iSeries SQL will not use logical files :

http://www.itjungle.com/fhg/fhg041608-story01.html

In addition, coding multiple conditioned SQL SELECT statements in your program can also speed things up, because you can then use the SELECT statement that best fits the selections the user has made from your screen. So, for the cases where the user only fills in a single range, there is a SELECT just for that single range. But there must always be a SELECT for the worst-case, where multiple ranges and single values have been selected.

Now to ‘ordinary’ RPG processing. I am assuming here that all your ranges are on data held in the same physical file.

First, look at the logical files you have to play with. You can specify all those that allow you to select the ranges of data required in your F-specs, and of course they must have different record format names in the code.

(Create a D-spec externally-described data structure for the file. It will be filled in by any of the record formats when you do a read from any of the logicals, because they all have the same field names. You don’t really need it, but if your screen fields are based on a similar extrenally-described structure with a renamed prefix, then just one EVAL will move the data from the file into the structure for the screen, so saving some time.)

Have a subroutine which examines the user selections, and which will decide which logical file to use. So, if the user selects the range FAX REFERENCE NUMBER, your routine will decide to use the logical keyed on fax reference number . The object is to reduce the number of database reads. However, there may be issues regarding the order the user expects the data to be shown in the subfile.

Your subroutine will have set a multi-valued flag that will control a Select group to SETLL the selected logical using the FROM range value, and then in a read loop to control a Select group to Read the logical.

You READ the range for the key. Test the key value , and when it is greater than the TO range value leave the loop. If the user entered just one value (meaning ‘just this value’), then set the TO value = the FROM value.

Inside the loop, perform sub-selection, where the user has entered additional selection values not covered by the logical you used.

So, if the user entered a range of Fax Reference Numbers and a single Order Date, and you don’t have a logical based on order date, you will read the logical based on Fax Ref No for the range, and within the loop have:

Select
When ScreenOrderDateFrom = *Zero
When ScreenOrderDateTo = *Zero and
FileOrderDate <> ScreenOrderDateFrom
Iter
When FileOrderDate < ScreenOrderDateFrom or
FileOrderDate > ScreenOrderDateTo
Iter
EndSl

The Iter is the fastest way to loop round for the next record.

Of course, you’ll also have a Select group that covers the range your logical is keyed on, just because the read loop could be reading from any of the logicals; but this Select group will never make an Iter.

Another thing to look at is, how many records do you expect to find? If it’s a lot, then think about loading the subfile a page at a time, so the user gets one page as soon as it is filled, and the program only looks for the next page of data when the user pressed Roll Up (Page Down). Otherwise you may spend a lot of time loading a lot of records, and the user will get bored and make a cup of tea, spill it on his keyboard, and you will get the blame.

Regards,

Sloopy