× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Luis

You can do any of the query option joins in QM - you just have to change the SELECT yourself, because the RTVQMQRY brings everything in as option 1 joins. Same with running a QRYDFN using STRQMQRY.

This limitation is documented in the Query Management manual and is flagged when you use RTVQMQRY or ANZQMQRY.

There are some things like detail and summary things - summary only, e.g. - that seem less easy with QM - I don't do those much, and maybe there'd be a need to modify the SELECT statement again.

As to blocking QM queries, I can see sense in that, as that is a tremendously powerful interface to the database, once people find out about it. But if a shop is to replace QRYDFNs with QMQRYs/QMFORMs, I'd say they might want to limit who can CRTQMQRY.

Vern

On 7/21/2010 8:40 AM, Luis Rodriguez wrote:
Vern,

Although I do agree that QM is an excellent choice for many kinds of
reports, there are some things that can't be done (AFAIK) without sometimes
of workaround, mainly doing exception joins (QRY option 3) or Left Outer
Joins (QRY option 2). Also, there is the fact that, for reasons unknown to
me, I have found some shops that block their users's QM use and allow them
only access to WRKQRY.

Regards,

Luis Rodriguez
IBM Certified Systems Expert — eServer i5 iSeries
--



On Wed, Jul 21, 2010 at 8:53 AM, Vern Hamberg<vhamberg@xxxxxxxxxxx> wrote:

The&FIELD works in a QMFORM - those give you much more power, since you
have the full range of SQL available to you. You can convert QRYDFNs to
QMQRYs and QMFORMs easily, then go from there. You can even have
substitution variables. STRQMQRY replaces RUNQRY.

Having said that, there are many similarities between the 2 types of
query and presentation - I'd think the same thing works in Query but
don't know for sure.

HTH
Vern

On 7/21/2010 7:04 AM, Peter_Vidal@xxxxxxxx wrote:
"You can use&FIELD, where FIELD is the field name from a file. I would
imagine that it would also work on a derived field. I think that it must
be specified in upper case, but it's been a while since I've used that
feature, so I'm not 100% sure.
-mark"

Hi Mark!

I tried both ways (a field from a file and a work field), always in
uppercase, and it does not work like that. Looks like this&FIELD is
simply treated as a constant value and is not interpreting it as a field
value. You will have the title "&FIELD" included in your page headings
and or footings, that is all .

Can you give us an example of how you do it?


PETER VIDAL
PALL CORPORATION
SR System Analyst | WH Application Development
10540 Ridge Rd., Suite 203, New Port Richey, FL 34654-5111
727-815-3104 | Fax: 727-815-3120 | www.pall.com

"Imagination is more important than knowledge"
Albert Einstein (1879 - 1955)

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
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-Ups:
Replies:

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.