That's true however our DB character set is utf8 and the client charset is AL32UTF8.
I was trying to come up with a better performing mechanism than retrieving the information from user_tab_columns. The max length (along with column name and data type) ends up being sent to a client in a json structure so the client can perform some local validation. The scenarios where a column is defined as VARCHAR2(nn BYTE) rather than VARCHAR2(nn CHAR) are in the minority and only exist for applications whose character data is essentially limited to 7-bit ascii. Even in those applications there is a mixture of (nn CHAR) and (nn BYTE). I was hoping to be able to use the information that comes back from the OCIAttrGet (OCI_ATTR_CHAR_USED) call - which as you can see from the trace output DBD::Oracle uses to populate char_used attribute to 1 (nn CHAR) or 0 (nn BYTE). Cheers, Steve On Wed, Sep 9, 2015 at 10:10 AM, Bruce Johnson <john...@pharmacy.arizona.edu > wrote: > > > On Sep 8, 2015, at 3:42 PM, Steve Baldwin <stbald...@multiservice.com> > wrote: > > > > I have a table defined as follows: > > > > SQL> desc sb1 > > Name Null? Type > > ----------------------------- -------- -------------------- > > C1 VARCHAR2(30 CHAR) > > C2 VARCHAR2(30) > > > > Note the difference is the character semantics, c1 is CHAR, c2 is BYTE. > > > > isn’t that dependent on what ns_lang is set to? for single-byte encoding > this is correct, as 30 char == 30 bytes. > > <http://www.dba-oracle.com/t_nls_lang.htm> > > -- > Bruce Johnson > University of Arizona > College of Pharmacy > Information Technology Group > > Institutions do not have opinions, merely customs > > -- ------------------------------------------------------------------ This email is intended solely for the use of the addressee and may contain information that is confidential, proprietary, or both. If you receive this email in error please immediately notify the sender and delete the email.. ------------------------------------------------------------------
