I do believe UTF8 is variable-width. For performance in some
applications, a fixed-width character set may be preferable. as far as i
can tell, that's the reason to use anything else...
.n.
Zorg Adam hath momely rade gribble:
: I am going through the same exact exercise. It appears that the national
: character set has to be a subset of the database character set(?). If this
: is true, then maybe the database character set should be UTF8 and the
: National Character set should ASCII. Anyway, to insert data, you can do
: this: insert into foo values (n'ascii to be stored in an UTF8
: olumn'); --Note the "n".
: I too would like to hear :
: 1. Is anyone doing this.
: 2. Is there a reason to? Considering it is possible to create a database
: with UTF8 and never store a multi-byte language (and thus not having a
: storage consideration), is there a performance impact for doing so. If not,
: why wouldn't you always build an UTF8 database so that it would be easier to
: support foreign languages in the future?
: 3. Do I have to use the nls_charset library with JDBC to use the nvarchar2
: datatype?
: I hope this helps you. I would be happy to exchange information on
: this...Thanks
: "tiny anklet bells" <nroshak_at_hcs.harvard.edu> wrote in message
: news:89mfp2$bei$2_at_news.fas.harvard.edu...
:> Is anyone out there running a database that stores NCHAR data in a
:> different character set than the overall character set? If so, please
:> help me out here.
:>
:> Recently we decided that our testing database needed to store NCHAR and
:> NVARCHAR data in a UTF8 national character set. The database was built
:> with US7ASCII character set. I did ALTER DATABASE SET NATIONAL
:> CHARACTERSET "UTF8" (etc), and the data is being stored and read
:> correctly.
:>
:> The question is: How do you get fresh NCHAR data into the database when
:> the character set != the national character set? The Oracle NLS
:> documentation says, "Because SQL text such as the literals in SQL
:> statements can only be represented by the database character set, and not
:> the NCHAR character set, you should choose an NCHAR character set that
:> either has an equivalent or subset character repertoire of the database
:> character set." That is, we cannot input UTF8 literals into the database
:> (either through SQL*Plus or through SQL statements passed by the
:> application we're testing).
:>
:> Now I -know- there must be people out there who use a different NATIONAL
:> CHARACTER SET than their CHARACTER SET -- otherwise what's the point of
:> having NCHAR data at all? So there -must- be a way to get fresh NCHAR
:> data into our tables. The question is, how the heck do you do it???
:>
:> At the moment, the only solution we've come up with is to put the UTF data
:> into a flat file and import it using SQL*Loader. Yuck, yuck, uuugly.
:> Please, post and let me know what the "standard" way is, or how you've
:> been doing it.
:>
:> TIA,
:> Natalka Roshak
:> --
:> He stands proud in his uniform
:> He knows he's made it now
:> He's been told he'll be a hero
:> But he hasn't been told how
:> He receives his plastic key to heaven
:> Takes his holy vow
:> Then he turns,
:> Then he's gone
:> --Peter Ulrich, "Taqaharu's Leaving"
--
He stands proud in his uniform
He knows he's made it now
He's been told he'll be a hero
But he hasn't been told how
He receives his plastic key to heaven
Takes his holy vow
Then he turns,
Then he's gone
--Peter Ulrich, "Taqaharu's Leaving"
Received on Wed Mar 08 2000 - 00:00:00 CST