Turn off thousands separator from NLS locale

Author: mmontealegre@commandalkon.com (mmontealegre)

We have had a recent project to turn our legacy application to start using NLS locale so that the decimal separator is comma for Europe and period for US.  For this we started using $nls_locale, previously we never had this set to anything.  Without this set there is no thousand separator, now with this set there is a thousands separator.  This causes a large number of bugs in our application in a large variety of areas.  Is there any way to just turn the thousand separator off?  Also wouldn't mind if there was a way to turn off the date formatting portion as well.  We have had a ton of custom logic dealing with dates that is stepping on the NLS in a large number of areas of the application as well.

1 Comment

  1. Hi, From your opening post, am I correct in assuming that:

    1. Your legacy application is a Uniface application (?)
    2. In the ASN file of the legacy application $NLS_LOCALE has been set to the value 'system' (?) 3. Nothing (no NLS settings etc.) has been changed on the database settings of the legacy application (?)

    And you're now experiencing problems on the thousands seperator in numeric fields, and sometimes on date formatting. My guess is that developers have done a lot of (sub-)string manipulation on numeric and date fields, heavily relying on the 'old' (or non) NLS setting, rather than using the proper date, time and numeric operations. You can try to override the behavior specified by NLS locale by setting $NLS_FORMAT or $nlsformat. $NLS_FORMAT is an assignment setting, where $nlsformat is proc code. Please check the Help file on this. For your numeric field formatting, please check 'Uniface Reference -> Field definitions -> Display Formats for Numeric and Float Data'. For your date formatting, please check 'Uniface Reference -> Field definitions -> Display Formats for Date and Time Data'. Also 'Developing international applications -> Language and Locale' might be a good chapter to check. Hope this helps, regards, Arjen

    Author: Arjen van Vliet (arjen.van.vliet@uniface.com)