Rob,
I actually use the outfile from query for many various system maintenance functions.
AJS scheduled jobs, call CLP, which reads the query outfile, then performs a system maintenance function.
I'm assuming this could also be done with SQL.
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Thursday, September 25, 2014 9:42 AM
To: Midrange Systems Technical Discussion
Subject: RE: 57nnQU1
Paul,
Actually the whole joining files and outputting the results to an output file is one of the main reasons I stopped using WRKQRY. There were too many occasions that I couldn't do correlated queries that forced me to use the output file thing and then requery that which really encouraged me to go to sql instead for everything.
And I can understand simplifying data for users. But I feel that should be resolved with better views that combine, sanitize, rename confusing columns, do math or use functions, etc. And have the users query the views instead.
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
From: "Steinmetz, Paul" <PSteinmetz@xxxxxxxxxx>
To: "'Midrange Systems Technical Discussion'"
<midrange-l@xxxxxxxxxxxx>
Date: 09/25/2014 09:10 AM
Subject: RE: 57nnQU1
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
I use both, each has their own advantages.
Use query to join files, output results to an outfile.
Haven't ever done this with SQL.
SQL search, replace, and update capabilities are superb. Can't really do
this with query.
SQL index engine out performs the query index engine.
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
rob@xxxxxxxxx
Sent: Thursday, September 25, 2014 9:00 AM
To: Midrange Systems Technical Discussion
Subject: Re: 57nnQU1
I've not tried the formatting in years. Just tried it now. Actually it
doesn't look too bad. But honestly, I don't generate a lot of reports for
end users so the stuff I can get from STRSQL versus either STRQM or WRKQRY
works for most of my tastes.
I think my earlier bias came from looking at the source of a form.
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail
to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
From: Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 09/25/2014 08:43 AM
Subject: Re: 57nnQU1
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
Rob
I'm curious about something in this post - column formatting - I
actually like what I can do (like wrapping within the column) in STRQM
for this - can you say a little more to compare and contrast the 2
products as to column formatting? As you undoubtedly know, F13 toggles
between the query and the form, the latter being where the formatting
goes.
Thanks
Vern
On 9/25/2014 6:45 AM, rob@xxxxxxxxx wrote:
Are the users using STRSQL?
Do they prefer the selection and prompting of WRKQRY?
Have they tried STRQM as an alternative? (If you have STRSQL you have
STRQM.)
Have they tried STRQM but miss the ease of column formatting with
WRKQRY?
Do you have RUNQRY buried into any of your code? Do your vendors
require
QU1 be installed because they may have that imbedded?
:-) Are you still running V4 or earlier and have QU1 doing document
merge
with OV/400?
Is it worth the savings of dropping QU1 and missing all of this?
I liked the column formatting of QU1 over STRQM. However I forced
myself
to stick with STRSQL. The benefit of that was that if I ran into
something that was outside the realm of QU1's 'result fields' I didn't
avoid using that function because it wasn't worth the pain of
converting.
And, yes, I know the commands to convert a QU1 query into SQL. I've
written an article on this.
Rob Berendt
midrange.com
