Re: GLS Databases

The document I was talking about is "Guide to GLS functionality", page 3-23. I understood from that document that the "IN('feron')" comparisons should return feron and f'ron (is e and ' are considered are equivalent). Any other clues ? June Tong wrote in message <36071C14.58BBE465@hotmail.com>... >Vincent Birlouez wrote: > >> I set up my database to support french sorting order (using DB_LOCALE and >> CLIENT_LOCALE, I set them to fr_be.8859-1). I'm using informix 7.24 >> >> It work fine for sorting order (F'ron is coming right after Feron). >> >> But, when I execute the following query : >> select * from tab1 >> where ncharcolumn in ('feron')>> I only get the rows where ncharcolumn = feron. I was expecting >> informix to return feron, f'ron and Feron, as written in the GLS guide >> (3-28). > >Hmmm. I don't know if I've ever seen the GLS guide, but I'm thinking I might >have to get my hands on one. I have been told by Informix development that >what you are seeing is expected behavior; that is, that comparisons like: > WHERE ncharcolumn = 'feron' >*should* only return 'feron', and *not* 'f'ron'. This was a really huge >sticking point with me. I would really love to see documentation that >contradicts this... (Clem... ?) Of course, they will probably just say the >documentation is incorrect. The documentation group follows what PD says, >not (usually) the other way around. > >I am also very interested in the opinions of anyone whose native language >includes accented letters, such as ', on whether they think it *should* test >true. If your users typed 'fe*' into a form, would they expect to get >'f'ron', or not? This only applies to languages where the accented letter is >equivalent to the unaccented letter, such as French or Spanish, not to >languages which contain additional letters which are treated differently, >e.g. the Swedish '. > >June >-- >june_t@hotmail.com >Lost in the wilds of Palo Alto, living on Mrs. Fields' chocolate chip cookies > > >