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