GLS, 4GL, questions and some answers

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). If I specify no_no.8859-1 I can use 8 bit characters freely in litteral strings. Understand it whoever can. I have to write it off on american missunderstandings of what a character set is. 8859-1 ought to be the same character set all over the world. Apperantly it isn't to Informix. Any answers to this would be greatly appreciated. To change to another locale, even one that doesn't realy change anything at all, you have to export the database and import it again after having set the proper DB_LOCALE. You often can't use dbexport/dbimport for this. If the decimal point and thousands separator are different the dbimport will not understand decimal data after you have changed DB_LOCALE. The same would probably be true if there where significant changes in the date format or possibly other things. I did change the appropriate .lc file (it is an ascii file and is called $INFORMIXDIR/gls/no_no/0333.lc in my case) with an editor. Then dbimport worked with decimal data and I could change it back afterwards. onunload and onload does however work, and is better for the purpose. 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? May be I shouldn't do this. May be it's enough to use the different environement variables for this purpose? 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? Even though 4GL doesn't support GLS it does however accept 8 bit characters in litteral strings after I created the database with DB_LOCALE=no_no.8859-1. That means the construct statement now workseven if the user types an 8 bit character in his query spesifications. Great! That solves *the* major problem. I and my users aren't too conserned about sort orders. First they don't print or display many reports any more that needs to be sorted alphabetically on data that is effected. Secondly even if they do they find out the sort order and use it effectively. 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. Why isn't there some kind of a system/environement variable or whatever to define the sort order for CHAR columns? Isn't that specified in the ANSI standard? Who cares. The ANSI standard in this area and many others is so bogus anyway it isn't particularly interesting. Let's have solutions that are simple without destroying functionality or features. If I want one of them to sort in some order it seems to me quite likely that I want them all sorted in that order. I do have cases myself where this isn't so, but NCHAR doesn't help me out of that. I would have had to have several CHAR datatypes with separate sort orders for each. Realy another requirement that should be supported. That might however have been done via a domain spesification of some kind, not necessarily a built in datatype. It would however also be required to specify such domains as compatible (for use in unions and several other purposes) with just the sort order different. The internal datatype may not realy be different. They may all be character columns using the same character set with only the sort order beeing different. Different character sets in different columns may be a requirement for some, but that's more esoteric. However beeing able to specify a limited set out of the standard charcterset for a column is a significant requirement that should be supported, and shouldn't be hard via a proper domain spesification. Now if I do define NCHAR columns (or even if I had had a way to spesify sort order for CHAR columns) I have seen reports here in c.d.i. that creating indexes slows down very significantly. Can anyone confirm this? If it is the case, can something be done? How are inserts and updates effected then? It seems to me they must be equally slow. I can't find any documentation on how Informix have realy implemented the sort order stuff. Of course it must be something with how they create the index data. It would however be extremely helpfull to know something about this. Does anyone know anything, or better know of a reference to a manual of whatever that describes this? I need this information to evaluate whether NCHAR can be used in my applications. 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. Then I plan to sell my applications in the US. How many in the US would like to see NCHAR columns in the database. Probably not that many. I would have to create an american version of the database. Great!?."#$ Most of my potential customers in the US would love to be able to insert 8 bit characters though, so I would still have to set up GLS for this sole purpose. Strange americans. The point here is that they are starting to understand that some people write their names and adresses with strange characters. With modern equipment these characters, wonder over all wonders, actually print on american printers and display on their screens. They are actually possible to input as well. Some even arrive over the internet as people fill in their name and adress via web pages. Many now like to be able to store things correctly and please their customers. As 4GL doesn't support GLS it also doesn't use the GLS environement for display of dates, numeric data or anything else. This is fine. I have no problem with this. I am however quite conserned that some unknown programmer somewhere have sneeked in some bug that only pops up when I use a GLS database. Does anyone know of any such bugs in 4GL? I and my customers are on different 6.0x releases of 4GL and use only the C-compiled version. Do I dislike americans? No way. Do I think some americans are sometimes not too smart? Yes, just like us on this side of the pond and anywhere else. Do I think americans could have thought a little bit more about international support in databases. Yes I do. You create these products. Excelence is as important to you as to anyone else. You do need to learn a little more about the world outside your own dorstep. That has allways been a problem in the US. Some of you are learning though. IBM now has one of the best internationalization support in the world, and it's showing up in Java through a cooperative effort with Sun. Informix bett