*** Oracle
NCHAR and NVARCHAR2 Datatypes
NCHAR and NVARCHAR2 are Unicode data types that store Unicode
character data. The character set of NCHAR and NVARCHAR2 datatypes can
only be either AL16UTF16 or UTF8 and is specified at database creation
time as the national character set. AL16UTF16 and UTF8 are both
Unicode encoding.
* The NCHAR datatype stores fixed-length character strings that
correspond to the national character set.
* The NVARCHAR2 datatype stores variable length character strings.
When you create a table with an NCHAR or NVARCHAR2 column, the maximum
size specified is always in character length semantics. Character
length semantics is the default and only length semantics for NCHAR or
NVARCHAR2.
*** SQL Server
nchar Fixed-length Unicode data with a maximum length of 4,000 characters
nvarchar Variable-length Unicode data with a maximum length of 4,000
characters
ntext Variable-length Unicode data with a maximum length of 2^30 - 1
characters
Seems the best approach would be that if arserver is configured for
unicode support, it should use unicode data types within the db.
Makes transitioning from non-unicode to unicode a bit more difficult,
but not impossible.
Axton Grams
On Dec 13, 2007 4:05 AM, Hugo Visser <[EMAIL PROTECTED]> wrote:
> ** I'm sorry, but I'm finding this almost offensive. Unicode was invented to
> map a character to a byte representation. So when your product "supports
> unicode" it most of the time means that you can enter any kind of character
> in a field or whatever and that the system will do the right thing to store
> it. Whether a character is stored in one, two or four bytes is just an
> implementation detail and the spec for that is unicode.
>
> BMC is really turning this around with it's "unicode" implementation. Now a
> developer or end user must be aware that a bunch of characters end up being
> x bytes in the DB or application. Something that the developer or user can
> NEVER anticipate. The AR System, from a development platform perspective,
> should hide this implementation detail, the same way as the DB is "hidden"
> from the application developer.
> That would be true unicode support, and this is how many other unicode apps
> do it.
>
> Just saying "hey you didn't read the docs" is the easy way out. BTW I did
> read the docs and therefore we decided that AR System on unicode is a no-go
> for now.
>
> So as far as unicode support in AR System is concerned, it's a technical
> hack that lets you store stuff in a unicode DB, but there's no real
> application support for it. It is nice for marketing to let the world know
> you "support unicode" though.
>
> I hope someone at BMC will see the light and bring true unicode support to
> AR System in the next release.
>
> Hugo
>
>
> On Dec 13, 2007 12:40 AM, Easter, David < [EMAIL PROTECTED]> wrote:
> >
> >
> >
> >
> > > I'm reading the answer from David as the application developers does
> > > not know the difference between a byte and a character....
> >
> > Yes, I do find this to be true - it's a combination of three things:
> >
> > 1. In older (6.3 and before) versions of AR System documentation, it was
> stated that the field length is in characters. This didn't cause a problem
> when a character set has a one-to-one mapping of bytes to characters, but it
> isn't true for multi-byte languages. So when we added Unicode support in
> 7.0, the documentation was updated to be more technically accurate that the
> field length is really in bytes, not characters.
> >
> > 2. Others just haven't read the documentation at all and make an
> assumption that "length" is in characters, when it's really in bytes.
> >
> > 3. Some folks don't know that characters can be more than one byte in
> length. So when they want a field to hold 10 characters, they select "10"
> as the field length. Then, when Unicode is used, multi-byte characters
> exceed the field length of 10 bytes.
> >
> > Put these together, and you run into this problem.
> >
> > Note that by "application developers" I mean those that create
> applications on top of AR System. The AR System engineers themselves have
> always known that field lengths are in bytes. It's only recently with the
> introduction of Unicode support ( i.e. 7.0.00 and forward) where there has
> been confusion in the customer base about this topic.
> >
> > Thanks,
> >
> > -David J. Easter
> > Sr. Product Manager, Service Management Business Unit
> > BMC Software, Inc.
> >
> > The opinions, statements, and/or suggested courses of action expressed in
> this E-mail do not necessarily reflect those of BMC Software, Inc. My
> voluntary participation in this forum is not intended to convey a role as a
> spokesperson, liaison or public relations representative for BMC Software,
> Inc.
> >
> >
> >
> >
> > -----Original Message-----
> > From: Action Request System discussion list(ARSList)
> [mailto:[EMAIL PROTECTED] On Behalf Of Jarl Grøneng
> > Sent: Wednesday, December 12, 2007 11:56 AM
> > To: [email protected]
> > Subject: Unicode...
> >
> > Intresting answers from BMC:
> > http://developer.bmc.com/jiveProd/thread.jspa?threadID=8144&tstart=0
> >
> > I'm reading the answer from David as the application developers does
> > not know the difference between a byte and a character....
> >
> > --
> > Jarl
> >
> >
> _______________________________________________________________________________
> > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> > Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
> >
> >
> _______________________________________________________________________________
> > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> > Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
> >
>
> __20060125_______________________This posting was submitted with HTML in
> it___
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
