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