× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Alan,

I'll admit I haven't run the benchmarks on any recent hardware or OS
level...maybe I'll dig some up and run them.

But the fact of the matter is a SQL SELECT INTO could only ever be as
fast as an RPG CHAIN....never faster...and it certainly wasn't even as
fast a few years ago. Perhaps that's changed.

Still, IMHO it's pointless to simply replace RPG RLA with SQL RLA....

Replacing RPG RLA with SQL set operations is another matter entirely.

Charles

On Wed, Apr 4, 2012 at 4:22 PM, Alan Campin <alan0307d@xxxxxxxxx> wrote:
"with SQL is usually a bad idea since SQL isn't conductive to
record at a time operations"

Based on my experience I believe this is a myth. We have hundreds of
programs doing single I/O operations using SQL and I have yet to see
any real problem. You might do a test and have a few milliseconds
slower but in a real world environment does that really matter?

On Wed, Apr 4, 2012 at 2:14 PM, Charles Wilt <charles.wilt@xxxxxxxxx> wrote:
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.

--
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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.