Re: Query Management Reports Problem

[CRPence <CRPbottle@xxxxxxxxx>]

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