RE: SQL VS QUERY

Steve,
        (one bird, many stones).  We are both correct it looks like.
        Now is the time to put this to rest.  :-)

Thank you,
Matt Tyler
Mattt@wincofoods.com

-----Original Message-----
From: Steve Landess [mailto:steve_landess@hotmail.com]
Sent: Thursday, October 10, 2002 10:14
To: midrange-l@midrange.com
Subject: Re: SQL VS QUERY

I'm NOT saying that I favor Query over SQL, and I'm not trying to start a
big argument.

Now having said that,  I was just saying that if I could ONLY have 1 tool, I
would probably choose Query/400.  It is better suited for the end-user of
the system than giving them SQL. Also, depending on the processor group, SQL
used to be a very pricy option.  If it is included in the development tools
in V5R1 and up, then this is a non-issue.

I may be wrong (and often I am, but I never say that to my wife), but:

1) I agree that a user can fill up the system with Query/400, but can you
not do the same thing with SQL?  I probably should have said that you should
give only power users access to Query/400 as well as SQL, as well as
guidelines for using these tools...

2) Can't you create LF's over the necessary fields to optimize the
processing of data with query?  I thought that DB2/400 was smart enough to
determine which existing access path it can use instead of building new
ones.

3) You can also limit the RUNQRY command to batch if necessary to prevent
long-running queries from eating up all interactive capacity, and by using
the QQUPRFOPTS data area you can control other aspects of Query/400.


----- Original Message -----
From: "Tyler, Matt" <mattt@wincofoods.com>
To: <midrange-l@midrange.com>
Sent: Thursday, October 10, 2002 10:36 AM
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.