One customer reported a not-correctly displayed Euro Symbol (€) in the database from sqlplus (msdos).
Why?
First, the character set did not support it.
select * from v$nls_parameters where PARAMETER like '%CHARACTERSET%';
PARAMETER VALUE
------------------------------ ---------------
NLS_CHARACTERSET WE8ISO8859P1
NLS_NCHAR_CHARACTERSET AL16UTF16
If you are still using WE8ISO8859P1, consider migrating to WE8MSWIN1252 using csalter
sqlplus "/ as sysdba" @?/rdbms/admin/csminst
csscan "'sys/sys as sysdba'" full=y tochar=we8mswin1252 array=1024000 process=5
sqlplus "/ as sysdba" @?/rdbms/admin/csalter.plb
It is not always that straight forward, check output from csscan (scan.*) carefully before running csalter.
Ok, now retry
H:\>set NLS_LANG=american_america.we8pc850
H:\>sqlplus.exe scott/tiger
SQL*Plus: Release 11.1.0.6.0 - Production on Thu May 10 11:28:01 2012
Copyright (c) 1982, 2007, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> select chr(128) from dual;
C
-
■
Not good!
Obviously, the PC850 client character is not good enough. Let’s switch to mswin1252 on the client.
H:\>chcp 1252
Active code page: 1252
H:\>set NLS_LANG=american_america.we8mswin1252
H:\>sqlplus.exe scott/tiger
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> select chr(128) from dual;
C
-
Ç
Well, what’s missing now? The font ! Let’s change it from “Raster Fonts” to “Lucida Console”. Either by clicking on the command com properties, or even dynamically with that gem (tested on XP) !
H:\>type Lucida.cs
using System;
using System.Runtime.InteropServices;
public class Lucida
{
const int STD_OUT_HANDLE = -11;
[DllImport("kernel32.dll", SetLastError = true)]
static extern int SetConsoleFont(IntPtr hOut, uint dwFontSize);
[DllImport("kernel32.dll", SetLastError = true)]
static extern IntPtr GetStdHandle(int dwType);
public static void Main()
{
SetConsoleFont(GetStdHandle(STD_OUT_HANDLE), 6);
}
}
H:\>csc Lucida.cs
Microsoft (R) Visual C# 2010 Compiler version 4.0.30319.1
Copyright (C) Microsoft Corporation. All rights reserved.
H:\>Lucida
H:\>sqlplus.exe scott/tiger
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> select chr(128) from dual;
C
-
€
Can you explain why WE8MSWIN1252 a better choice than WE8ISO8859P15?
I would not be able to explain it better than in note 264294.1
mswin1252 is a superset of iso8859p1 and the migration path is easy for small db with little to no rubish in varchar2 field (I am currently in the process of migrating a db with 99.998% good data, which is everything but 3M rows)
If you are 100% microsoft allergic, with no microsoft client, nothing related to windows and dos etc, you may want to try we8iso8859p15, which is a logical (but not binary-compatible) subset of we8mswin1252, but really why do that? There is no advantage I can think of
Just a littel nitpick: you are *not* using MSDOS when you run SQL*Plus.
The commandline in Windows has nothing to do with DOS (or MSDOS) it is a native Windows commandline.
well, that’s nitpick indeed. So CMD.EXE is Windows and COMMAND.COM is DOS?
or is command.com MSWINDOS and MSDOS is where you used to start WIN.COM
still, you remark makes sense as a pure MS-DOS console would not allow a mswin 1252 codepage. As the latest MSDOS version is almost two decades old, I suppose it would be very little benefit to show how to display the euro symbol in native MS-DOS. But chcp 1252 and .net won’t help for sure