|
midrange.com
This is a multipart message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
I kind of disagree with you on not giving Query/400 to the users. If you
don't give them these tools to manipulate as they will then they will
insist the data be moved to their OS of choice where they can manipulate
it there. And the blame will be put on the iSeries and not on the control
trying to be exercised over the data.
Good point on creating views. Developers should create more views and/or
logical files to make ad hoc reporting easier for the users. Granted I
could have created a couple of queries to prepare reports, locked them
down, make them accessible only by driver programs. But instead I created
the following intense logical and said "go for it".
* 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#
Rob Berendt
--
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
Benjamin Franklin
"Tyler, Matt" <mattt@wincofoods.com>
Sent by: midrange-l-admin@midrange.com
10/10/2002 10:36 AM
Please respond to midrange-l
To: "'midrange-l@midrange.com'" <midrange-l@midrange.com>
cc:
Fax to:
Subject: RE: SQL VS QUERY
Steve,
It has been posted on this list about a query eating up a
system.
True, basic users cannot kill data using QUERY/400, but there is by
default
nothing to prevent them from chewing up all the remaining resources with a
bad selection condition set.
You still need SQL to create views in order to give ad-hoc report users
better reporting data in QUERY/400. You should not expect a user outside
of
IT to know which tables to join and how to join them.
Plus, since it comes with in the development package for the 400 why not
use
it.
IMO, QUERY/400 is not a tool to give to end-users without putting
restrictions on them via system parameters and objects.
Thank you,
Matt Tyler
Mattt@wincofoods.com
-----Original Message-----
From: Steve Landess [mailto:steve_landess@hotmail.com]
Sent: Thursday, October 10, 2002 09:20
To: midrange-l@midrange.com
Subject: Re: SQL VS QUERY
IMO, the SQL tools are for:
1) power users (who you trust to NOT use 'DELETE * from FILEXXX')
2) IT dept. users
3) required if using embedded SQL in your programs
Query is better for ad-hoc reporting, since the user interface allows
relatively unsophisticated users the ability to quickly create and format
reports.
If I were told that I could only have 1 tool, I'd probably choose Query.
If you have AS/400 query, you can create code a SQL statement in a source
member and use CRTQMQRY to compile it, then use STRQMQRY to run it, giving
the same results as you would get using interactive SQL, without the
syntax
checker.
Also, the CRTQMQRY & STRQMQRY commands can be secured to only authorized
users, so as to prevent a novice from hosing up the system.
HTH
----- Original Message -----
From: "Bob Carl" <bcarl@knapheide.com>
To: "Midrange Computing Technical NewsGroup for ISeries"
<midrange-l@midrange.com>
Sent: Thursday, October 10, 2002 10:08 AM
Subject: SQL VS QUERY
This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
My account is getting ready to purchase some sort of IBM ISeries Query
tool,
SQL tools, or both. I have been asked to provide justification for
investment in the SQL tool over or in addition to Query.
Can you use SQL in a CL in the same fashion as query, such as to create a
file(Like OPNQRYF). I would think you can. I am wondering if we can scrap
query all together in favor of SQL (RUNSQL). Right now we do not use SQL
for
anything but transferring data, such as in Excel or Client Access, but
considering its industry presence, it seems like a no-brainer. Please
submit to me your best arguments for using SQL, and if it can replace
Query
completely and easily.
Thanks in advance.
Bob Carl, Senior Systems Analyst
Knapheide Manufacturing Company
217-223-1848 Ext. 2397
Fax: 217-223-1947
--
_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
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.
