|
midrange.com
Another Alternative:
For those customers who have Windoze PCs with MS-Office,
if you install MS-Query or Access on the end users PCs, you can
give them ODBC access to selected database files on the AS/400,
and they can easily use MS-Query or Access to perform queries
or create their own reports.
And, usually, this is software your company already licenses, so
you don't have to buy anything extra.
Of course, you would use OS/400 security to ensure that these
end-users can "read" but not "update or delete" the data contained
in these selected database files. :-)
Just my two cents worth... :-)
Regards,
Mark S. Waterbury
----- Original Message -----
From: <rob@dekko.com>
To: <midrange-l@midrange.com>
Sent: Thursday, October 10, 2002 12:10 PM
Subject: RE: SQL VS QUERY
> 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.
>
>
>
> _______________________________________________
> 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.
