The single-record access I was doing was dynamic. That is, the where clause was dynamic based on the keys set. From my understanding, this required using a prepare statement, which requires a cursor. I do agree, though, that the steps required for that kind of single-record access was over the top.
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Charles Wilt
Sent: Wednesday, April 04, 2012 3:14 PM
To: RPG programming on the IBM i / System i
Subject: Re: File Encapsulation Quandary
I'm with Scott, the only reason to encapsulate a file is to encapsulate business logic with the file i/o... Your example is a
perfect example of this. Even the simplest logic can/should be
encapsulated...I once had a master file with an active/inactive flag.
There was code all over the place checking that flag. Then the business decided that to be (in?)active, not only did the flag have to be set but some other criteria needed to be met...
Would have loved to simply make a change to the ITEM_isActive() procedure instead of finding every line of code that had IF ITMACT = 'Y'
Having your own procedures that simply mimic RPG RLA operations is pointless...the only benefit it provides, being able to replace RPG RLA with SQL is usually a bad idea since SQL isn't conductive to record at a time operations (as you've found out). The other "benefit" often branded about, "when it comes time to implement a file change, having that file in one location...." is oftentimes broken as the data structures passed back and forth are tied the file. Besides, you can easily accomplish the goal of minimizing re-compiles by simply enforcing the rule that all file access is done through a logical with an explicit field list. Now you can add fields to your hearts content and not have to recompile anything.
Finally a word about your SQL example...using a cursor to fetch a single row, ie. CHAIN, is not the right way to do it. Instead, you
should be using a SELECT INTO. However, even SELECT INTO isn't going
to be quite as fast as CHAIN.
Remember my motto, if you're using a cursor, you probably shouldn't be. :) Yes, there are places where you have to use a cursor, loading a display subfile or printing a report...but otherwise look for a non cursor approach.
Charles
On Wed, Apr 4, 2012 at 3:29 PM, Kurt Anderson <kurt.anderson@xxxxxxxxxxxxxx> wrote:
First off, we don't encapsulate all of our files. Only the ones that have business logic directly associated with the file.
For example:
We have a file with records with effective dates associated with them. We also have some clients who apply grace periods to their effective dates (that we need to interpret and apply on the fly if a record wasn't found w/o the grace period). Without this service program, this file would be used in over a hundred programs. Instead of having every program that needs to use this file have to go through all the gyrations of looking for the effective record, it's all handled in the service program. I also call this service program a business unit. The service program is set up so all the caller has to do is code the statement "line = getEffectiveLine( date: otherinfo ); "
--
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.
midrange.com
