Re: SQL sort

On 04-Sep-2015 07:28 -0600, Charles Wilt wrote:

On Fri, Sep 4, 2015 at 1:06 AM, Birgitta Hauser wrote:

Specifying a DDS described logical file in a SQL statement is
not a good idea (and never was).

Actually, IBM does recommend it now...
[http://www.mcpressonline.com/tips-&-techniques/sql/techtip-boost-sql-performance-on-dds-databases.html]

Very possibly, and hopefully, some of the quirks have been resolved with that newer capability. However...

From a prior post I made: "For a level of support on which the SQL Query Engine (SQE) can process the query of a DDS LF, the selection of the LF is translated [...] into the equivalent SQL predicates and the query is performed against the underlying PF(s) irrespective the table-reference." The snipped "[,,,]" part in the above quote: "I have seen examples where that [ed: translation of DDS LF into SQL predicate logic] fails horribly, and unless someone reported what I described, such defects may persist."

Given my negative experience, I personally would perform a thorough review of the data selected from a SQE query using a DDS-LF table-reference to be sure that the unordered result-set [reminder: the SQL ignores the keyed access path] matches exactly with what the direct RLA access of that LF produces, before coding such a query into an application. AFaIK the /generated SQL/ for the DDS LF would be the basis for what the SQE will use [as a sensible\reusable design], so I would verify that the predicate logic of the SQL VIEW and INDEX that are generated from that DDS LF exactly matches both the selection logic and any mapping coded in the DDS, before using that LF in any SQE-implemented query request; problem being, if the query currently routes to the CQE, there is no way to know [unless CQE has been eliminated entirely for the SQL] if\when such a query will eventually remain the domain of the SQE,