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?
H:\>cmd
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
H:\>command
Microsoft(R) Windows DOS
(C)Copyright Microsoft Corp 1990-2001.
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 🙂