We did have one off-the-shelf application (SalesLogix - CRM) complain about UTF8, so we switched it back.
thanks for your prompt reply.
what do you mean by one of your application complain about UTF8 and you have to swich it back??? What did you switch to???
Do you know any issues with changing the characterset to UTF8 or WE8MSWIN1252??????
Also, I read on Asktom and it said we may have to modify the plsql code as follow:
Your plsql routines may will have to change -- your data model may well have to
You'll find that in utf, european characters (except ascii -- 7bit data) all
take 2 bytes. That varchar2(80) you have in your database? It might only hold
40 characters of eurpean data (or even less of other kinds of data). It is 80
bytes (you can use the new 9i syntax varchar2( N char ) -- it'll allocate in
characters, not bytes).
So, you could find your 80 character description field cannot hold 80
You might find that x := a || b; fails -- with string to long in your plsql code
due to the increased size.
You might find that your string intensive routines run slower (substr(x,1,80) is
no longer byte 1 .. byte 80 -- Oracle has to look through the string to find
where characters start and stop -- it is more complex)
chr(10) and chr(13) should work find, they are simple ASCII.
On clob -- same impact as on varchar2, same issues.
Last edited by learning_bee; 03-10-2004 at 02:58 PM.
I export the WE8ISO88559P1 database, below is part of the exp log:
Connected to: Oracle9i Enterprise Edition Release 188.8.131.52.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 184.108.40.206.0 - Production
Export done in WE8ISO8859P1 character set and AL16UTF16 NCHAR character set
so I did create a new database and it's on UTF8, below is the part of my import:
import done in WE8ISO8859P1 character set and AL16UTF16 NCHAR character set
import server uses UTF8 character set (possible charset conversion)
IMP-00046: using FILESIZE value from export file of 1992294400
look like Oracle does the data conversion it self, my import still running with no error yet. Assume the import finish, with no error on the log, will I lose the data at all ??? or I am ok
in addition to this thread, I also had the additional question about the NLS_DATABASE_PARAMETERS. Below is the query about the NLS_DATABASE_PARAMETERS:
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
as you see the data format was in DD-MON_RR, but when I do the query on sysdata from dual I got:
3/11/2004 1:37:18.000 PM
the question is so where this sysdate is driven by??? b/c it's not the same as the data format in NLS_DATABASE_PARAMETERS