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" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
