|
midrange.com
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.
Steve Raisor
----- Original Message -----
From: Rob Berendt <rob@dekko.com>
To: <RPG400-L@midrange.com>
Sent: Friday, February 25, 2000 3:27 PM
Subject: Re: Query/400 to RPG program
> And then again you'll be attacked by the PC package replacement. And
> instead of designing decent join logicals in the first place you'll have
> to go through jumps in the PC package to set up the links that basically
> emulate a decent join logical. As for me, I created a join logical like
> the following for query usage:
> * ADDLFM FILE(MGR1499SID/ZDATAW) MBR(ZDATAW)
> * DTAMBRS((SAFETYF/AUDIT (AUDIT))
> * (SAFETYF/AUDITINCID (AUDITINCID))
> * (MGR1499SID/LOCATION (LOCATION))
> * (MGR1499SID/EMPNAM (EMPNAM))
> * (SAFETYF/INCIDENT (INCIDENT))
> * (SAFETYF/STATUSES (STATUSES))
> * (MGR1499SID/EMPNAM (EMPNAM))
> * (MGR1499SID/COMPNAME (COMPNAME))
> * (SAFETYF/INCIDENTT (INCIDENTT))
> * (MGR1499SID/EMPNAM (EMPNAM))
> * (MGR1499SID/DIVISION (DIVISION))
> * (MGR1499SID/EMPNAM (EMPNAM)))
> * Modification log:
> * 06/11/97 by R.Berendt, CCP GDS, LLC
> * Added field TAKEACTION from INCIDENT. This field
> * is the 'Action to be taken'
> *
> JDFTVAL
> R ZDATAWR JFILE(AUDIT AUDITINCID +
> LOCATION EMPNAM INCIDENT +
> STATUSES EMPNAM COMPNAME +
> INCIDENTT EMPNAM DIVISION +
> EMPNAM)
> J JOIN(1 2)
> JFLD(AUDIT# AUDIT#)
> JDUPSEQ(SEQUENCE#)
> J JOIN(1 3)
> JFLD(LOC LOC)
> J JOIN(1 4)
> JFLD(AUDITOR# EMPLY)
> J JOIN(2 5)
> JFLD(INCIDENT# INCIDENT#)
> J JOIN(2 6)
> JFLD(STATUS STATUS)
> J JOIN(3 7)
> JFLD(MANAGR EMPLY)
> J JOIN(3 8)
> JFLD(ENTITY COMP)
> J JOIN(5 9)
> JFLD(INCIDENTYP INCIDENTYP)
> J JOIN(8 10)
> JFLD(MANAGR EMPLY)
> J JOIN(8 11)
> JFLD(DIV DIV)
> J JOIN(11 12)
> JFLD(MANAGR EMPLY)
> AUDIT# JREF(1)
> LOC JREF(1)
> LOCNAME JREF(3) RENAME(NAME)
> LOCMGR JREF(3) COLHDG('Location' +
> 'Manager') RENAME(MANAGR)
> LMNAME JREF(7) COLHDG('Location' +
> 'Manager') RENAME(NAME)
> ENTITY JREF(3)
> CMPMGR JREF(8) COLHDG('Company' +
> 'Manager') RENAME(MANAGR)
> CMNAME JREF(10) COLHDG('Company' +
> 'Manager') RENAME(NAME)
> DIV JREF(8)
> CMPNAME JREF(8) COLHDG('Company') +
> RENAME(DESC40)
> DIVNAME JREF(11) COLHDG('Division') +
> RENAME(DESC40)
> DVMGR JREF(11) COLHDG('Division' +
> 'Manager') RENAME(MANAGR)
> DVNAME JREF(12) COLHDG('Division' +
> 'Manager') RENAME(NAME)
> DATEAUDIT 8S 0 JREF(1) +
> EDTWRD(' / / ')
> DATAUDMM I SST(DATEAUDIT 5 2)
> DATAUDDD I SST(DATEAUDIT 7 2)
> DATAUDYY I SST(DATEAUDIT 3 2)
> AUDITOR# JREF(1) COLHDG('Auditor')
> AUDNAME JREF(4) COLHDG('Auditor') +
> RENAME(NAME)
> DATEREPORT 8S 0 JREF(1) +
> EDTWRD(' / / ')
> DATREPMM I SST(DATEREPORT 5 2)
> DATREPDD I SST(DATEREPORT 7 2)
> DATREPYY I SST(DATEREPORT 3 2)
> SEQUENCE# JREF(2)
> INCIDENT# JREF(2)
> INCIDENTYP JREF(5)
> INTYPDESC JREF(9)
> SHORTDESC JREF(5)
> REGULATION JREF(5)
> ACTION JREF(5)
> PENALTYAMT JREF(5)
> TAKEACTION JREF(5)
> STATUS JREF(2)
> STATUSDESC JREF(6)
> PRIORITY JREF(2)
> DATEDEADL 8S 0 JREF(2) +
> EDTWRD(' / / ')
> DATDEDMM I SST(DATEDEADL 5 2)
> DATDEDDD I SST(DATEDEADL 7 2)
> DATDEDYY I SST(DATEDEADL 3 2)
> DATECLOSE 8S 0 JREF(2) +
> EDTWRD(' / / ')
> DATCLOMM I SST(DATECLOSE 5 2)
> DATCLODD I SST(DATECLOSE 7 2)
> DATCLOYY I SST(DATECLOSE 3 2)
> COMMENTS JREF(2)
> DOCID10 JREF(2)
> K AUDIT#
>
>
>
>
>
>
>
> sraisor@earthlink.net on 02/25/2000 03:18:45 PM
> Please respond to RPG400-L@midrange.com@Internet
> To: RPG400-L@midrange.com@Internet
> cc:
> Fax to:
> Subject: Re: Query/400 to RPG program
>
> In my opinion, queries are fine for quick one time reports needed by the
end
> users. However, I don't think end users should become dependant on
queries
> for their day to day activities. Most end users don't understand the
> relationships between files that is needed to write "good" queries.
Quickly
> you start seeing queries indexing files for minutes on end, due to strange
> joins and sorts. Also, if they are dependant on a query and suddenly a
> problem develops with that query, who has to fix the problem in a hurry?
> Write programs in programs, don't try to write programs in query!!!
>
> Steve Raisor
>
> ----- Original Message -----
> From: Rob Berendt <rob@dekko.com>
> To: <RPG400-L@midrange.com>
> Sent: Friday, February 25, 2000 7:19 AM
> Subject: Re: Query/400 to RPG program
>
>
> > What is so bad about Query? Is this some sort of programmers union
> > uprising? 'The users are access their own data without going through
> > us! Wait, lets remove the easy maintainability of Query and put it into
> RPG!'
> >
> >
> >
> >
> >
> > danielh@elp.rr.com on 02/25/2000 02:23:59 AM
> > Please respond to RPG400-L@midrange.com@Internet
> > To: RPG400-L@midrange.com@Internet
> > cc:
> > Fax to:
> > Subject: Query/400 to RPG program
> >
> > I just started working with RPG. This company lives on querys! They run
> > around a 80 different ones a day. Is there a good tool that anyone would
> > suggest that would convert querys to code. we run 3.7.
> >
> > Thank you
> > Dan
+---
| 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 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.
