dbTalk Databases Forums  

Purpose and effect of $DBNLS env

comp.databases.informix comp.databases.informix


Discuss Purpose and effect of $DBNLS env in the comp.databases.informix forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
Andrew Clarke, Civica
 
Posts: n/a

Default Purpose and effect of $DBNLS env - 10-18-2010 , 12:02 AM






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?

Reply With Quote
  #2  
Old   
Jonathan Leffler
 
Posts: n/a

Default Re: Purpose and effect of $DBNLS env - 10-19-2010 , 09:08 AM






On Oct 17, 10:02*pm, "Andrew Clarke, Civica"
<a.andrew.cla... (AT) gmail (DOT) com> wrote:
Quote:
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

Reply With Quote
  #3  
Old   
Andrew Clarke
 
Posts: n/a

Default Re: Purpose and effect of $DBNLS env - 10-20-2010 , 08:16 PM



On Thu, 21 Oct 2010 02:19:18 Jonathan Leffler wrote:
Quote:
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.

Quote:
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.

Quote:
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.

Quote:
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.

Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.