Re: PL/SQL: Using Unicode Datatypes.

linevoltage_halogen wrote:

> I have RTFM and still am confused. Any help would be greatly
> appreciated.
>
> From
> Oracle® Database Globalization Support Guide
> 10g Release 1 (10.1)
> Part Number B10749-02
>
>
> "Your SQL statements and PL/SQL code contain Unicode data. You must
> use a Unicode database. SQL statements and PL/SQL code are converted
> into the database character set before being processed. If the SQL
> statements and PL/SQL code contain characters that cannot be converted
> to the database character set, then those characters are lost. A
> common place to use Unicode data in a SQL statement is in a string
> literal."
>
> I want my database to be able to store Unicode data, specifically I
> want to do it through Unicode Datatypes instead of a Unicode database.
> I have many reasons for this with the major one being I only need a
> handful of columns to support this data type. From the excerpt above
> it seems that I will run into problems if I stay with my 8bit western
> encoding and choose AL16UTF16 as my national character set if I used
> stored packages and procedures?
>
> If anyone can obviate this for me it would be greatly appreciated.

I think you'll be fine. Read it again: SQL *statements* and PL/SQL *code* are converted to the database's character set. Data isn't converted at all, according to that statement. All that is really saying is that if you store one or two columns of weirdness in NVARCHAR2's, relying on your UTF16 national character set, your SQL and PL/SQL code will continue to run in 8-bit ISO8859P1. That's quite standard, and would not involve data loss.

Don't, in other words, expect to be able to knock up a procedure or function in Serbo-croat, Kanji or tagalog any time soon, though data stored in any of those languages will be fine.

Probably.

But, as ever, the only way you can really gain assurance on that is to create a small test case, with a 8ISO/UTF16 database, a couple of tables, and some sample stored procedures.

Regards
HJR Received on Mon Oct 25 2004 - 18:05:28 CDT