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



Luis

You are right about CQE vs SQE - that was changed at V5R4 - I ran into that with one of our products where we have case-insensitive searches.

And I'm glad to see you confirm what my old memory brought up about the pseudo-ASCII order.

Regards
Vern

On 3/27/2012 8:22 AM, Luis Rodriguez wrote:
Joe,

Joe, I use *LANGIDSHR when I need both, case insensitivity and an
ASCII-like collating sequence (numbers before letters). Also, it allows
(AFAIK) for the correct collating sequence, regardless of the code base
used. For instance, in Spanish we have a letter that is just like a 'N'
with a tilde on top (Ñ). If I use, for instance, *HEX, the lower case
version (ñ) comes AFTER the upper case version (Ñ), because the upper case
letter corresponds (IIRC) to the # character in EBCDIC (appears before
'A'). *LANGIDSHR solves this.

The downsize is that, at least in V5R3, it seems to me that SQL tends to
use CQE instead of SQE when defining a table with *LANGIDSHR...

HTH,

Luis Rodriguez
IBM Certified Systems Expert — eServer i5 iSeries

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.