×
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.
If that's the only difference, you've found a bug.
That setting has nothing to do with the result set you'll get from an SQL
statement, only what query engine gets a chance to execute the request.
Do a WRKPTFGRP and check for the latest:
http://www-912.ibm.com/s_dir/slkbase.nsf/recommendedfixes
Elvis
Celebrating 11-Years of SQL Performance Excellence on IBM i, i5/OS and
OS/400
www.centerfieldtechnology.com
-----Original Message-----
Subject: RE: Is this an SQL problem or quirk
Thanks for your reply Elvis
I'll look into that, but we were thinking it was something to do with
IGNORE_DERIVED_INDEX being changed from the default of *NO to *YES.
According to the text in the file, it says....
Allows SQE to process the query even when a mapped key index or select omit
index exists over a table in the query. SQE will ignore the derived index
(s) and continue. QQVAL: *DEFAULT--The default value is set to *NO.
*YES--Allow the SQE optimizer to ignore the derived index and process the
query. The resulting query plan will be created without any regard to the
existence of the derived index(s). *NO--Do not ignore the derived index. If
a derived index exists CQE will process the query.
Once this was changed back to the default, the results for BOTH of us was
what was expected.
Alan Shore
As an Amazon Associate we earn from qualifying purchases.