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


  • Subject: Re: Query/400 to RPG program
  • From: "Steve Raisor" <sraisor@xxxxxxxxxxxxx>
  • Date: Mon, 28 Feb 2000 12:41:34 -0500

Dave,

        I do understand what you are saying, and I agree some joins are
fine.  We've just found it's easier to say no joins, that way the programmer
doesn't have to decide whether the join they are about to make meets the
criteria that you are describing.  To me, it also makes file changes more
difficult.  For example, if your order file has a join logical with the
customer file, and for the sake of argument a large amount of programs use
that logical because it's key structure is what they needed.  Lets say only
half of the programs using the join logical use fields from the customer
master.  Then, a database change comes along for the customer file.  Now you
must recompile all the programs that are over that join not just the ones
that accessing the customer information.  That's a simple example, what if
the customer file is joined into 20 files on the system.  Suddenly, the
database change to the customer file just got to be much more difficult that
it might have been.

Steve Raisor

----- Original Message -----
From: Shaw, David <dshaw@spartan.com>
To: <RPG400-L@midrange.com>
Sent: Monday, February 28, 2000 10:24 AM
Subject: RE: Query/400 to RPG program


> Steve,
>
> You do realize, of course, that this only applies if the join needs an
index
> which doesn't already exist?  For example, if you join an order header
file to
> an order detail file by order number, and if the first field in one or
more
> indexes of the detail file is order number (which should almost certainly
be the
> case), then the join will share the already-existing index and not create
a new
> one.  Sharing an existing index should be the case in most parent-child
joins,
> so most of these shouldn't add any overhead at file maintenance time, and
will
> slightly reduce overhead at join usage time.  Many programmers have the
notion
> that a join logical uses a different kind of index than a normal file, but
this
> isn't the case - it actually uses the same kind of index that RPG would
need for
> CHAIN/READE, which more than likely is in the database anyway.
>
> Dave Shaw
> Spartan International, Inc.
> Spartanburg, SC
>
> > -----Original Message-----
> > From: Steve Raisor [mailto:sraisor@earthlink.net]
> >
> > At our shop, we don't use joins.  In my opinion, that just hides the
> > indexing that goes on behind the scenes and causes a  load on
> > the processor
> > for each record that is added to the database.  Instead of
> > indexing the file
> > once for each query that is ran, your join is having to index
> > each record
> > that is added into your physicals to keep the join logical up to date.
> > Depending on whether your files are updated often and the
> > number of queries
> > run, this could actually make performance worse overall.
> +---
> | This is the RPG/400 Mailing List!
> | To submit a new message, send your mail to RPG400-L@midrange.com.
> | To subscribe to this list send email to RPG400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
david@midrange.com
> +---
>

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.