Skip to main content
Answer

GBP Pound sign £ returned by Oracle 19 (WE8ISO8859P15) displayed as # in Uniface 10.4 application

  • November 10, 2025
  • 3 replies
  • 48 views
Henk Van der Veer

Anyone ran into the following? And knows a solution?

Environment:

  • Uniface 10.4.02.58 on Windows 10 and RedHat 9.4 Linux
  • Character set for I/O ($DEF_CHARSET:
    - Windows: CP1252 (default)
    - Linux: LATIN1 (default)

Oracle Database 19c, 
NLS_CHARACTERSET defined as WE8ISO8859P15; this is supposed to be ISO 8859-15 including £ and € 

GBP pound sign £ stored in a database table or returned in the text of a Stored Package is displayed in Uniface (both Windows GUI and Linux CHUI) as #. 

Setting $DEF_CHARSET on the client(s) and userver to UTF8 helps, but has a negative side effect on tables with column LONG RAW, such as PRATT. 

Best answer by Peter Beugel

Hello Henk

 

I can reproduce this  when not setting NLS_LANG on the client side.

 

Your result should be ok after setting NLS_LANG to match the database character set

and $DEF_CHARSET to match NLS_LANG.

 

For example

[SETTINGS]

$DEF_CHARSET = LATIN9

 

and in script to test Uniface

set "NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P15"

 

 

 

3 replies

Peter Beugel
Forum|alt.badge.img+1
  • Peter BeugelRocketeer
  • Rocketeer
  • Answer
  • November 12, 2025

Hello Henk

 

I can reproduce this  when not setting NLS_LANG on the client side.

 

Your result should be ok after setting NLS_LANG to match the database character set

and $DEF_CHARSET to match NLS_LANG.

 

For example

[SETTINGS]

$DEF_CHARSET = LATIN9

 

and in script to test Uniface

set "NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P15"

 

 

 

Henk Van der Veer
Ingo Stiller
Forum|alt.badge.img+3
  • Ingo Stiller
  • Participating Frequently
  • November 13, 2025

Hi Henk

Since I have been interested in such problems for decades, I surfed the internet to see if there was an explanation. And yes, the very old, deep-rooted cause is that the Americans gave the # character the name ‘pound’.  
This still has an effect today: databases with older code pages that are labeled as American  replace the input ‘£’ with ‘#’. 
See also:
https://comp.databases.oracle.misc.narkive.com/zHkR8i6T/oracle-8i-pound-symbols-stored-as-hashes

Maybe and if it possible, teh database had to switch to some european settings :-)

groeten van de Rijn
Ingo

 

Henk Van der Veer

Hi Ingo,

It wasn’t about inputting/storing pound signs, but about displaying pound signs retrieved from an Oracle table or sent as part of a response by an Oracle procedure.

Peter's answer regarding setting environment variable $NLS_LANG to AMERICAN_AMERICA.WE8ISO8859P15 was spot on! I did not have to change $DEF_CHARSET in any of the Uniface assignment files at all. 

Our situation is:

  • Both a CHUI application on Linux and a GUI application on Windows suffered form this problem.
  • The CHUI application performs I/O against Oracle using a local Oracle client
  • The GUI performs I/O with Oracle via Uniface Urouter/userver (which talks to the same Oracle client)

Changes we applied:

  • CHUI environment: set environment variable in the insunis command file
  • Userver: set environment variable in /etc/sysconfig/urouter
    (this file sets the environment for uservers started by the urouter service)

Groeten 
Henk

Recent badge winners

Explore all badges
Terms & ConditionsAccessibility statement