Well, I haven't checked Oracle, but when you install the unicode AR System on MS SQL today the columns created are of type nchar. For example the C1 field is nvar(15). So it looks like the db side is created already OK. I can even insert the offending characters using SQL and get them displayed in ars without any problems.
Hugo On 5/10/07, Axton <[EMAIL PROTECTED]> wrote:
Probably implemented different function names because some other products do: http://www.oracle.com/technology/oramag/oracle/03-mar/o23sql.html In Oracle, you can define the limits of a column like this (if using a unicode character set): VARCHAR2(3 CHAR) This sizes the column such that the limit is on the number of characters, not bytes. Seems this would be a hefty change for a .x release, but could be implemented in a major release since people will be using the installer to perform the upgrade. The reason I say hefty is because all varchar columns in the db would need to be altered to use the character limit and not the byte limit. Not sure how this translates to other db's either. Axton On 5/10/07, Hugo Visser <[EMAIL PROTECTED]> wrote: > ** 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.orgARSlist:"Where > the Answers Are" > > > > __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"
