Re: GLS, 4GL, questions and some answers

Nils Myklebust wrote: > > We need to use the 8859-1 character set in our databases. > This is supposed to be an 8 bit characterset and that's what we need. > > Still if I use no locale or specify DB_LOCALE and CLIENT_LOCALE as > en_us.8859-1 I can not insert any 8 bit character into the database in > a litteral string, nor use such a litteral string in a query (in any > utility or language I have). You need an updated version of the en_us.8859-1 codeset, specifically version 4 or later of the en_us.8859-1 locale: to check your version, grep $INFORMIXDIR/gls/lc11/en_us/0333.lco LC_SOURCE_VERSION I don't know if the later locales are available from the external web- site (hmmm, something for me to do tomorrow), but they are available internally, so your local office should be able to get it for you. > Understand it whoever can. I have to write it off on american > missunderstandings of what a character set is. You can write it off as a misunderstanding, but GLS is not done in America. Not that I'm saying Americans haven't caused me problems in the past, with respect to accented characters and date formats... > I might however want to change some locale data for other purposes, > and didn't exactly like to do it with an editor. I didn't find a > locale file compiler. Does anyone know if there is one? We don't provide a way for you to create your own locales. However, you can contact your local Informix office about getting a new locale from Informix. > Now, Informix 4GL doesn't support GLS until release 7.2. Who knows > when that will be available for SCO Unix 5.0.x. Informix in Norway > can't give a good answer even though the have asked Informix in the > US. Does anyone have an idea? In the next few weeks, assuming you're talking about SCO 3.2.5.0 (I know nothing about SCO's version numbering). Sorry I can't be more specific than that, but you know how it is - can't commit. Supposed to be this month, anyway. Give or take... > However it doesn't look too professional to sort in the wrong order so > it is a small problem. To sort correctly I have to define collumns to > sort on as NCHAR instead of CHAR. A great pain in itself, but possibly > doable. Possibly. Why did the great american programmers give us a > problem like this? Why, dear americans? If one of you could give me > even the resemblance of a sensible answer I would be happy. Although it looks to you like CHAR sorts the American way, actually CHAR sorts by ASCII order, so the following CHAR values are sorted as follows: ABCDE ZZZZZ [[[[[ abcde zzzzz Since this is probably not what you want, you need to use a locale. The same would apply to Americans. > I am generally much more in need of speed than proper > sort order. Any loss of speed would render the NCHAR datatype next to > useless. If speed is your primary concern, I would suggest sticking to CHAR. Trust me on this one. > Do I dislike americans? No way. Oh, glad to hear it. -- June ---- June Tong Informix Software ---- ---- Senior Consultant (650) 926-6140 ---- ---- International Support junet@informix.com ---- ---- Location-du-jour: Menlo Park ----