This is a multipart message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
We used to have end users be the trainers for the new systems people.

We had end users uploading stuff to the iSeries just to be able to run
Query/400 against it.

Definetly a good end user tool.

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/11/2002 03:03 PM
Please respond to midrange-l


        To:     "'midrange-l@midrange.com'" <midrange-l@midrange.com>
        cc:
        Fax to:
        Subject:        RE: SQL VS QUERY


Evan,
                 We can go back and for on this issue.  The answer to the
original
question is "depends".  It depends on how the need can be fulfilled.  I
like
SQL for querying and QUERY/400 for reporting.  I have used both and both
are
used in a product situation.  I do give it to end-users but only to a very
select few.

Thank you,
Matt Tyler
Mattt@wincofoods.com

-----Original Message-----
From: Evan Harris [mailto:spanner@ihug.co.nz]
Sent: Friday, October 11, 2002 13:32
To: midrange-l@midrange.com
Subject: RE: SQL VS QUERY

Hi Matt

you wrote

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

this is one of those statements I see from time to time that I like to
challenge :)

If someone wrote a query that outputs to a file with a production file
name
and replace member *yes specified they could certainly "kill" data.

Of course an adequate security scheme would prevent this but I'd hazard a
guess that this might be a vulnerability on just a few systems

regards
Evan Harris


>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

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


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.