Re: GLS, 4GL, questions and some answers

Thanks for the comments, but there are some further questions: On Tue, 12 May 1998 22:23:17 -0700, June Tong <junet@informix.com> wrote: >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 Well, I have LC_SOURCE_VERSION= 3 so that's why it doesn't work properly then. I assume new upgrades will have this, and as we have just ordered one for a customer I'll look into that in a few days. >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. Ok, but others don't seem to understand it too well either. I'll write it off on this ground however. But as you may have seen here in c.d.i. it has caused quite a few people a lot of greaf. We do however now know what to answer them. > 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. If I don't get one with the upgrade I will. The "compiled" locale file is still some sort of text file though, and I am able to make minor changes to it. May be it's too dangerous to let customers play with it. There would be a lot of things you could do very wrong. Still a tool to do at least some things might have been nice. >> 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... This just sounds great. I'll wait in great expectation. And yes it is SCO 3.2.5.0.x where the x has been at least 0, 2 and 4 which are the latest releases of SCO Open Server. >> 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, Well, I do understand that. I would call it binary order perhaps, but yes, there are some problems with that. > 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. Yes, indeed. I.e. for sorting of names it would most often be a good idea to have upper and lower case as equal as a very minimum. Here you'll soon hit a problem with requirements for different sort orders on different data. I guess the Universal Data Option is the real answer to that. In the meantime we use extra sort columns for which we generate data ourselves. >> 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. Here is the big question: For many locale conversions when it comes to ordering of char-data it would suffice to have a very simple lookup table to convert each byte to another in a char variable. This should be very fast and should at least not slow down index creation by as much as has been reported. I do understand that other conversions are much more complicated, and would require a significant chunck of code to do it (dictionary order of 16 bit characters would be an exsample). It seems to me that the Informix solution goes through a fairly complicated routine to do such conversions even in the simple cases. If this is the case I think it would be more than a good idea for Informix to look into this and see if simple sort orders could be done significantly faster. I am talking about those where you essentially have to translate each character into another that represents the ordering. >> 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 ---- Nils Myklebust NM Data AS Norway E-mail: Nils.Myklebust@nmdata.com FAQ at: http://www.iiug.org/techinfo/faq/faq_top.html (Now with ODBC info under "Third party products".)