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
midrange.com
