Re: Purpose and effect of $DBNLS env

On Oct 17, 10:02 pm, "Andrew Clarke, Civica" <a.andrew.cla...@gmail.com> wrote: > Hi folks > > I'm trying to get up to speed with GLS, and I can't seem to do > anything which triggers an error contrary to what the GLS manual > claims is the purpose of the DBNLS setting: > > <quote> > The DBNLS environment variable specifies whether automatic data type > conversion is supported between NCHAR and NVARCHAR database columns > and CHAR and VARCHAR variables (respectively) of the client systems. > > Conversely, setting no value for DBNLS disables automatic conversion > between CHAR and VARCHAR variables of the client application and NCHAR > and NVARCHAR columns of the database, and also prevents Dynamic Server > from using the locale files of the client system: > > setenv DBNLS > unsetenv DBNLS > </quote> > > I've tried using fr_fr.8859-1 locale to create a database and table > with CHAR and NCHAR, then tried to operate on it using de_de.8859-1 > but I'm not seeing an error when I assign a CHAR to NCHAR or vice- > versa in dbaccess. > > Does the engine or the client require this setting (or both)? > > What's it supposed to do exactly? DBNLS pre-dates GLS. NLS was (is) POSIX National Language Support, a set of mechanisms for handling multiple locales within a single application binary. DBNLS turned on NLS handling in IDS. One of the problems with NLS was that different platforms had different degrees of support for it - it did not provide a uniform internationalization environment (even ignoring the issues on Windows). The Informix solution to this was Global Language Support - GLS - introduced with the 7.20 family of products and still in use today. These days, you should not use DBNLS - unless you were using it in the days of 6.00, 7.00, or 7.1x, in which case you might keep it lurking around for backwards compatibility. But ideally, you should not use it even so. Yours, Jonathan Leffler

On Oct 20, 1:08 am, Jonathan Leffler <jonathan.leff...@gmail.com> wrote: > On Oct 17, 10:02 pm, "Andrew Clarke, Civica" > > > > <a.andrew.cla...@gmail.com> wrote: > > Hi folks > > > I'm trying to get up to speed with GLS, and I can't seem to do > > anything which triggers an error contrary to what the GLS manual > > claims is the purpose of the DBNLS setting: > > > <quote> > > The DBNLS environment variable specifies whether automatic data type > > conversion is supported between NCHAR and NVARCHAR database columns > > and CHAR and VARCHAR variables (respectively) of the client systems. > > > Conversely, setting no value for DBNLS disables automatic conversion > > between CHAR and VARCHAR variables of the client application and NCHAR > > and NVARCHAR columns of the database, and also prevents Dynamic Server > > from using the locale files of the client system: > > > setenv DBNLS > > unsetenv DBNLS > > </quote> > > > I've tried using fr_fr.8859-1 locale to create a database and table > > with CHAR and NCHAR, then tried to operate on it using de_de.8859-1 > > but I'm not seeing an error when I assign a CHAR to NCHAR or vice- > > versa in dbaccess. > > > Does the engine or the client require this setting (or both)? > > > What's it supposed to do exactly? > > DBNLS pre-dates GLS. > > NLS was (is) POSIX National Language Support, a set of mechanisms for > handling multiple locales within a single application binary. > > DBNLS turned on NLS handling in IDS. > > One of the problems with NLS was that different platforms had > different degrees of support for it - it did not provide a uniform > internationalization environment (even ignoring the issues on > Windows). > > The Informix solution to this was Global Language Support - GLS - > introduced with the 7.20 family of products and still in use today. > > These days, you should not use DBNLS - unless you were using it in the > days of 6.00, 7.00, or 7.1x, in which case you might keep it lurking > around for backwards compatibility.  But ideally, you should not use > it even so. > > Yours, > Jonathan Leffler Thanks for the reply. I'll take it on faith I don't need to set $DBNLS variable then, but the GLS manual for 10.0 mumbles something about it enabling and disabling conversions between CHAR <-> NCHAR, and VARCHAR <-> NVARCHAR. I'm still puzzled as to what that means? Ultimately I think I need to set only $SERVER_LOCALE, $DB_LOCALE, and $CLIENT_LOCALE in the appropriate places. We're getting something done that needs GLS; I'd better not mention at this stage in case it's still skunk-works, but if you poke around and have a chat with people like Kevesha or Mr. Pintus and mention Civica I'm sure they'll fill you in. By the way, is this newsgroup still gated to the informix-list@ mailing list? My mail subscription has been broken for quite a while so I went to the google. I haven't seen much traffic at all in the 2 days I've been waiting on my question. Cheers and thanks again

