We have a unicode Oracle instance and arserver is configured to use unicode; the columns are varchar2.
[EMAIL PROTECTED] scripts]$ cat /x/y/z/conf/ar.conf |grep UTF Db-Character-Set: UTF-8 btw, you're not ranting; there's the right way then there's the easy way; I almost always prefer the right way. Axton Grams On Dec 13, 2007 10:18 AM, Hugo Visser <[EMAIL PROTECTED]> wrote: > ** Axton, > > I'm not sure what you are saying, but when you install the AR System with > unicode checked in the installer on MSSQL, the created columns are already > of the nchar kind. So database wise it seems OK. I think the same is true > for an Oracle install. That's why I don't understand the bytes vs characters > argument. DB is OK, just check the field against the number of characters > and stuff it in the DB. Maybe the problem is the check itself if the AR > System is not using unicode internally (which is likely). > > @Fred the original problem can be related, if the menu check is also using > bytes (convert 60 chars to unicode bytes, limit to field length and convert > back), it might "miss" some characters fireing the error. > > Anyway, the key thing is that unicode deals with characters, not bytes. We > (users, developers) should not have to care about how a character is encoded > internally or in the DB. I've never understood the choice for SUBSTR vs > SUBSTRC. SUBSTRC will work in both unicode and non-unicode installs, while > SUBSTR could break your workflow in unicode environments, but will still > work on non unicode installs. To me that's a clear indication that > unicodewise BMC doesn't seem to get it. > > Hugo > > PS I realize that I might be ranting, but I just want to get a better AR > System :) > > > > On Dec 13, 2007 3:55 PM, Axton <[EMAIL PROTECTED] > wrote: > > > > > > > > *** 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" > > > > > __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"
