Re: Query Management Reports Problem

Alan Campin wrote:

CRPence wrote:

<snip>
I believe [or at least I hope] you have mis-remembered what you
were told. The Query/400 report writer is used by the STRSQL,
to produce the output for non-DRDA interactive SQL requests.
The QM report writer is separate. The following thread:
http://archive.midrange.com/midrange-l/200708/msg01234.html
</snip>

Interesting thing is if you do a RTVQMFORM from a QRY/400 and QMQRY
object you get the same thing. Same underlying engine or just the
same file format?

Also, when you retrieve the query (RTVQMQRY) what you get back from
the QRY/400 object is not necessarily correct which implies that it
is just guessing at what the SQL would look like if they were running
SQL.

The output is the /same/ format because those are the interfaces for the Query Management component, to retrieve\produce the source for either a Query Management SQL query [other than SELECT statements are allowed, so it is somewhat a misnomer] or a Query Management form. The compilers for the *QMQRY and *QMFORM objects will recognize only its own source language.

Those retrieve features as part of the QM [Query Management] feature of the OS, have coded an extension to support the *QRYDFN object. When referencing a *QRYDFN object versus a *QMQRY or *QMFORM object, they attempt to extract the information from the *QRYDFN object, to enable creation of source from which a representative QM object can be created by each of the CRTQMQRY and CRTQMFORM commands. The source that is generated is only an attempt at a like-representation of the details extracted from the Query Definition object. Due to the non-SQL nature of the Query/400 Query Definition object reporting, it may not be possible to generate QMQRY source [an SQL SELECT] which can represent the function of the *QRYDFN as produced by a RUNQRY request. The ANZQRY for example, will warn of many of the details not available to the QMQRY or the QMFORM, when extracting from a *QRYDFN. Note: A *QRYDFN object encapsulates both the /query/ and the /report form/, instead of having separate objects; the *QRYDFN supports only an effective SELECT, even though its join and selection is not always capable of being easily represented in SQL, even if only due to its report options.

Regards, Chuck