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