 | |
Problem with Unicode Strings
comp.databases.oracle.misc comp.databases.oracle.misc
 |
| | Thread Tools | Display Modes |
#11
 
| |||
| |||
|
Re: Problem with Unicode Strings -
04-16-2008
, 07:44 AM
|
"Carlos" <miotromailcar... (AT) netscape (DOT) net> schrieb im Newsbeitragnews:c03f11e2-8cd4-41ff-bba6-b0a0f6c3c7e7 (AT) m3g2000hsc (DOT) googlegroups.com... On Apr 15, 3:04 pm, "André Hartmann" <andrehartm... (AT) hotmail (DOT) com wrote:>I cannot see the point of storing UNICODE (UTF8? UTF16?) in a WE8MSWIN1252 database... (you don't specify the NLSupport codepage for NVARCHARS/NCHARS) The DB codepage should be unicode (AL32UTF8). Hi, if that is so (unicode cannot be stored into databases that do not have a unicode character set) then why can I create tables with unicode columns (NCHAR, NVARCHAR2, NCLOB) in such databases? Wouldnt it be more appropriate then for Oracle to cast errors when trying so? To say it the other way round, the sheer fact that it is possible to declare unicode columns in the database implied to me that it is possible to store such values. Am I wrong here? André  |
AL16UTF16 for these ones.
Can you confirm?
Cheers.
Carlos.
#12
| |||
| |||
|
|
"Carlos" <miotromailcar... (AT) netscape (DOT) net> schrieb im Newsbeitragnews:c03f11e2-8cd4-41ff-bba6-b0a0f6c3c7e7 (AT) m3g2000hsc (DOT) googlegroups.com... On Apr 15, 3:04 pm, "André Hartmann" <andrehartm... (AT) hotmail (DOT) com wrote:>I cannot see the point of storing UNICODE (UTF8? UTF16?) in a WE8MSWIN1252 database... (you don't specify the NLSupport codepage for NVARCHARS/NCHARS) The DB codepage should be unicode (AL32UTF8). Hi, if that is so (unicode cannot be stored into databases that do not have a unicode character set) then why can I create tables with unicode columns (NCHAR, NVARCHAR2, NCLOB) in such databases? Wouldnt it be more appropriate then for Oracle to cast errors when trying so? To say it the other way round, the sheer fact that it is possible to declare unicode columns in the database implied to me that it is possible to store such values. Am I wrong here? André |
AL16UTF16 for these ones.
Can you confirm?
Cheers.
Carlos.
#13
| |||
| |||
|
|
"Carlos" <miotromailcar... (AT) netscape (DOT) net> schrieb im Newsbeitragnews:c03f11e2-8cd4-41ff-bba6-b0a0f6c3c7e7 (AT) m3g2000hsc (DOT) googlegroups.com... On Apr 15, 3:04 pm, "André Hartmann" <andrehartm... (AT) hotmail (DOT) com wrote:>I cannot see the point of storing UNICODE (UTF8? UTF16?) in a WE8MSWIN1252 database... (you don't specify the NLSupport codepage for NVARCHARS/NCHARS) The DB codepage should be unicode (AL32UTF8). Hi, if that is so (unicode cannot be stored into databases that do not have a unicode character set) then why can I create tables with unicode columns (NCHAR, NVARCHAR2, NCLOB) in such databases? Wouldnt it be more appropriate then for Oracle to cast errors when trying so? To say it the other way round, the sheer fact that it is possible to declare unicode columns in the database implied to me that it is possible to store such values. Am I wrong here? André |
AL16UTF16 for these ones.
Can you confirm?
Cheers.
Carlos.
#14
| |||
| |||
|
|
"Carlos" <miotromailcar... (AT) netscape (DOT) net> schrieb im Newsbeitragnews:c03f11e2-8cd4-41ff-bba6-b0a0f6c3c7e7 (AT) m3g2000hsc (DOT) googlegroups.com... On Apr 15, 3:04 pm, "André Hartmann" <andrehartm... (AT) hotmail (DOT) com wrote:>I cannot see the point of storing UNICODE (UTF8? UTF16?) in a WE8MSWIN1252 database... (you don't specify the NLSupport codepage for NVARCHARS/NCHARS) The DB codepage should be unicode *(AL32UTF8). * Hi, if that is so (unicode cannot be stored into databases that do not have a unicode character set) then why can I create tables with unicode columns (NCHAR, NVARCHAR2, NCLOB) in such databases? Wouldnt it be more appropriate then for Oracle to cast errors when trying so? To say it the other way round, the sheer fact that it is possible to declare unicode columns in the database implied to me that it is possible to store such values. Am I wrong here? |
way, way helpful and way, way, way friendly about converting from one
character set to another. Most tools honor that, but some don't. But
the general way to not get the conversion is to have the proper NLS
environment, as well as the proper character set. In general, using a
character set that does not support what you are putting into it will
cause you grief one way or another. Unicode is designed to handle any
sets (subject to which Unicode you are using - there are many version-
dependent issues about that).
It is not an error because it is a feature for Oracle to be able to
handle different character sets. That puts it upon you to understand
the implications. Please read the docs about globalization, as well
as the metalink docs that help you understand NLS. It can get quite
involved, though usually the answer for a particular situation winds
up being simple.
jg
--
@home.com is bogus.
http://paulschreiber.com/blog/2008/0...n-translation/
#15
| |||
| |||
|
|
"Carlos" <miotromailcar... (AT) netscape (DOT) net> schrieb im Newsbeitragnews:c03f11e2-8cd4-41ff-bba6-b0a0f6c3c7e7 (AT) m3g2000hsc (DOT) googlegroups.com... On Apr 15, 3:04 pm, "André Hartmann" <andrehartm... (AT) hotmail (DOT) com wrote:>I cannot see the point of storing UNICODE (UTF8? UTF16?) in a WE8MSWIN1252 database... (you don't specify the NLSupport codepage for NVARCHARS/NCHARS) The DB codepage should be unicode *(AL32UTF8). * Hi, if that is so (unicode cannot be stored into databases that do not have a unicode character set) then why can I create tables with unicode columns (NCHAR, NVARCHAR2, NCLOB) in such databases? Wouldnt it be more appropriate then for Oracle to cast errors when trying so? To say it the other way round, the sheer fact that it is possible to declare unicode columns in the database implied to me that it is possible to store such values. Am I wrong here? |
way, way helpful and way, way, way friendly about converting from one
character set to another. Most tools honor that, but some don't. But
the general way to not get the conversion is to have the proper NLS
environment, as well as the proper character set. In general, using a
character set that does not support what you are putting into it will
cause you grief one way or another. Unicode is designed to handle any
sets (subject to which Unicode you are using - there are many version-
dependent issues about that).
It is not an error because it is a feature for Oracle to be able to
handle different character sets. That puts it upon you to understand
the implications. Please read the docs about globalization, as well
as the metalink docs that help you understand NLS. It can get quite
involved, though usually the answer for a particular situation winds
up being simple.
jg
--
@home.com is bogus.
http://paulschreiber.com/blog/2008/0...n-translation/
#16
| |||
| |||
|
|
"Carlos" <miotromailcar... (AT) netscape (DOT) net> schrieb im Newsbeitragnews:c03f11e2-8cd4-41ff-bba6-b0a0f6c3c7e7 (AT) m3g2000hsc (DOT) googlegroups.com... On Apr 15, 3:04 pm, "André Hartmann" <andrehartm... (AT) hotmail (DOT) com wrote:>I cannot see the point of storing UNICODE (UTF8? UTF16?) in a WE8MSWIN1252 database... (you don't specify the NLSupport codepage for NVARCHARS/NCHARS) The DB codepage should be unicode *(AL32UTF8). * Hi, if that is so (unicode cannot be stored into databases that do not have a unicode character set) then why can I create tables with unicode columns (NCHAR, NVARCHAR2, NCLOB) in such databases? Wouldnt it be more appropriate then for Oracle to cast errors when trying so? To say it the other way round, the sheer fact that it is possible to declare unicode columns in the database implied to me that it is possible to store such values. Am I wrong here? |
way, way helpful and way, way, way friendly about converting from one
character set to another. Most tools honor that, but some don't. But
the general way to not get the conversion is to have the proper NLS
environment, as well as the proper character set. In general, using a
character set that does not support what you are putting into it will
cause you grief one way or another. Unicode is designed to handle any
sets (subject to which Unicode you are using - there are many version-
dependent issues about that).
It is not an error because it is a feature for Oracle to be able to
handle different character sets. That puts it upon you to understand
the implications. Please read the docs about globalization, as well
as the metalink docs that help you understand NLS. It can get quite
involved, though usually the answer for a particular situation winds
up being simple.
jg
--
@home.com is bogus.
http://paulschreiber.com/blog/2008/0...n-translation/
#17
| |||
| |||
|
|
"Carlos" <miotromailcar... (AT) netscape (DOT) net> schrieb im Newsbeitragnews:c03f11e2-8cd4-41ff-bba6-b0a0f6c3c7e7 (AT) m3g2000hsc (DOT) googlegroups.com... On Apr 15, 3:04 pm, "André Hartmann" <andrehartm... (AT) hotmail (DOT) com wrote:>I cannot see the point of storing UNICODE (UTF8? UTF16?) in a WE8MSWIN1252 database... (you don't specify the NLSupport codepage for NVARCHARS/NCHARS) The DB codepage should be unicode *(AL32UTF8). * Hi, if that is so (unicode cannot be stored into databases that do not have a unicode character set) then why can I create tables with unicode columns (NCHAR, NVARCHAR2, NCLOB) in such databases? Wouldnt it be more appropriate then for Oracle to cast errors when trying so? To say it the other way round, the sheer fact that it is possible to declare unicode columns in the database implied to me that it is possible to store such values. Am I wrong here? |
way, way helpful and way, way, way friendly about converting from one
character set to another. Most tools honor that, but some don't. But
the general way to not get the conversion is to have the proper NLS
environment, as well as the proper character set. In general, using a
character set that does not support what you are putting into it will
cause you grief one way or another. Unicode is designed to handle any
sets (subject to which Unicode you are using - there are many version-
dependent issues about that).
It is not an error because it is a feature for Oracle to be able to
handle different character sets. That puts it upon you to understand
the implications. Please read the docs about globalization, as well
as the metalink docs that help you understand NLS. It can get quite
involved, though usually the answer for a particular situation winds
up being simple.
jg
--
@home.com is bogus.
http://paulschreiber.com/blog/2008/0...n-translation/
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.