Sql developer vs nls_lang/character set

Hi
I've been trying to change the character set for sql developer but I can't seem to get it done.
I've tried:
<ul>
<li>regedit: NLS_LANG=AMERICAN_AMERICA.AL32UTF8
<li>Windows env: NLS_LANG=AMERICAN_AMERICA.AL32UTF8
<li>dos env: set NLS_LANG=AMERICAN_AMERICA.AL32UTF8
</ul>
and still it is not showing in AL32UTF8, while sqlplus and sqlplusw on the same computer do show the correct character set
What am I missing?
Geert

Duh, nobody ever checks out Preferences?
That trick's for v1.0; NLS Parameters can be found under the Database node since...
No guarantee that would enable the desired character set in the desired places, but you can try to change the Encoding under Environment too.
Regards,
K.

Similar Messages

Java.sql.SQLException: Non supported character set: oracle-character-set-17

Hi,
i am trying to execute an Oracle procedure from JDBC. The procedure accepts a Nested table as an input parameter. Definition of the nested table is given below.
Database – Oracle 10g.
Application Server – JBOSS 4.2.1
I get the following exception._
java.sql.SQLException: Non supported character set: oracle-character-set-178
at oracle.gss.util.NLSError.throwSQLException(NLSError.java:46)
I. JDBC Code_
Session s = HibernateUtil.getSession();
Transaction tr = s.beginTransaction();
con=s.connection();
oraConn = (OracleConnection) con.getMetaData().getConnection();
TableObject obj=new TableObject();
obj.setId(new Integer(123));//Tested ok, stroing in DB
obj.setDescr("test"); // this line throwing error
obj.setCre_user(new Integer(456));
obj.setUpd_user(new Integer(789));
obj.setXfr_flag("Y");
ArrayList al=new ArrayList();
al.add(obj);
Object[] objAray = al.toArray();
ArrayDescriptor arrayDescriptor =ArrayDescriptor.createDescriptor("T_TEST_SYN", oraConn);
ARRAY oracleArray = new ARRAY(arrayDescriptor, oraConn, objAray);
cs = (OracleCallableStatement)oraConn.prepareCall("call PKG_OBJ_TEST.accept_ui_input(?) ");
cs.setArray(1, oracleArray);
cs.execute();
tr.commit();
public class TableObject implements SQLData{
private String sql_type = "T_OBJ_TEST";
private int id;
private String descr;
//private Date cre_date;
private int cre_user;
//private Date upd_date;
private int upd_user;
private String xfr_flag;
public TableObject()
public TableObject (int id,String descr,int cre_user,int upd_user,String xfr_flag)
// this.sql_type = sql_type;
this.id = id;
this.descr = descr;
// this.cre_date=cre_date;
this.cre_user=cre_user;
//this.upd_date=upd_date;
this.upd_user=upd_user;
this.xfr_flag=xfr_flag;
public String getSQLTypeName() throws SQLException {
return "T_OBJ_TEST";
public void readSQL(SQLInput stream, String typeName) throws SQLException {
//sql_type = typeName;
id=stream.readInt();
descr=stream.readString();
//cre_date=stream.readDate();
cre_user=stream.readInt();
//upd_date=stream.readDate();
upd_user=stream.readInt();
xfr_flag=stream.readString();
public void writeSQL(SQLOutput stream) throws SQLException {
try {
stream.writeInt(this.id);
System.out.println("Iddddd");
stream.writeString(this.descr);
System.out.println("Desccccccccccccccc"+":"+descr);
//stream.writeDate(cre_date);
stream.writeInt(this.cre_user);
System.out.println("userrrrrrrrrrrr");
//stream.writeDate(upd_date);
stream.writeInt(this.upd_user);
System.out.println("upd uiserrrrrrrrrrr");
stream.writeString(this.xfr_flag);
System.out.println("flagggggggggggggggggggg"+xfr_flag);
}catch (SQLException se) {
System.out.println("Table object sql exception");
se.printStackTrace();
catch (Exception e) {
System.out.println("Table object exception");
* @return the id
public int getId() {
return id;
* @param id the id to set
public void setId(Object obj) {
Integer iobj= (Integer)obj;
this.id =iobj.intValue();
* @return the descr
public String getDescr() {
System.out.println("getDescr "+descr);
return descr;
* @param descr the descr to set
public void setDescr(Object obj) {
System.out.println("setDescr "+obj);
String sobj = (String)obj;
this.descr=sobj.toString();
System.out.println("setDescr "+obj);
* @return the cre_user
public int getCre_user() {
return cre_user;
* @param cre_user the cre_user to set
public void setCre_user(Object obj) {
Integer iobj=(Integer)obj;
this.cre_user = iobj.intValue();
* @return the upd_user
public int getUpd_user() {
return upd_user;
* @param upd_user the upd_user to set
public void setUpd_user(Object obj) {
Integer iobj=(Integer)obj;
this.upd_user = iobj.intValue();
* @return the xfr_flag
public String getXfr_flag() {
return xfr_flag;
* @param xfr_flag the xfr_flag to set
public void setXfr_flag(Object obj) {
this.xfr_flag = (String)xfr_flag;
II. Oracle database object details
Details of Object and Nested table created in the database.
T_TEST_SYN is a public synonym created for t_tab_obj_test
CREATE OR REPLACE TYPE t_obj_test as object (
id number(10),
descr varchar2(100),
--cre_date date,
cre_user number(10),
--upd_date date,
upd_user number(10),
xfr_flag varchar2(1),
CONSTRUCTOR FUNCTION t_obj_test ( id IN NUMBER DEFAULT NULL,
descr IN varchar2 default null,
--cre_date in date      default null,
cre_user in number default null,
--upd_date in date      default null,
upd_user in number default null,
xfr_flag in varchar2 default null ) RETURN SELF AS RESULT ) ;
CREATE OR REPLACE TYPE BODY t_obj_test as
CONSTRUCTOR FUNCTION t_obj_test ( id IN NUMBER DEFAULT NULL,
descr IN varchar2 default null,
--cre_date in date      default null,
cre_user in number default null,
--upd_date in date      default null,
upd_user in number default null,
xfr_flag in varchar2 default null ) RETURN SELF AS RESULT IS
BEGIN
SELF.id := id ;
SELF.descr := descr ;
--SELF.cre_date := cre_date ;
SELF.cre_user := cre_user ;
--SELF.upd_date := cre_date ;
SELF.upd_user := cre_user ;
SELF.xfr_flag := xfr_flag ;
RETURN ;
END ;
END ;
CREATE OR REPLACE TYPE t_tab_obj_test AS TABLE OF t_obj_test ;
CREATE OR REPLACE PACKAGE BODY PKG_OBJ_TEST AS
PROCEDURE accept_ui_input ( p_tab_obj_test in T_TAB_OBJ_TEST ) IS
BEGIN
FOR row IN p_tab_obj_test.First .. p_tab_obj_test.LAST
LOOP
INSERT INTO OBJ_TEST ( ID,
DESCR,
CRE_DATE,
CRE_USER,
UPD_DATE,
UPD_USER,
XFR_FLAG )
VALUES ( p_tab_obj_test(row).ID,
p_tab_obj_test(row).DESCR,
NULL,
p_tab_obj_test(row).CRE_USER,
NULL,
p_tab_obj_test(row).UPD_USER,
p_tab_obj_test(row).XFR_FLAG ) ;
END LOOP ;
COMMIT ;
END accept_ui_input ;
END PKG_OBJ_TEST;
/

Check your CLASSPATH enviroment variable. Try to add something like c:\Ora10g\jlib\orai18n.jar.
From "JDBC Developers Guide and Reference":
orai18n.jar
Contains classes for globalization and multibyte character sets support
This solved the same error in my case.

Java.sql.SQLException: Non supported character set: oracle-character-set-860

Hi,
I am working on resultset.updateRow() and found some problem.
I've tried the same jsp page on 2 WebLogic server
one is on a Solaris Platfoem and another is on a NT platform
On NT Platform it seems to be OK and update the database successfully.
On Solaris, on error message on WebLogic log but error found in the JDBC log
java.sql.SQLException: Non supported character set: oracle-character-set-860
P.S. both jsp page connection to the same database server Oracle 8
The testing JSP page:
<%@ page language="java" import="java.sql.*, oracle.jdbc.driver.*,
java.util.*, javax.sql.*" %>
<html>
<head>
<title>Weblogic Oracle Testing - Store Procedure</title>
<meta http-equiv="Content-Type" content="text/html; charset=big5">
</head>
Oracle Connection Testing
 
<body bgcolor="#FFFFFF">
<%
Connection conn = null;
Statement stmt = null;
ResultSet rs = null;
String sql;
Driver myDriver =
(Driver)Class.forName("oracle.jdbc.driver.OracleDriver").newInstance();
try {
conn=DriverManager.getConnection("jdbc:oracle:thin:sa/z0y1z2y3@oradev01:1521
:DEV01a");
DatabaseMetaData DBMetaData = conn.getMetaData();
boolean support1 =
DBMetaData.supportsResultSetType(ResultSet.TYPE_SCROLL_SENSITIVE);
boolean support2 =
DBMetaData.supportsResultSetType(ResultSet.CONCUR_UPDATABLE);
%>
<%=support1%>
<%=support2%>
<%
//create a statement
stmt = conn.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE,
ResultSet.CONCUR_UPDATABLE);
//execute a query
rs = stmt.executeQuery("SELECT tbl_web_trx_hdr.* FROM tbl_web_trx_hdr");
int concurrency = rs.getConcurrency();
int type = rs.getType();
%>
concurrency: <%=concurrency%>
type: <%=type%>
<%
rs.moveToInsertRow();
rs.updateString("org_idx", "CCC");
rs.updateString("trx_num", "ABC2");
rs.updateDate("trx_dte", java.sql.Date.valueOf("2001-06-01"));
rs.updateString("description", "123");
rs.insertRow();
rs.updateRow();
} catch (SQLException e)
{ System.out.println("SQLMessage: " + e.getMessage());
finally
{ rs.close();
stmt.close();
conn.close(); }
%>
</body>
</html>
Please help
regards,
Fannie

yupp finally i got the solution. . .
I was using connection from tomcat connection pooling.
Hence, even though i was setting the classes12.jar and nls_charset12.jar in the classpath and compiling, -In runtime tomcat was using its own classes in the common/lib folder. . .(which might not support oracle-character-set-178.)
So just added this jars into the common/lib of tomcat instead of web-inf/lib of my project
and things began working. . .
Thanks for the hint jshell. . .

Std::string NLS_LANG character sets

I'm an OCI user but not a pure one. Because I use the free available OTL (Oracle Template Library) from S.Kuchin which is a wrapper around OIC I hope this not off topic here.
The library offers the possibility to read database strings from VARCHAR2 fields to
a std::string. I know that oracle does character converting at client side controlled
via NLS_LANG environment variable.
It's clear to me that reading database strings to std::string is no problem for
one byte character sets liike ISO-8859-1. But how about when I let point NLS_LANG
to UTF-8 or chinese character set e.g. ZHT16BIG5 ?
Is it still safe to read the result to a std::string ?
For example I have a database with default characterset AMERICAN_AMERICA.WE8ISO8859P15. I stored some German umlaut in some
table. I wrote a small program using OTL and set NLS_LANG to UTF8 on client side.
I fetched the data from server to client, stored the data in a std::string, pushed them in a file and yes the data were stored as UTF8.
Is it really so simple or is it dangerous to read the UTF8-converted data to
std::string ? Wat is the common rule ? When may and when may I not read the data
to std::string ?

Hello,
I think you'll have more accurate answer in the Globalization Support Forum:
Globalization Support
Best regards,
Jean-Valentin

How to change the Forms and Reports's NLS_LANG character set on OAS

Hi,
I'm having problems with the OAS10g's actual character set, when displaying a report made with Reports Builder 10g who has the letter "ñ" it displays "ñ " with a blank space at the final so i need to change this character set for one that suits this requirement.
which file or files should i change ??
could this change affect something else, for example another product in my OAS ??
Regards
Carlos

I have this Forms and Reports Application in Brazilian Potuguese. What I do at new installations is:
1. Open this file: <MiddlewareOracleHome>/forms/server/default.env and add the NLS parameters below the FORMS_PATH definition:
FORMS_PATH=D:\Oracle\home207middle\forms;D:\MYENV\Exe;D:\MYENV\Imagens
NLS_LANG=BRAZILIAN PORTUGUESE_BRAZIL.WE8MSWIN1252
NLS_NUMERIC_CHARACTERS=,.2. Open this file: <MiddlewareOracleHome>/reports/conf/<your_report_server_name>.conf and create an "environment" section with the NLS variables:
 <environment id="MYENV">
 <envVariable name="REPORTS_PATH" value="D:\MYENV\Exe;D:\MYENV\Imagens"/>
 <envVariable name="NLS_LANG" value="BRAZILIAN PORTUGUESE_BRAZIL.WE8MSWIN1252"/>
 <envVariable name="NLS_DATE_FORMAT" value="DD/MM/YYYY"/>
 <envVariable name="NLS_NUMERIC_CHARACTERS" value=",."/>
 </environment>For this one to work, the application must set RP2RROREPORTSENV=MYENV before launching the report.

Oracle.sql.ARRAY error "Non supported character set: oracle-character-set-"

Hi Folks,
I am getting error :
java.sql.SQLException: Non supported character set: oracle-character-set-178
at oracle.gss.util.NLSError.throwSQLException(NLSError.java:46)
in the following code :
Object[] arrayToPassToDB=new Object[7];
ArrayDescriptor arraydesc = ArrayDescriptor.createDescriptor(arrayDesc,con);
ARRAY array = null;
array = new ARRAY(arraydesc, con, arrayToPassToDB);
i am using jdk1.6 and oracle 10g.
I have copied the orai18n.jar and ojdbc6.jar in WEB-INF\lib directory of my project and also in the Tomcat\lib directory.
can you please help me?
Thanks in advance.

java.sql.SQLException: Non supported character set:oracle-character-set-178

Inserting and retrieving data from a al32UTF8 database USING SQL Developer

hi guys,
Before i post my questions , i think its better for me to provide you guys with my understandings first so that it easier to understand where/if i have gone wrong..
I am using Window XP and Oracle 10g
Non-unicode client - a client program that need to use the OS code page for mapping of the retrieved unicode data from the database as well as the support of displaying/inserting the characters from that code page to the database.
E.G sqlplusw.exe
Therefore, when using a non-unicode client
1) we have to set the OS code page (Control panel - regional and language setting - advance - language for non unicode program ) to the code page that contain the characters we are going to display/insert.
2) we will also have to set the NLS_LANG characterset to the character set of the code page we are going to insert so that when we do a insert (for e.g in thai ) , oracle will know, and auto conversion to UNICODE can take place. This is also true when we retrieve unicode data from the database so that conversion to the correct character set can take place.
INSERTING
THAI ---> conversion ----> UNICODE
RETRIEVING
THAI <---- conversion <---- UNICODE
I hope my basic understanding is correct up till this point.
Unicode client - a client program that supports the displaying/inserting of unicode characters without the need of setting the OS code page (Control panel - regional and language setting - advance - language for non unicode program )
E.G isqlplus http or SQL developer
However,
1) There is still a need to set the NLS_LANG so that correct conversion can take place between the client and the database.
For e.g, when retrieving if we set the NLS_LANG character set to ZHS16GBK (chinese) and the data store in unicode in database is E.G (THAI) , then the conversion would be wrong .
Since it is a unicode supported client, then the NLS_LANG character set should be set to UNICODE as well.
Here come my questions
*Important - please help if you are busy and have no other time to answer the rest of the questions
*Q1) If i were to use a unicode client, what should i set my NLS_LANG character set to ?
AMERICAN_AMERICA.UTF8 ?
*Q2) Where do i set the NLS_LANG character set information in SQL Developer, i know there is a metalink for setting NLS_LANG using isqlplus but i cant seems to google any result for SQL developer.
Q3) Is my basic understanding right until this point ? If not, please explain in a more generalised term as i am really not familiar with character sets, code page, unicode , glyphs and fonts..
Q4) If a unicode client does not need to refer to the OS code page (set in regional and language) , is there a UNICODE code page for the client to refer to , or is there any Window API available ?
Q5)
There is still a need to set the NLS_LANG so that correct conversion can take place between the client and the >>database.
For e.g, when retrieving if we set the NLS_LANG character set to ZHS16GBK (chinese) and the data store in >>unicode in database is E.G (THAI) , then the conversion would be wrong .am i right on this point for UNICODE supported client ?
Thanks for spending time to read my questions and i hope to hear advices from you guys soon.
Million thanks again for sharing.
Best Regards,
Noob but willing to learn

The requirement to always set NLS_LANG is not true for JDBC, which ignores NLS_LANG altogether. Java programs fetch text data into String variables, which use Unicode UTF-16 by design. JDBC sets character set conversion so that data is converted between UTF-16 and the database or national character set.
The requirement to set NLS_LANG is not generally true for OCI, either. The first call in an OCI problem can be OCIEnvNlsCreate(). This call has two parameters that allow the caller to define the character set to use for VARCHAR2/CHAR/LONG/CLOB/statement text and the character set to use for NVARCHAR2/NCHAR/NCLOB. Only if these character sets are specified as 0, NLS_LANG character set is used. Also, OCI programs can specify different character sets for each bind or define variable (i.e. input/output buffer). Note: OCI programs always use NLS_LANG to initialize the language and territory settings for the client program and the database session. Only the character set can be specified is OCIEnvNlsCreate().
OCIEnvNlsCreate() can specify the client character set as UTF-16 (in platform endianess). This is not possible with NLS_LANG.
Various interfaces building on OCI, such as Oracle ODBC and ODP .NET, explicitly initialize OCI with Unicode character set, and thus ignore the NLS_LANG character set as well.
Thnx,
Sergiusz

Character set problems with xmltype and SQLdeveloper

Hi all,
Using SQL DEveloper v.3.2.20.09 on Windows XP and connecting to Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production.
SQL Developer encoding is set to Cp1252 (my understanding is this has nothing to do with nls_lang and used for encoding of files in sqldeveloper)
SQL Developer NLS Language params set to Canada English.
Database NLS parameters are:
"PARAMETER" "VALUE"
"NLS_LANGUAGE" "AMERICAN"
"NLS_TERRITORY" "AMERICA"
"NLS_CURRENCY" "$"
"NLS_ISO_CURRENCY" "AMERICA"
"NLS_NUMERIC_CHARACTERS" ".,"
"NLS_CHARACTERSET" "AL32UTF8"
"NLS_CALENDAR" "GREGORIAN"
"NLS_DATE_FORMAT" "DD-MON-RR"
"NLS_DATE_LANGUAGE" "AMERICAN"
"NLS_SORT" "BINARY"
"NLS_TIME_FORMAT" "HH.MI.SSXFF AM"
"NLS_TIMESTAMP_FORMAT" "DD-MON-RR HH.MI.SSXFF AM"
"NLS_TIME_TZ_FORMAT" "HH.MI.SSXFF AM TZR"
"NLS_TIMESTAMP_TZ_FORMAT" "DD-MON-RR HH.MI.SSXFF AM TZR"
"NLS_DUAL_CURRENCY" "$"
"NLS_COMP" "BINARY"
"NLS_LENGTH_SEMANTICS" "BYTE"
"NLS_NCHAR_CONV_EXCP" "FALSE"
"NLS_NCHAR_CHARACTERSET" "AL16UTF16"
"NLS_RDBMS_VERSION" "11.2.0.2.0"
I didn't have an NLS_LANG user env variable set, so i set it to "AMERICAN_AMERICA.WE8MSWIN1252"
Problem i'm having is editing my xmltype data... i have some french accented characters in there, but when saved through SQLDeveloper, they come out as:
Étape par étape -> Ã‰tape par Ã©tape
I do have an encoding on the xml file in the xmltype column set to UTF-8... but from what i read, this has no effect when reading or writing in 11g...
I ran a dump(col, 1016) on my table and got the following:
Typ=58 Len=2037: 0,0,0,1,10,4,8c,a8,0,0,0,1,10,8c,ff,b8,0,0,0,1,11,2,2,f8,0,0,0,1,10,e1,a9,20,3b,9a,ca,0,0,0,f,a0,0,0,f,a0,0,1,0,4,0,0,0,1,9,84,d5,24,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,1,10,f,93,48,0,0,0,1,10,88,0,8,40,b3,8f,0,0,0,1,41,0,0,0,0,0,0,0,0,0,0,0,1,10,88,ab,b8,0,0,1,40,0,0,0,0,0,0,0,1,10,88,ab,d8,0,0,0,1,10,f,93,48,0,0,40,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,2,7,6,0,0,0,0,0,0,0,0,0,0,0,0,0,0,40,68,6b,78,73,2d,68,65,61,70,2d,63,0,0,0,0,0,0,7f,ff,7f,ff,80,0,80,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,18,0,0,0,1,10,8d,0,b8,0,0,0,1,10,8d,0,b8,0,0,0,0,0,0,0,28,0,0,0,1,10,8d,0,d0,0,0,0,1,10,8d,0,d0,0,0,0,0,0,0,0,38,0,0,0,1,10,8d,0,e8,0,0,0,1,10,8d,0,e8,0,0,0,0,0,0,0,58,0,0,0,1,10,8d,1,0,0,0,0,1,10,8d,1,0,0,0,0,0,0,0,1,18,0,0,0,1,10,8d,1,18,0,0,0,1,10,8d,1,18,0,0,0,0,0,0,4,18,0,0,0,1,10,8d,1,30,0,0,0,1,10,8d,1,30,0,0,0,0,0,0,10,18,0,0,0,1,10,8d,1,48,0,0,0,1,10,8d,1,48,d0,b3,8f,0,0,0,fe,a9,0,0,0,1,10,8d,0,18,0,0,0,1,10,f,94,e0,0,0,0,1,10,ff,aa,98,0,0,0,1,10,8d,8,98,d0,b3,8f,0,0,0,7,1,0,0,0,0,0,0,0,0,0,0,0,1,10,8d,8,b8,0,0,0,1,10,f,84,48,0,0,0,1,10,8d,8,c0,0,b3,8f,0,0,0,0,31,0,0,0,0,0,0,0,0,0,0,0,1,8,fc,ac,8,d0,b3,8f,0,0,0,fe,41,0,0,0,1,10,8d,1,58,0,0,0,1,10,f,93,48,0,0,0,1,10,f,83,a0,0,0,0,1,11,35,a9,0,d0,b3,8f,0,0,0,fe,19,0,0,0,0,0,0,0,0,0,0,0,1,10,f,84,48,0,0,0,1,10,f,84,48,50,0,4,1,0,0,0,18,0,0,0,58,0,4,1,0,0,0,30,0,0,0,60,0,4,1,0,0,0,48,0,0,0,68,0,4,1,0,0,0,60,0,0,0,70,0,4,1,0,0,0,78,0,0,0,78,0,1,1,0,0,0,90,0,0,0,90,0,2,2,0,0,0,a8,0,0,0,a8,0,17,1,1,3,69,2,0,0,0,d0,0,0,0,c0,0,11,1,1,3,69,2,0,0,0,f8,0,0,0,d8,0,20,1,1,3,69,2,0,0,1,20,0,0,1,0,0,14,1,1,3,69,2,0,0,1,48,0,0,1,18,0,40,1,1,3,69,2,0,0,1,70,0,0,1,60,0,28,1,1,3,69,2,0,0,1,98,0,0,1,90,0,3f,1,1,3,69,2,0,0,1,c0,0,0,1,d0,0,1a,1,1,3,69,2,0,0,1,e8,0,0,1,f0,0,28,1,1,3,69,2,0,0,2,10,0,0,2,20,0,2b,1,1,3,69,2,0,0,2,38,0,0,2,50,0,33,1,1,c0,b3,8f,0,0,0,10,81,0,0,0,1,10,8d,1,58,0,0,0,1,10,f,93,48,0,0,0,1,10,8d,4d,30,0,0,0,1,10,8d,13,88,d0,b3,8f,0,0,0,10,59,0,0,0,0,0,0,0,0,0,0,0,1,10,8d,13,a8,0,0,0,1,11,0,98,88,0,0,0,1,10,8d,13,c8,0,b3,8f,0,0,0,0,41,0,0,0,0,0,0,0,0,0,0,0,1,8,fc,ac,8,0,0,0,0,0,0,0,0,0,0,0,1,10,8d,3,c0,80,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,b3,8f,0,0,0,0,29,0,0,0,1,10,8d,3,40,0,0,0,1,8,fc,ac,50,0,0,0,b7,0,2,43,31,0,0,0,0,0,0,0,0,0,b3,8f,0,0,0,0,99,0,0,0,1,10,8d,3,80,0,0,0,1,9,10,e7,50,1,0,0,0,0,0,0,0,0,0,0,b7,0,0,0,0,0,0,0,0,0,0,0,0,0,2,0,0,0,0,0,0,0,0,0,0,0,0,0,0,7,0,0,0,7,c7,bf,b8,c0,b3,8f,0,0,0,18,79,0,0,0,1,10,8d,1,58,0,0,0,1,10,f,93,48,0,0,0,0,0,0,0,0,0,0,0,1,10,8d,1c,80,d0,b3,8f,0,0,0,18,51,0,0,0,0,0,0,0,0,0,0,0,1,10,8d,1c,a0,0,0,0,1,10,f,84,48,0,0,0,1,10,8d,1c,a8,10,b3,8f,0,0,0,18,29,0,0,0,0,0,0,0,0,0,0,0,1,8,fb,fe,44,0,0,0,0,0,0,0,0,0,0,0,1,10,8d,1c,68,0,0,0,0,0,0,0,0,0,30,0,30,0,0,0,4,0,0,0,1,10,8d,24,80,0,0,0,1,10,8d,4,88,0,0,0,1,10,8d,4,58,0,0,0,1,10,8d,4,a0,0,0,0,1,10,8d,1c,68,0,0,0,1,10,88,4,f0,0,0,0,1,10,8d,49,38,0,0,0,1,20,0,0,1,0,0,0,0,0,0,0,0,0,0,0,1,10,8d,40,88,0,0,0,1,9,10,e6,5c,0,0,0,1,10,88,6,0,0,0,0,1,10,8d,38,a0,0,0,0,2,10,8d,0,2,0,0,0,0,0,0,0,0,0,0,0,1,10,8d,40,a8,0,b3,8f,0,0,0,0,69,0,0,0,1,10,88,14,c8,0,0,0,1,10,8d,38,a0,0,0,0,2,20,0,0,2,0,0,0,0,0,0,0,0,0,0,0,1,10,8d,40,c8,0,0,0,0,0,0,0,0,0,0,0,1,10,88,14,30,0,0,0,1,10,8d,38,a0,0,0,0,2,0,0,0,2,0,0,0,0,0,0,0,0,0,0,0,1,10,8d,40,e8,0,0,0,0,0,0,0,0,0,b3,8f,0,0,0,0,59,0,0,0,1,10,8d,4,f8,0,0,0,1,8,fd,b9,e0,0,0,0,1,11,0,83,a8,0,0,0,1,11,0,83,a8,0,0,0,1,11,0,83,c0,0,0,0,1,11,0,7b,98,0,0,0,1,10,8d,26,c0,0,0,0,1,10,8d,26,c0,0,0,0,1,8,fd,b9,e0,0,0,8,0,ac,64,61,74,0,b3,8f,0,0,0,4,29,0,0,0,1,10,8d,5,60,0,0,0,1,8,fb,fe,44,0,0,0,0,0,0,0,0,0,0,0,1,10,8d,9,e0,0,0,0,0,0,0,0,0,0,40,0,40,0,0,0,0,0,0,0,1,10,8d,9,f8,0,0,0,1,10,8d,6,0,0,0,0,1,10,8d,5,d0,0,0,0,1,10,8d,6,18,0,0,0,1,10,8d,9,e0,48,45,4d,41,5f,50,52,45,53,45,4e,54,22,23,66,65,35,64,36,61,61,30,35,64,65,62,64,64,65,61,20,23,33,0,0,0,0,0,0,0,2,0,0,4,0,0,0,3,0,0,0,10,44,2,f,a0,1,0,f,d0,41,0,30,d,0,18,d,0,10,0,0,0,0,0,0,3,0,0,0,2,3,80
I find it odd it doesnt tell me what character set is used. If i run a dump 1016 on a varchar2 on the same table, i get:
Typ=1 Len=14 CharacterSet=AL32UTF8: 53,74,65,c3,a9,70,68,61,6e,65,c3,a9,c3,a0
Any ideas? This is frustrating.... xml data gets corrupted everytime it's edited in SQLDeveloper.
Thanks for the help

Thanks for the reply...
create table sample_charset(theString varchar2(2 char), theXml xmltype);
insert into sample_charset values('éà',xmltype('<xml>éà</xml>'));
commit;
select * from sample_charset;
"THESTRING" "THEXML"
"éà" <xml>Ã©Ã </xml>
select dump(theString, 1016) as theStringDump, dump(theXml,1016) as theXmlDump from sample_charset;
"THESTRINGDUMP" "THEXMLDUMP"
"Typ=1 Len=4 CharacterSet=AL32UTF8: c3,a9,c3,a0"
"Typ=58 Len=120: 0,0,0,1,10,4,8c,a8,0,0,0,1,10,e1,a8,60,0,0,0,1,10,dc,36,f8,0,0,0,1,10,95,bf,28,3b,9a,ca,0,0,0,f,a0,0,0,f,a0,0,1,0,4,0,0,0,1,9,84,d5,24,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,1,10,f,91,28,0,0,0,1,10,db,a8,b8"

Change character set

Hi
is anyone can tell me how to change characterset.
i try with alter session but it doesnt work.
thanks

Article from Metalink
Doc ID: Note:66320.1
Subject: Changing the Database Character Set or the Database National Character Set
Type: BULLETIN
Status: PUBLISHED
 Content Type: TEXT/PLAIN
Creation Date: 23-OCT-1998
Last Revision Date: 12-DEC-2003
PURPOSE ======= To explain how to change the database character set or national character set of an existing Oracle8(i) or Oracle9i database without having to recreate the database. 1. SCOPE & APPLICATION ====================== The method described here is documented in the Oracle 8.1.x and Oracle9i documentation. It is not documented but it can be used in version 8.0.x. It does not work in Oracle7. The database character set is the character set of CHAR, VARCHAR2, LONG, and CLOB data stored in the database columns, and of SQL and PL/SQL text stored in the Data Dictionary. The national character set is the character set of NCHAR, NVARCHAR2, and NCLOB data. In certain database configurations the CLOB and NCLOB data are stored in the fixed-width Unicode encoding UCS-2. If you are using CLOB or NCLOB please make sure you read section "4. HANDLING CLOB AND NCLOB COLUMNS" below in this document. Before changing the character set of a database make sure you understand how Oracle deals with character sets. Before proceeding please refer to [NOTE:158577.1] "NLS_LANG Explained (How Does Client-Server Character Conversion Work?)". See also [NOTE:225912.1] "Changing the Database Character Set - an Overview" for general discussion about various methods of migration to a different database character set. If you are migrating an Oracle Applications instance, read [NOTE:124721.1] "Migrating an Applications Installation to a New Character Set" for specific steps that have to be performed. If you are migrating from 8.x to 9.x please have a look at [NOTE:140014.1] "ALERT: Oracle8/8i to Oracle9i Using New "AL16UTF16"" and other referenced notes below. Before using the method described in this note it is essential to do a full backup of the database and to use the Character Set Scanner utility to check your data. See the section "2. USING THE CHARACTER SET SCANNER" below. Note that changing the database or the national character set as described in this document does not change the actual character codes, it only changes the character set declaration. If you want to convert the contents of the database (character codes) from one character set to another you must use the Oracle Export and Import utilities. This is needed, for example, if the source character set is not a binary subset of the target character set, i.e. if a character exists in the source and in the target character set but not with the same binary code. All binary subset-superset relationships between characters sets recognized by the Oracle Server are listed in [NOTE:119164.1] "Changing Database Character Set - Valid Superset Definitions". Note: The varying width character sets (like UTF8) are not supported as national character sets in Oracle8(i) (see [NOTE:62107.1]). Thus, changing the national character set from a fixed width character set to a varying width character set is not supported in Oracle8(i). NCHAR types in Oracle8 and Oracle8i were designed to support special Oracle specific fixed-width Asian character sets, that were introduced to provide higher performance processing of Asian character data. Examples of these character sets are : JA16EUCFIXED ,JA16SJISFIXED , ZHT32EUCFIXED. For a definition of varying width character sets see also section "4. HANDLING CLOB AND NCLOB COLUMNS" below. WARNING: Do not use any undocumented Oracle7 method to change the database character set of an Oracle8(i) or Oracle9i database. This will corrupt the database. 2. USING THE CHARACTER SET SCANNER ================================== Character data in the Oracle 8.1.6 and later database versions can be efficiently checked for possible character set migration problems with help of the Character Set Scanner utility. This utility is included in the Oracle Server 8.1.7 software distribution and the newest Character Set Scanner version can be downloaded from the Oracle Technology Network site, http://otn.oracle.com The Character Set Scanner on OTN is available for limited number of platforms only but it can be used with databases on other platforms in the client/server configuration -- as long as the database version matches the Character Set Scanner version and platforms are either both ASCII-based or both EBCDIC-based. It is recommended to use the newest Character Set Scanner version available from the OTN site. The Character Set Scanner is documented in the following manuals: - "Oracle8i Documentation Addendum, Release 3 (8.1.7)", Chapter 3 - "Oracle9i Globalization Support Guide, Release 1 (9.0.1)", Chapter 10 - "Oracle9i Database Globalization Support Guide, Release 2 (9.2)", Chapter 11 Note: The Character Set Scanner coming with Oracle 8.1.7 and Oracle 9.0.1 does not have a separate version number. It reports the database release number in its banner. This version of the Scanner does not check for illegal character codes in a database if the FROMCHAR and TOCHAR (or FROMNCHAR and TONCHAR) parameters have the same value (i.e. you simulate migration from a character set to itself). The Character Set Scanner 1.0, available on OTN, reports its version number as x.x.x.1.0, where x.x.x is the database version number. This version adds a few bug fixes and it supports FROMCHAR=TOCHAR provided it is not UTF8. The Character Set Scanner 1.1, available on OTN and with Release 2 (9.2) of the Oracle Server, reports its version number as v1.1 followed by the database version number. This version adds another bug fixes and the full support for FROMCHAR=TOCHAR. None of the above versions of the Scanner can correctly analyze CLOB or NCLOB values if the database or the national character set, respectively, is multibyte. The Scanner reports such values randomly as Convertible or Lossy. The version 1.2 of the Scanner will mark all such values as Changeless (as they are always stored in the Unicode UCS-2 encoding and thus they do not change when the database or national character set is changed from one multibyte to another). Character Set Scanner 2.0 will correctly check CLOBs and NCLOBs for possible data loss when migrating from a multibyte character set to its subset. To verify that your database contains only valid codes, specify the new database character set in the TOCHAR parameter and/or the new national character set in the TONCHAR parameter. Specify FULL=Y to scan the whole database. Set ARRAY and PROCESS parameters depending on your system's resources to speed up the scanning. FROMCHAR and FROMNCHAR will default to the original database and national character sets. The Character Set Scanner should report only Changless data in both the Data Dictionary and in application data. If any Convertible or Exceptional data are reported, the ALTER DATABASE [NATIONAL] CHARACTER SET statement must not be used without further investigation of the source and type of these data. In situations in which the ALTER DATABASE [NATIONAL] CHARACTER SET statement is used to repair an incorrect database character set declaration rather than to simply migrate to a new wider character set, you may be advised by Oracle Support Services analysts to execute the statement even if Exceptional data are reported. For more information see also [NOTE:225912.1] "Changing the Database Character Set - a short Overview". 3. CHANGING THE DATABASE OR THE NATIONAL CHARACTER SET ====================================================== Oracle8(i) introduces a new documented method of changing the database and national character sets. The method uses two SQL statements, which are described in the Oracle8i National Language Support Guide: ALTER DATABASE [<db_name>] CHARACTER SET <new_character_set> ALTER DATABASE [<db_name>] NATIONAL CHARACTER SET <new_NCHAR_character_set> The database name is optional. The character set name should be specified without quotes, for example: ALTER DATABASE CHARACTER SET WE8ISO8859P1 To change the database character set perform the following steps. Note that some of them have been erroneously omitted from the Oracle8i documentation: 1. Use the Character Set Scanner utility to verify that your database contains only valid character codes -- see "2. USING THE CHARACTER SET SCANNER" above. 2. If necessary, prepare CLOB columns for the character set change -- see "4. HANDLING CLOB AND NCLOB COLUMNS" below. Omitting this step can lead to corrupted CLOB/NCLOB values in the database. If SYS.METASTYLESHEET (STYLESHEET) is populated (9i and up only) then see [NOTE:213015.1] "SYS.METASTYLESHEET marked as having convertible data (ORA-12716 when trying to convert character set)" for the actions that need to be taken. 3. Make sure the parallel_server parameter in INIT.ORA is set to false or it is not set at all. 4. Execute the following commands in Server Manager (Oracle8) or sqlplus (Oracle9), connected as INTERNAL or "/ AS SYSDBA": SHUTDOWN IMMEDIATE; -- or NORMAL <do a full database backup> STARTUP MOUNT; ALTER SYSTEM ENABLE RESTRICTED SESSION; ALTER SYSTEM SET JOB_QUEUE_PROCESSES=0; ALTER SYSTEM SET AQ_TM_PROCESSES=0; ALTER DATABASE OPEN; ALTER DATABASE CHARACTER SET <new_character_set>; SHUTDOWN IMMEDIATE; -- OR NORMAL STARTUP RESTRICT; 5. Restore the parallel_server parameter in INIT.ORA, if necessary. 6. Execute the following commands: SHUTDOWN IMMEDIATE; -- OR NORMAL STARTUP; The double restart is necessary in Oracle8(i) because of a SGA initialization bug, fixed in Oracle9i. 7. If necessary, restore CLOB columns -- see "4. HANDLING CLOB AND NCLOB COLUMNS" below. To change the national character set replace the ALTER DATABASE CHARACTER SET statement with ALTER DATABASE NATIONAL CHARACTER SET. You can issue both statements together if you wish. Error Conditions ---------------- A number of error conditions may be reported when trying to change the database or national character set. In Oracle8(i) the ALTER DATABASE [NATIONAL] CHARACTER SET statement will return: ORA-01679: database must be mounted EXCLUSIVE and not open to activate - if you do not enable restricted session - if you startup the instance in PARALLEL/SHARED mode - if you do not set the number of queue processes to 0 - if you do not set the number of AQ time manager processes to 0 - if anybody is logged in apart from you. This error message is misleading. The command requires the database to be open but only one session, the one executing the command, is allowed. For the above error conditions Oracle9i will report one of the errors: ORA-12719: operation requires database is in RESTRICTED mode ORA-12720: operation requires database is in EXCLUSIVE mode ORA-12721: operation cannot execute when other sessions are active Oracle9i can also report: ORA-12718: operation requires connection as SYS if you are not connect as SYS (INTERNAL, "/ AS SYSDBA"). If the specified new character set name is not recognized, Oracle will report one of the errors: ORA-24329: invalid character set identifier ORA-12714: invalid national character set specified ORA-12715: invalid character set specified The ALTER DATABASE [NATIONAL] CHARACTER SET command will only work if the old character set is considered a binary subset of the new character set. Oracle Server 8.0.3 to 8.1.5 recognizes US7ASCII as the binary subset of all ASCII-based character sets. It also treats each character set as a binary subset of itself. No other combinations are recognized. Newer Oracle Server versions recognize additional subset/superset combinations, which are listed in [NOTE:119164.1]. If the old character set is not recognized as a binary subset of the new character set, the ALTER DATABASE [NATIONAL] CHARACTER SET statement will return: - in Oracle 8.1.5 and above: ORA-12712: new character set must be a superset of old character set - in Oracle 8.0.5 and 8.0.6: ORA-12710: new character set must be a superset of old character set - in Oracle 8.0.3 and 8.0.4: ORA-24329: invalid character set identifier You will also get these errors if you try to change the characterset of a US7ASCII database that was started without a (correct) ORA_NLSxx parameter. See [NOTE:77442.1] It may be necessary to switch off the superset check to allow changes between formally incompatible character sets to solve certain character set problems or to speed up migration of huge databases. Oracle Support Services may pass the necessary information to customers after verifying the safety of the change for the customers' environments. If in Oracle9i an ALTER DATABASE NATIONAL CHARACTER SET is issued and there are N-type colums who contain data then this error is returned: ORA-12717:Cannot ALTER DATABASE NATIONAL CHARACTER SET when NCLOB data exists The error only speaks about Nclob but Nchar and Nvarchar2 are also checked see [NOTE:2310895.9] for bug [BUG:2310895] 4. HANDLING CLOB AND NCLOB COLUMNS ================================== Background ---------- In a fixed width character set codes of all characters have the same number of bytes. Fixed width character sets are: all single-byte character sets and those multibyte character sets which have names ending with 'FIXED'. In Oracle9i the character set AL16UTF16 is also fixed width. In a varying width character set codes of different characters may have different number of bytes. All multibyte character sets except those with names ending with FIXED (and except Oracle9i AL16UTF16 character set) are varying width. Single-byte character sets are character sets with names of the form xxx7yyyyyy and xxx8yyyyyy. Each character code of a single-byte character set occupies exactly one byte. Multibyte character sets are all other character sets (including UTF8). Some -- usually most -- character codes of a multibyte character set occupy more than one byte. CLOB values in a database whose database character set is fixed width are stored in this character set. CLOB values in an Oracle 8.0.x database whose database character set is varying width are not allowed. They have to be NULL. CLOB values in an Oracle >= 8.1.5 database whose database character set is varying width are stored in the fixed width Unicode UCS-2 encoding. The same holds for NCLOB values and the national character set. The UCS-2 storage format of character LOB values, as implemented in Oracle8i, ensures that calculation of character positions in LOB values is fast. Finding the byte offset of a character stored in a varying width character set would require reading the whole LOB value up to this character (possibly 4GB). In the fixed width character sets the byte offsets are simply character offsets multiplied by the number of bytes in a character code. In UCS-2 byte offsets are simply twice the character offsets. As the Unicode character set contains all characters defined in any other Oracle character set, there is no data loss when a CLOB/NCLOB value is converted to UCS-2 from the character set in which it was provided by a client program (usually the NLS_LANG character set). CLOB Values and the Database Character Set Change ------------------------------------------------- In Oracle 8.0.x CLOB values are invalid in varying width character sets. Thus you must delete all CLOB column values before changing the database character set to a varying width character set. In Oracle 8.1.5 and later CLOB values are valid in varying width character sets but they are converted to Unicode UCS-2 before being stored. But UCS-2 encoding is not a binary superset of any other Oracle character set. Even codes of the basic ASCII characters are different, e.g. single-byte code for "A"=0x41 becomes two-byte code 0x0041. This implies that even if the new varying width character set is a binary superset of the old fixed width character set and thus VARCHAR2/LONG character codes remain valid, the fixed width character codes in CLOB values will not longer be valid in UCS-2. As mentioned above, the ALTER DATABASE [NATIONAL] CHARACTER SET statement does not change character codes. Thus, before changing a fixed width database character set to a varying width character set (like UTF8) in Oracle 8.1.5 or later, you first have to export all tables containing non-NULL CLOB columns, then truncate these tables, then change the database character set and, finally, import the tables back to the database. The import step will perform the required conversion. If you omit the steps above, the character set change will succeed in Oracle8(i) (Oracle9i disallows the change in such situation) and the CLOBs may appear to be correctly legible but as their encoding is incorrect, they will cause problems in further operations. For example, CREATE TABLE AS SELECT will not correctly copy such CLOB columns. Also, after installation of the 8.1.7.3 server patchset the CLOB columns will not longer be legible. LONG columns are always stored in the database character set and thus they behave like CHAR/VARCHAR2 in respect to the character set change. BLOBs and BFILEs are binary raw datatypes and their processing does not depend on any Oracle character set setting. NCLOB Values and the National Character Set Change -------------------------------------------------- The above discussion about changing the database character set and exporting and importing CLOB values is theoretically applicable to the change of the national character set and to NCLOB values. But as varying width character sets are not supported as national character sets in Oracle8(i), changing the national character set from a fixed width character set to a varying width character set is not supported at all. Preparing CLOB Columns for the Character Set Change --------------------------------------------------- Take a backup of the database. If using Advanced Replication or deferred transactions functionality, make sure that there are no outstanding deferred transactions with CLOB parameters, i.e. DEFLOB view must have no rows with non-NULL CLOB_COL column; to make sure that replication environment remains consistent use only recommended methods of purging deferred transaction queue, preferably quiescing the replication environment. Then: - If changing the database character set from a fixed width character set to a varying with character set in Oracle 8.0.x, set all CLOB column values to NULL -- you are not allowed to use CLOB columns after the character set change. - If changing the database character set from a fixed width character set to a varying width character set in Oracle 8.1.5 or later, perform table-level export of all tables containing CLOB columns, including SYSTEM's tables. Set NLS_LANG to the old database character set for the Export utility. Then truncate these tables. Restoring CLOB Columns after the Character Set Change ----------------------------------------------------- In Oracle 8.1.5 or later, after changing the character set as described above (steps 3. to 6.), restore CLOB columns exported in step 2. by importing them back into the database. Set NLS_LANG to the old database character set for the Import utility to avoid IMP-16 errors and data loss. RELATED DOCUMENTS: ================== [NOTE:13856.1] V7: Changing the Database Character Set -- This note has limited distribution, please contact Oracle Support [NOTE:62107.1] The National Character Set in Oracle8 [NOTE:119164.1] Changing Database Character set - Valid Superset definitions [NOTE:118242.1] ALERT: Changing the Database or National Character Set Can Corrupt LOB Values <Note.158577.1> NLS_LANG Explained (How Does Client-Server Character Conversion Work?) [NOTE:140014.1] ALERT: Oracle8/8i to Oracle9i using New "AL16UTF16" [NOTE:159657.1] Complete Upgrade Checklist for Manual Upgrades from 8.X / 9.0.1 to Oracle9i (incl. 9.2) [NOTE:124721.1] Migrating an Applications Installation to a New Character Set Oracle8i National Language Support Guide Oracle8i Release 3 (8.1.7) Readme - Section 18.12 "Restricted ALTER DATABASE CHARACTER SET Command Support (CLOB and NCLOB)" Oracle8i Documentation Addendum, Release 3 (8.1.7) - Chapter 3 "New Character Set Scanner Utility" Oracle8i Application Developer's Guide - Large Objects (LOBs), Release 2 - Chapter 2 "Basic Components" Oracle8 Application Developer's Guide, Release 8.0 - Chapter 6 "Large Objects (LOBs)", Section "Introduction to LOBs" Oracle9i Globalization Guide, Release 1 (9.0.1) Oracle9i Database Globalization Guide, Release 2 (9.2) For further NLS / Globalization information you may start here: [NOTE:150091.1] Globalization Technology (NLS) Library index .
 Copyright (c) 1995,2000 Oracle Corporation. All Rights Reserved. Legal Notices and Terms of Use.
Joel P�rez

Password change fails in SQL Developer with verify function...

A couple of months ago I enforced a password verify function on our 11.2.0.3 databases and also one legacy 10.2.0.4 database.
At the time I tested on my account (which had elevated privileges...doh!). Now some users are hitting expiry, they can't change it via SQL Developer.
If I create a user with 'create session' privilege and set their profile to one that uses the verify function (see both below), I then log in to SQL Developer (we have tried with versions 3.1 (Windows) and 3.2 (Linux) with same failure results.
BTW,.. the password verify function enforces the following:
password must be minimum of 8 characters
password must not be the same as the user name, or user name (1-100)
password must contain at least a single digit
password must contain at least a single character
1. Works = I log into the local server and run command line SQLPlus, type 'password' and update. I can successfully change my password.
2. Fails = I log into the local server and run command line SQLPlus, type 'alter user <me> identified by <newpwd>;' I get:
TEST: SUTEMP > alter user sutemp identified by carport9999;
alter user sutemp identified by carport9999
ERROR at line 1:
ORA-28221: REPLACE not specified
This error is because the account does not have the 'alter user' privilege. I'm okay with this, as I don't want our users having this privilege.
3. I start SQL Developer 3.2, type 'alter user <me> identified by <newpwd>;' I get the same ORA-28221 error as above. That is fine, and as expected.
4. Now in SQL Developer, I type 'password', set a valid password, but I get 'Failed to change password' in the Script Output tab.
I have a database 'after servererror on database' trigger set, and querying the database table it is logging into, I see a record with a date stamp matching my failure with a server_error=28221 (the same as above).
So I'm wondering if I'm doing something wrong here, or if this is a bug in SQL Developer. I don't want standard users having 'alter user' privileges, but I do want to enforce password verification.
I get the same result on three 11.2.0.3 databases (haven't tried any more but suspect same results for others) and one legacy 10.2.0.4 database, and using SQL Developer 3.1 and 3.2.
DBA_PROFILE used:
PROFILE
RESOURCE_NAME
RESOURCE LIMIT
CTRU
COMPOSITE_LIMIT
KERNEL DEFAULT
CTRU
SESSIONS_PER_USER
KERNEL 10
CTRU
CPU_PER_SESSION
KERNEL DEFAULT
CTRU
CPU_PER_CALL
KERNEL DEFAULT
CTRU
LOGICAL_READS_PER_SESSION KERNEL DEFAULT
CTRU
LOGICAL_READS_PER_CALL
KERNEL DEFAULT
CTRU
IDLE_TIME
KERNEL DEFAULT
CTRU
CONNECT_TIME
KERNEL DEFAULT
CTRU
PRIVATE_SGA
KERNEL DEFAULT
CTRU
FAILED_LOGIN_ATTEMPTS
PASSWORD 10
CTRU
PASSWORD_LIFE_TIME
PASSWORD 180
CTRU
PASSWORD_REUSE_TIME
PASSWORD DEFAULT
CTRU
PASSWORD_REUSE_MAX
PASSWORD 5
CTRU
PASSWORD_VERIFY_FUNCTION PASSWORD VERIFY_FUNCTION_11G
CTRU
PASSWORD_LOCK_TIME
PASSWORD .002
CTRU
PASSWORD_GRACE_TIME
PASSWORD 21
16 rows selected.
Verify Function used:
$ cat utlpwdmg.sql
Rem
Rem $Header: utlpwdmg.sql 02-aug-2006.08:18:05 asurpur Exp $
Rem
Rem utlpwdmg.sql
Rem
Rem Copyright (c) 2006, Oracle. All rights reserved.
Rem
Rem NAME
Rem utlpwdmg.sql - script for Default Password Resource Limits
Rem
Rem DESCRIPTION
Rem This is a script for enabling the password management features
Rem by setting the default password resource limits.
Rem
Rem NOTES
Rem This file contains a function for minimum checking of password
Rem complexity. This is more of a sample function that the customer
Rem can use to develop the function for actual complexity checks that the
Rem customer wants to make on the new password.
Rem
Rem MODIFIED (MM/DD/YY)
Rem suren 05/09/13 - customise for NIHI use
Rem asurpur 05/30/06 - fix - 5246666 beef up password complexity check
Rem nireland 08/31/00 - Improve check for username=password. #1390553
Rem nireland 06/28/00 - Fix null old password test. #1341892
Rem asurpur 04/17/97 - Fix for bug479763
Rem asurpur 12/12/96 - Changing the name of password_verify_function
Rem asurpur 05/30/96 - New script for default password management
Rem asurpur 05/30/96 - Created
Rem
-- This script sets the default password resource parameters
-- This script needs to be run to enable the password features.
-- However the default resource parameters can be changed based
-- on the need.
-- A default password complexity function is also provided.
-- This function makes the minimum complexity checks like
-- the minimum length of the password, password not same as the
-- username, etc. The user may enhance this function according to
-- the need.
-- This function must be created in SYS schema.
-- connect sys/<password> as sysdba before running the script
CREATE OR REPLACE FUNCTION verify_function_11G
(username varchar2,
password varchar2,
old_password varchar2)
RETURN boolean IS
 n boolean;
 m integer;
 differ integer;
 isdigit boolean;
 ischar boolean;
 ispunct boolean;
 db_name varchar2(40);
 digitarray varchar2(20);
 punctarray varchar2(25);
 chararray varchar2(52);
 i_char varchar2(10);
 simple_password varchar2(10);
 reverse_user varchar2(32);
BEGIN
 digitarray:= '0123456789';
 chararray:= 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ';
 -- Check for the minimum length of the password
 IF length(password) < 8 THEN
 raise_application_error(-20001, 'Password length less than 8');
 END IF;
 -- Check if the password is same as the username or username(1-100)
 IF NLS_LOWER(password) = NLS_LOWER(username) THEN
 raise_application_error(-20002, 'Password same as or similar to user');
 END IF;
 FOR i IN 1..100 LOOP
 i_char := to_char(i);
 if NLS_LOWER(username)|| i_char = NLS_LOWER(password) THEN
 raise_application_error(-20005, 'Password same as or similar to user name ');
 END IF;
 END LOOP;
 -- Check if the password contains at least one letter, one digit
 -- 1. Check for the digit
 isdigit:=FALSE;
 m := length(password);
 FOR i IN 1..10 LOOP
 FOR j IN 1..m LOOP
 IF substr(password,j,1) = substr(digitarray,i,1) THEN
 isdigit:=TRUE;
 GOTO findchar;
 END IF;
 END LOOP;
 END LOOP;
 IF isdigit = FALSE THEN
 raise_application_error(-20008, 'Password must contain at least one digit, one character');
 END IF;
 -- 2. Check for the character
 <<findchar>>
 ischar:=FALSE;
 FOR i IN 1..length(chararray) LOOP
 FOR j IN 1..m LOOP
 IF substr(password,j,1) = substr(chararray,i,1) THEN
 ischar:=TRUE;
 GOTO endsearch;
 END IF;
 END LOOP;
 END LOOP;
 IF ischar = FALSE THEN
 raise_application_error(-20009, 'Password must contain at least one digit, and one character');
 END IF;
 <<endsearch>>
 -- Check if the password differs from the previous password by at least
 -- 3 letters
 IF old_password IS NOT NULL THEN
 differ := length(old_password) - length(password);
 differ := abs(differ);
 IF differ < 3 THEN
 IF length(password) < length(old_password) THEN
 m := length(password);
 ELSE
 m := length(old_password);
 END IF;
 FOR i IN 1..m LOOP
 IF substr(password,i,1) != substr(old_password,i,1) THEN
 differ := differ + 1;
 END IF;
 END LOOP;
 IF differ < 3 THEN
 raise_application_error(-20011, 'Password should differ from the old password by at least 3 characters');
 END IF;
 END IF;
 END IF;
 -- Everything is fine; return TRUE ;
 RETURN(TRUE);
END;
alter profile ctru limit password_verify_function verify_function_11g;
alter profile default limit password_verify_function verify_function_11g;
alter profile web_and_it limit password_verify_function verify_function_11g;

okay,... I just saw another website which shows I should put in the 'replace <oldpwd>' clause in.
This works in SQL Developer: alter user sutemp identified by carport999 replace garage999;
So why does the 'password' command fail? (Developers: it would also be helpful to have the ORA- error displayed as opposed to 'Failed to change password')

한글이 ??? 로 DISPLAY 되는 경우(CHARACTER SET)

제품 : SQL*PLUS
작성날짜 : 1996-07-02
한글이 ??? 로 DISPLAY 되는 경우(CHARACTER SET)
=============================================
Oracle Tools(SQL*Plus, Forms 30, Forms 40, Reports 20 등)을 이용하여 한글
DATA를 조회할 때 ???로 출력되는 경우 해결 방법.
DATABASE는 SQL COMMAND 'CREATE DATABASE'를 포함하는 STATEMENT를 수행할
때 만들어지는데 우리가 그 STATEMENT를 수행하기 앞서 고려해야 할 사항 중의
하나가 DB CHARACTERSET이다.
DB를 CREATE할 때 DATABSE CHARACTERSET을 명시해야만 하는데, 한번 선택되고
난 후에는 CHARACTER SET을 변경하는 것은 쉽지가 않다.
DATA DICTIONARY에 있는 DATA를 포함해서 모든 DATA는 선택된 CHARACTERSET에
의해 입출력 되기 때문에 USER가 다른 CHARACTERSET으로 ACCESS한다면 한글 데이
타가 ???로 출력된다.
또한, 분산 DB 환경이나 UPGRADE할 경우에는 DATABASE CHARACTERSET이 같아야
하므로, 사용자들은 DATABASE의 CHARACTERSET을 알아 두어야 한다.
< 현재 DATABASE 의 CHARACTERSET 확인 및 변경 >
1. 데이타베이스 CHARACTERSET 확인
$ sqldba lmode=y
SQLDBA> connect internal
SQLDBA> select * from v$nls_parameters;
PARAMETER VALUE
NLS_CHARACTERSET KO16KSC5601 (or US7ASCII)
(A)
2. 환경 변수의 NLS_LANG 확인
$ env
NLS_LANG=American_America.US7ASCII
(B)
위의 (A)와 (B)가 동일한 경우에만 한글 데이타 처리에 문제가 없으며, 이것이
서로 다른 상태에서 한글 데이타를 조회할 경우에는 ??? 로 출력 된다.
3. CHARACTERSET을 일치시키는 방법
* NLS_LANG 환경 변수를 변경하여 일치시키는 방법
<UNIX>
Bourne shell, k-shell을 사용하는 경우 .profile을 수정한다.
NLS_LANG = American_Amerca.KO16KSC5601; export NLS_LANG
c-chell을 사용하는 경우 .cshrc 혹은 .login 수정
setenv NLS_LANG American_America.KO16KSC5601
수정 후 다시 $env를 실행하여 변경되었는지 확인한다.
<WINDOWS 3.1>
C:\WINDOWS\ORACLE.INI 수정
NLS_LANG=American_America.KO16KSC5601
WINDOW 재기동
<WINDOWS 95>
WINDOWS 95에서는 NLS_LANG이 ORACLE.INI에 들어있지 않고
REGISTRY에 기록되므로 REGISTRY EDITOR를 이용하여 수정해야 한다.
MS DOS 창으로 나가서 REGEDIT.EXE 실행
또는
시작 -> 실행 -> regedit -> HKEY_LOCAL_MACHINE -> SOFTWARE -> ORACLE
오른쪽 마우스 버튼을 이용하여 NLS_LANG을 수정한다.
REGISTRY 변경 후에 PC를 REBOOTING 할 필요는 없습니다.
<WINDOWS NT>
WINDOWS NT 에서도 WINDOWS 95의 경우와 마찬가지로 REGISTRY에 기록된
정보를 변경해 주면 됩니다. 다음과 같이 합니다.
DOS 창에서 REGEDT32.EXE 실행
HKEY_LOCAL_MACHINE -> SOFTWARE -> ORACLE 선택
메뉴를 선택하여 NLS_LANG을 수정
* 서로 다른 character set 을 갖는 DB를 access 하는 client에서는 다음과
같은 setting 을 하면 편리합니다.
예를 들어서 SERVER의 character set이 US7ASCII이고 PC의 NLS_LANG이
American_America.KO16KSC5601과 같이 서로 다르게 설정되어 있는 경우
다음을 각 client의 환경에 추가하면 한글 문제가 해결됩니다.
ORA_NLS_CHARACTERSET_CONVERSION=NO_CHARACTER_SET_CONVERSION

두 디비가 다른 캐랙터 셋을 쓴다고 해도
디비 자체에는 문제가 없다고 보는데 말이죠..
두 플렛폼을 비교한번해보시고요.
그래도 문제가 생긴다면 님 말씀 대로 바꿔보심이.
위에건 그냥 보시라는거고
중요한건 imp,exp할때 약간 조정이 필요할거 같은데 말이죠.

Changing CHARACTER SET in OracleXE

Because this is my first post in this forum I like to say first "Hello" !
I do my first steps after installing OracleXE (OracleXEUnv.exe). In the database informations I saw that the Character Set (NLS_CHARACTERSET) is "AL32UTF8"., but I want to change it to "WE8MSWIN1252".
When I tried the SQL command "ALTER DATABASE CHARACTER SET WE8MSWIN1252;" but the system shows the message "ORA-12712: Der neue Zeichensatz muss eine Obermenge des alten Zeichensatzes sein".
How can I change the NLS_CHARACTERSET parameter ? Could it be that I have to deinstall this version und use instand the western european version (OracleXE.exe) ?
Kind regards, Michael

Could it be that I have to deinstall this version und
use instand the western european versionYup. You already knew the answer :)

HOW TO: Open SQL Developer from a batch file with specific tables opened

I use SQL Developer daily as I develop database intensive programs.
** Question **
How can I define a specific configuration of tabs (i.e. tables, procedures, etc) to be opened upon startup of SQL Developer?
For example, creating a .BAT file to open SQL Developer with a specific set of table tabs already opened. This will save me the time every morning I use to open SQL Developer and configure all the tables I need opened.
NOTE: I have tried various options of appending a table name to a command line starting sqldeveloper.exe. For example: ..\sqldeveloper.exe mydatabase.mytable. However, this only opens a worksheet tab with the name "mydatabase.mytable" but does not open my actual table.
Any help will be appreciated.
- Gary Davis

what version are you using? Sql Dev 1.5?
Not an exact answer, but you could try using Table FILTER
click on your connection
right button on TABLES
click apply filter
as for your question, check out:
Re: EA1 - Automatically open connection list at startup?
or
SQL Developer

Non supported character set: oracle-character-set-41

Hi everyone,
I have a issue while passing a VARRAY from my Java Class to Stored Procedure.
TYPE ERR_DATA_ARRAY AS VARRAY(100) OF VARCHAR2(1000);
In my code i have used ArrayDescriptor and ARRAY class of oracle.
When i run my program in eclipse i get following exception:-
java.sql.SQLException: Non supported character set: oracle-character-set-41
at oracle.gss.util.NLSError.throwSQLException(NLSError.java:46)
at oracle.sql.CharacterSetUnknown.failCharsetUnknown(CharacterSetFactoryThin.java:171)
at oracle.sql.CharacterSetUnknown.convert(CharacterSetFactoryThin.java:135)
at oracle.sql.CHAR.<init>(CHAR.java:159)
at oracle.sql.CHAR.<init>(CHAR.java:183)
at oracle.jdbc.oracore.OracleTypeCHAR.toDatum(OracleTypeCHAR.java:161)
at oracle.jdbc.oracore.OracleType.toDatumArray(OracleType.java:166)
at oracle.jdbc.oracore.OracleTypeCHAR.toDatumArray(OracleTypeCHAR.java:208)
at oracle.sql.ArrayDescriptor.toOracleArray(ArrayDescriptor.java:1517)
at oracle.sql.ARRAY.<init>(ARRAY.java:117)
at com.niit.slims.common.ejb.Array_test.test(Array_test.java:52)
at com.niit.slims.common.ejb.Array_test.main(Array_test.java:20)
I have added ojdbc14.jar.And my working jdk is jdk1.4.
Plz help
Edited by: user10569173 on Dec 8, 2011 3:58 AM

I am not an expert here,
but it seems that since you are using ojdbc14.jar you may actually need the
nls_charset12.jar
instead of the one I suggested previously.
Regards
Peter

SQL Developer vs TOAD: connection stability

I am trying to persuade a group of developers to switch from TOAD to SQL Developer. The feature set of version 1.5 is quite nice; and most of our users don't need the extra bells and whistles of TOAD. However, in side-by-side situations, it seems that TOAD gets better response times. In particular, the connection for SQL Developer sometimes seems to freeze and then come back later, while TOAD does not seem to be affected.
Our DBA thinks that the difference may be from SQL Developer using a JDBC connection while TOAD uses Oracle SQLNET. He said that switching to an LDAP server for name resolution might make the difference; but we really don't have much experience at this level of detail on the connections.
Is anyone else having a similar issue? Has anyone been able to 'equalize' the performance of the two products?
You insights are welcome.

However, in side-by-side situations, it seems that
TOAD gets better response times. In particular, the
connection for SQL Developer sometimes seems to
freeze and then come back later, while TOAD does not
seem to be affected.
Our DBA thinks that the difference may be from SQL
Developer using a JDBC connection ... I think the problem ist not SQL Developer\JDBC itself but rather the Java Runtime Environment. The behavior you describe sounds like that Garbage Collector hits you. SUN trys to make the GC better in each Java version, so I suggest you update your JRE to the newest one you can get(today: 1.6.0_06 from java.sun.com).
After doing that, install "Oracle SQL Developer for Windows, with JDK already installed" to make sure that SQL Dev. use the new one. You can check the used java version within SQL Dev. at the "About" dialog (register: version)
If you are familiar with java you should play with some gc and memory settings. Details about that you find here: http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html
Andreas

Sql developer vs nls_lang/character set

Similar Messages

Maybe you are looking for