Axton, Thanks, that would work but that would also mean that every field should have a filter check on this. Even then the fields that are now 255 chars long should be changed to long, making it impossible to show them in a table field for example. Indeed a PITA.
The current status of the RFE is that it's on the list to _consider_ for the 2008 release...Support also mentioned the same issue was raised a couple of times before. Too bad that we have to wait that long because I don't understand why they implemented it this way in the first place, our users are not thinking in how many bytes they type, they are thinking in characters. I've also never understood the difference about LENGTH and LENGTHC, in any case you'd want a substring of characters, not bytes so they should have made LENGTH behave like LENGTHC and not created another function for it imho. Hugo On 5/10/07, Axton <[EMAIL PROTECTED]> wrote:
There are functions that end with C (e.g., LENGTHC) that will count the number of characters and support unicode. You could enforce the length limits using this, while making the field length 4x the intended length. A PITA, but it could be made to work. Did BMC give a statement of direction for this issue, or is this a handicap we are intended to live with? Axton Grams On 5/10/07, Hugo Visser <[EMAIL PROTECTED]> wrote: > ** Hello List, > > I was wondering how many of you are running an ar system install in unicode > mode for your applications. Here's my situation: we develop an out of the > box workflow application called ExpertDesk that supports multiple locales. > Currently they are English, Dutch, German, Polish and French. Because of > future developments we'd like to switch to the use of unicode servers, > because currently a customer cannot run Polish and English on the same > server (since those languages use a different character set). However > there's one big "gotcha" which you may or may not be aware of and this is > what is causing me headaches :) > > The input length of fields in the AR System are not checked on the amount of > characters, but on the amount of bytes those characters translate to. What > this means is that if a field has set a input length of 30, in the current > situation it can always hold exactly 30 characters or less. But in the > unicode situation it can hold up to 30 characters, since a character may be > encoded in 1-4 bytes (UTF-8). In theory this implicates that if I set the > input length to 30 it could happen dat only 7 characters (25%) can be > entered. > > Now this is all documented in the unicode whitepaper for 7.0.1, and the > suggestion given there is to increase the field length. But unless I switch > all fields to 0 (long) fields, there will always be an unexpected limit. And > setting all fields to 0 isn't a great option either. Apart from that how do > we document this limitation or explain it to the users? Do you document that > a field can "hold up to 30 characters"? > > So my question would be how you guys are handling this situation and if > there is maybe something clever that I've not thought of to overcome this? > > Thanks, > > Hugo > > PS. I've submitted an issue for this, and I got the response that it is "as > designed". I've opened an RFE (SW00265962) so that the input length would be > the input length in characters, not in bytes in all cases. > __20060125_______________________This posting was > submitted with HTML in it___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
_______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
