Fair point - probably better for looking at less dynamic data. Reading
into an array hits the issue of having to know how many records you'll
need to cater for. Also there's the issue of reading all of a 20,000
record file (say) into an array but the user finds the record they're
looking for on the first page of the subfile. That's a lot of wasted
I/O.
Trevor Briggs
Analyst/Programmer
Lincare, Inc.
(727) 431-1246
TBriggs2@xxxxxxxxxxx
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Jon Paris
Sent: Tuesday, November 06, 2012 11:38 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Best approach for Embedded SQL SELECT in V7R1
On 2012-11-06, at 11:08 AM, rpg400-l-request@xxxxxxxxxxxx wrote:
One nice thing about using SQL to build subfiles is that you can do
some
fancy alternate sorting by manipulating the ORDER BY clause. Done
right,
this can give the user the ability to sort ascending or descending by
any column in the subfile.
Just a comment on this. I always find that this method confuses users.
When you are looking at data and you request a sort on the subfile, the
data you expect to get back is a reordered version of what you just saw.
But with this approach the data being retrieved may not match due to
updates in the interval. Not uncommon in a system with a lot of
transactions. I've seen users puzzle over a screen for a long time
trying to find an item they thought they'd seen in a different sequence.
I load most subfiles into an array when they fit (and a user space when
they don't) and that way I can sort the same data over and over. User
has an option to refresh when they want.
Just a thought.
Jon Paris
www.partner400.com
www.SystemiDeveloper.com
midrange.com
