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



Well, not a question of better. PRTFs and QMQRYs are completely different animals. PRTFs give you more control over what you see in a report. QMQRYs by themselves give you a default layout in columns. If you want formatting, you need to couple a QMQRY with a QMFORM. QMQRYs and QMFORMs together give you what QRYDFNs do by themselves - get the data and present it on screen or in a report.

You cannot use a QMQRY as you would a PRTF in RPG - it is not a file that can be named in an F-spec. It is executed using the STRQMQRY command, where you can optionally name the QMFORM used for presentation. And this is a CL command, so it is not intended for use in RPG - yes, you CAN use QCMDEXC, but that's not what it's for, for the most part.

As I posted, source record length is irrelevant - long constants and captions, etc., get wrapped properly in the keywords columns.

There has never been a point to VARCHARs in PRTFs. You handle them by reading the physical file with the varchar in RPG, then writing out to the PRTF after moving the data to a report field. You know this, I think.

As to header/detail reports, it might be possible with QMQRYs - I've never done it, and I use these things all the time. And promote them all the time. Consider first that a QMQRY is a single SELECT statement - essentially a single file in RPG terms. you'd need to use a JOIN to get header and detail information together. No such thing as reading the header file, then getting matching detail records. I'd say regular RPG file processing is probably more efficient that joining in a SELECT statement. Can't prove that, however.

Now it is possible to use level breaks in a QMFORM. And you can have break level text. You can have a header for each break, specify that it does not start on a new page, and that column headings are not repeated. You can put field references into this header. You can also have footers, which is typically where subtotals go. And you can put field references there, as well. So you could probably get a header/detail report - might be very nice, in fact. There are some limitations - e.g., the header/footer text in QMFORMs must all be in pieces <= 55 long. But you can have LEFT, CENTER, & RIGHT on the same lines, so this isn't so bad.

If you use QMQRY/QMFORM you would not need the RPG at all, probably. QMQRYs can have substitutions variables, so you can use a CMD front end to a CL to get the values you want to put into the SELECT, then start the QMQRY, and ba-da-bing, you're done.

HTH - I know I might try this a little more myself.
Vern

At 02:40 PM 3/5/2006, you wrote:

Which is more better for reporting in RPG, STRRLU or STRQM?

I have noticed that STRRLU PRTF File does not support :-

1. Source File > 92
2. Varchar Field

Any suggestions please?

Can I create a formatted report in STRQM, say, a Master/Detail Report.

for example:-

Master Record
==========

Name   :   Luqman                  Address: Room No. 27, Cantt Road,Karachi
Tel       : 1234567                   E-Mail : myemail@xxxxxxxxx

Detail Record
==========
Order Details of Luqman
Item No.    Quantity    Rate    Amount
1                23             1         23.00
2                20             2         40.00
                 ---                         ------
   Total:      43                         63.00
                 ---                         ------

Best Regards,

Luqman




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