Re: Best approach for Embedded SQL SELECT in V7R1 -- RPG400-L

When I select multiple rows I generally define my SQL DS as an occurs with enough elements to fill one page of the subfile.

On Nov 6, 2012, at 11:53 AM, "Briggs, Trevor (TBriggs2)" <TBriggs2@xxxxxxxxxxx> wrote:

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

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing
list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

************************************************************************************************************************************************************************************************************
This message originates from Lincare Holdings Inc. It contains information which may be confidential or privileged and is intended only for the individual or entity named above.
It is prohibited for anyone else to disclose, copy, distribute or use the contents of this message.
All personal messages express views solely of the sender, which are not to be attributed to Lincare Holdings Inc., and may not be copied or distributed without this disclaimer.
If you received this message in error, please notify us immediately at MailAdmin@xxxxxxxxxxx or (800) 284-2006.
************************************************************************************************************************************************************************************************************

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.