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




I came across an excellent tip in a Centerfield Technology Newsletter(Vol 2 Issue 2) concerning the use of *LANGIDSHR. I actually got it working and was able to retrieve records via SQL with the same column value regardless of case. This involved creating an index while the STRSQL task was set to *LANGIDSHR.

I was researching this in order to try and overcome the problem of v5r4 sending the SQL to the CQE and I optimistically thought that this might overcome that problem and thus despatch it to the SQE. Alas and alack! When I looked at the Visual Explain, the 'Reason SQE was not used' was - 'Translation Required'.

I presume this is something to do with the upper/lower case process in using the index?

Is it worth pursuing this path? Or is there no way of overcoming the UPPER barrier to the SQE? Something like the IGNORE_DERIVED_INDEX setting in QAQQINI?

This is a continuation of a post I made a few weeks ago so I'm not hopeful as *LANGIDSHR came up in that topic as well.

I tried telling my superiors that we could change every program which populates the table to force an upper, however this is not really feasible as it involves names which are used in communications.

Looks like we're stuck with the CQE which means there's no point in creating indexes to assist the SQL as they'll be ignored. Does this mean that CQE will always do a full table scan? Or should we retain the logical file in the SQL as it's being despatched to the CQE anyway?

My head is spinning!

Thanks.........


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.