On Oct 19, 4:13 pm, "Andrew Clarke, Civica" <a.andrew.cla...@gmail.com> wrote: > On Oct 20, 1:08 am, Jonathan Leffler <jonathan.leff...@gmail.com> wrote: > > On Oct 17, 10:02 pm, "Andrew Clarke, Civica" > > <a.andrew.cla...@gmail.com> wrote: > > > I'm trying to get up to speed with GLS, and I can't seem to do > > > anything which triggers an error contrary to what the GLS manual > > > claims is the purpose of the DBNLS setting: > > > > <quote> > > > The DBNLS environment variable specifies whether automatic data type > > > conversion is supported between NCHAR and NVARCHAR database columns > > > and CHAR and VARCHAR variables (respectively) of the client systems. > > > > Conversely, setting no value for DBNLS disables automatic conversion > > > between CHAR and VARCHAR variables of the client application and NCHAR > > > and NVARCHAR columns of the database, and also prevents Dynamic Server > > > from using the locale files of the client system: > > > > setenv DBNLS > > > unsetenv DBNLS > > > </quote> > > > > I've tried using fr_fr.8859-1 locale to create a database and table > > > with CHAR and NCHAR, then tried to operate on it using de_de.8859-1 > > > but I'm not seeing an error when I assign a CHAR to NCHAR or vice- > > > versa in dbaccess. > > > > Does the engine or the client require this setting (or both)? > > > > What's it supposed to do exactly? > > > DBNLS pre-dates GLS. > > > NLS was (is) POSIX National Language Support, a set of mechanisms for > > handling multiple locales within a single application binary. > > > DBNLS turned on NLS handling in IDS. > > > One of the problems with NLS was that different platforms had > > different degrees of support for it - it did not provide a uniform > > internationalization environment (even ignoring the issues on > > Windows). > > > The Informix solution to this was Global Language Support - GLS - > > introduced with the 7.20 family of products and still in use today. > > > These days, you should not use DBNLS - unless you were using it in the > > days of 6.00, 7.00, or 7.1x, in which case you might keep it lurking > > around for backwards compatibility.  But ideally, you should not use > > it even so. > Thanks for the reply. I'll take it on faith I don't need to set $DBNLS > variable then, but the GLS manual for 10.0 mumbles something about it > enabling and disabling conversions between CHAR <-> NCHAR, and VARCHAR > <-> NVARCHAR. I'm still puzzled as to what that means? I'm not sure I can explain; there was a thing called 'implicit NLS' and this was part of it. The difference between CHAR and NCHAR is overstated. I wouldn't worry about (I don't worry about it). > Ultimately I think I need to set only $SERVER_LOCALE, $DB_LOCALE, and > $CLIENT_LOCALE in the appropriate places. You only need to set the server locale when you start IDS (run 'oninit'). Otherwise, you just set DB_LOCALE and CLIENT_LOCALE. You can override GLS settings for date formats with DBDATE still. You probably leave everything else alone. > By the way, is this newsgroup still gated to the informix-list@ > mailing list? My mail subscription has been broken for quite a while > so I went to the google. I haven't seen much traffic at all in the 2 > days I've been waiting on my question. Yes, it is. NLS is an esoteric subject; most people don't know quite as much as I do about it, and I know depressingly little about it, so I'm not very surprised that no-one else responded. The ALS (Asian Language Support) and NLS environment variables are, I think, obsolete; they are on my hitlist of 'things to remove from Informix products' when I get the energy to drive it through. The problem is, you can't make a lot of snazzy Powerpoint slides out of "removed obsolete code from the product". Therefore, such work does not get much priority. So, check back in ten years or so... Yours, Jonathan Leffler You

On Thu, 21 Oct 2010 02:19:18 Jonathan Leffler wrote: > > I'm not sure I can explain; there was a thing called 'implicit NLS' > and this was part of it. The difference between CHAR and NCHAR is > overstated. I wouldn't worry about (I don't worry about it). > That's more than enough reassurance then. > You only need to set the server locale when you start IDS (run > 'oninit'). > > Otherwise, you just set DB_LOCALE and CLIENT_LOCALE. > You can override GLS settings for date formats with DBDATE still. > You probably leave everything else alone. > Cool. Another open question on environment I have is, can the sysdbopen() procedure dominate the assignment of locale? We only need a fixed locale, and we want every connecting product to use it, so anything that can avoid visiting hundreds of PC's to reset the locale in the registry would be very useful. > Yes, it is. NLS is an esoteric subject; most people don't know quite > as much as I do about it, and I know depressingly little about it, so > I'm not very surprised that no-one else responded. > I'm talking more in the number of other messages. Maybe google is not floating active threads to the top, just keeping them in order of original post. But it looked very quiet through that port hole. I've just successfully fixed my mailing list entry through the iiug, - on the 10th attempt over the last few years. I don't know what's different but at least it's sorted now. > The ALS (Asian Language Support) and NLS environment variables are, I > think, obsolete; they are on my hitlist of 'things to remove from > Informix products' when I get the energy to drive it through. The > problem is, you can't make a lot of snazzy Powerpoint slides out of > "removed obsolete code from the product". Therefore, such work does > not get much priority. So, check back in ten years or so... > heh - funny you should mention that. A main part of the communique was a rushed powerpoint with all the brightly colored stuff I've only seen in roadshows before.