Data Length Semantics?

Dear memebers,
what is Data Length Semantics property of text box?
what's its behavior?
thanks
Muhammad Nadeem
[email protected]

Values CHAR, BYTE, null
Refer to Built-in
GET_ITEM_PROPERTY
Usage Notes
- If a null value is specified, then byte semantics will be used unless the environment variable NLS_LENGTH_SEMANTICS is set to CHAR when the form is compiled.
- When the Synchronize with Item property is set, DATA_LENGTH_SEMANTICS will be ignored in a subordinate mirror item. The DATA_LENGTH_SEMANTICS property is always taken from the master mirror item. A compiler (generator) warning will be issued if a non-null value is specified in a subordinate mirror item.
- A compiler (generator) warning will also be issued if a non-null value is specified in an item whose datatype is neither CHAR, ALPHA, nor LONG.

Similar Messages

Export with data length semantics

Hello,
I've following problem.
I have a table abcd which contains 2 VARCHAR2 columns with different data length semantics (one with BYTE, one with CHAR). Charset is Single Byte; let's say WE8MSWIN1252, so data length semantics should not be a problem. should not. details later.
So this would be:
create table abcd (a_char VARCHAR2(2 CHAR), a_byte VARCHAR2(2 BYTE));after that I export the table via exp. I'm not setting NLS_LENGTH_SEMANTICS environment variable, so BYTE is used.
In the dump file the data length semantics for the byte col is omitted, as I exported it with BYTE:
create table abcd (a_char VARCHAR2(2 CHAR), a_byte VARCHAR2(2));after that, I "accidently" import it with data length semantics set to CHAR, and the table looks like this now
abcd
a_char VARCHAR2(2 CHAR)
a_byte VARCHAR2(2 CHAR)Same happens vice versa when using CHAR for export and BYTE for import...
In single byte charsets this might not be so much of a problem, as one CHAR is equal to one BYTE, but...
If I compile plsql against the original table, and run against the outcoming table after export, I get an ORA-4062, and I have to recompile...
Would not be a problem if the plsql I compile would be on the database...Big problem is that the ORA-4062 occurs in forms, where it's difficult for me to recompile (I would have to transfer all the sources to customer and compile there).
Is there any possibility to export data length semantics regardless which environment variable is set?
database version would be 9.2.0.6; but if there exists a solution in higher versions I would also be happy to hear them...
many thanks,
regards

I can't reproduce your problem:
SQL> show parameter nls_length_semantics
NAME                                 TYPE        VALUE
nls_length_semantics                 string      BYTE
SQL> create table scott.demo( col1 varchar2(10 byte), col2 varchar2(10 char) );
SQL> describe scott.demo
Name                                      Null?    Type
COL1                                               VARCHAR2(10)
COL2                                               VARCHAR2(10 CHAR)
$ export NLS_LENGTH_SEMANTICS=BYTE
$ exp scott/tiger file=scott.dmp tables=demo
SQL> drop table scott.demo;
$ export NLS_LENGTH_SEMANTICS=CHAR
$ imp scott/tiger file=scott.dmp
SQL> describe scott.demo
Name                                      Null?    Type
COL1                                               VARCHAR2(10 BYTE)
COL2                                               VARCHAR2(10)
SQL> alter session set nls_length_semantics=byte;
SQL> describe scott.demo
Name                                      Null?    Type
COL1                                               VARCHAR2(10)
COL2                                               VARCHAR2(10 CHAR)Can you post a test like mine?
Enrique
PS If you have access to Metalink, read Note:144808.1 Examples and limits of BYTE and CHAR semantics usage. From 9i and up, imp doesn't read nls_length_semantics from the environment.
Edited by: Enrique Orbegozo on Dec 16, 2008 12:50 PM
Edited by: Enrique Orbegozo on Dec 16, 2008 12:53 PM

Convert all VARCHAR2 data types to character length semantics

Hi,
I am wondering if there is an easy way to convert all columns in the database of data type VARCHAR2(x BYTE) to VARCHAR2(x CHAR)?
Regards
Håkan

The DMU does not allow character length semantics migration for the following type of objects:
- Columns already in character length semantics
- Data dictionary columns
- Columns under Oracle-supplied application schemas
- CHAR attribute columns of ADT
- Columns in clusters
- Columns on which partition keys are defined
Please check if the disabled nodes you observed in the wizard fall under one of these categories.

SQL Loader Multibyte character error, LENGTH SEMANTICS CHARACTER

Hi,
startet SQL Loader Multibyte character error
{thread:id=2340726}
some mod locked the thread, why?
the solution for others:
add LENGTH SEMANTICS CHARACTER to the controlfile
LOAD DATA characterset UTF8 LENGTH SEMANTICS CHARACTER
TRUNCATE
INTO TABLE utf8file_to_we8mswin1252
ID CHAR(1)
, TEXT CHAR(40)
)Regards
Michael

Hi Werner,
on my linux desktop:
$ file test.dat
test.dat: UTF-8 Unicode text, with very long lines
my colleague is working on a windows system.
On both systems exact the same error from SQL Loader.
Btw, try with different number of special characters (german umlaute and euro) and there is no chance to load without the error
when to many (?) special characters or data is long as column length and special characters included.
Regards
Michael

Oracle length semantics migration documention

Due to the oracle documention to migrate length semantics:
To convert an existing schema and its associated data from byte semantics and a single-byte character set to character semantics and a multibyte character set, such as UTF-8, you need only follow these steps: [The following steps have been corrected since the magazine was printed.]
1. Export the schema.
2. Issue an ALTER SYSTEM SET NLS_LENGTH_SEMANTICS=CHAR SCOPE=BOTH command on the target database.
3. Stop and restart the instance so that the parameter change takes effect.
4. Drop the original schema.
5. Recreate the original schema and its tables (you can use import's show=Y option to get the CREATE TABLE statements). Columns in the recreated tables will use character semantics, because that's now the default.
6. Import the schema into the target database using the IGNORE=Y import option.
What is the meaning of the terms target and original?
Suppose there is a (source) database with length semantics byte. If a (target) database
is to be created as a clone of the (source) database, except for the length semantic char, does one have to migrate the (source) database first?
Or rather, why is it not possible to
1. Export the data from the source database with length semantic byte,
2. Create a target database with length semantics char,
3. Import the data from the source database?)

This documentation is, unfortunately, poorly written.
If you want to migrate data from one database to another, with both databases having different character sets, you can avoid some data expansion issues, if you migrate to character set semantics at the same time.
You cannot just export data, and import it into a character semantics database, because export/import preserves original semantics of the exported tables.
Note: there is actually no such thing as a character semantics database. Character semantics is a column/variable property. The "character semantics database" is a confusing, though commonly used, term that actually means an instance which has NLS_LENGTH_SEMANTICS set to CHAR in its initialization file. The only significant meaning of this parameter is to be the default for session-level NLS_LENGTH_SEMANTICS. It is used for sessions that do not set this parameter explictly (through environment variable or ALTER SESSION). The session-level parameter is significant for CREATE TABLE/PROCEDURE/FUNCTION/PACKAGE [BODY] statements and tells the default for column and variable declarations that do not specify BYTE or CHAR explicitly.
To migrate semantics of an original schema you need to create a script that will contain all CREATE statements needed to recreate this schema (at least CREATE {TYPE | TABLE | MATERIALIZED VIEW | PROCEDURE | FUNCTION | PACKAGE [BODY]}). Then, you can just add the ALTER SESSION SET NLS_LENGTH_SEMANTICS=CHAR after any CONNECT command in this script. You can than run the script in the target database. How you create the script is irrelevant. You can use any reverse-engineering tool available (e.g. SHOW=Y option of import, DBMS_METADATA package, etc.)
After you pre-create the schema with the new semantics, you can import the data from the original (source) database with IGNORE=Y. The original semantics saved in the export file will be ignored for pre-created objects.
Note: PL/SQL may need manual corrections to migrate to character semantics. For example, SUBSTRB used to trim values before assignment may need to be replaced with SUBSTR.
-- Sergiusz

Issues caused by changing length semantics

Hi All,
Our database was formerly using BYTE for columns of tables and for stored procedures. We recently changed the Length Semantics to CHAR but caused some issues. An ORA-06502 pl/sql numeric or value error character string buffer too small appears when we access the database's stored procedures via Java. What could be the possible cause of this? Could you give me some paths to take in troubleshooting this issue?
Thanks to all!
Edited by: 1002671 on 25.4.2013 23:55

1002671 wrote:
Thanks for answering Sir! Are you kidding!!! No 'Sir' please... Common I don't know anything yet.
Correct me if I'm wrong but doesn't CHAR already handle multi-byte characters passed to or used in stored procedures? I'm really not that knowledgeable when it comes to the effects of changing the Length Semantics. We already changed the columns from VARCHAR2(BYTE) to VARCHAR2(CHAR). The problem lies within the stored procedures.I'm not clear on your doubt, but please check this -
Link: http://docs.oracle.com/cd/E11882_01/appdev.112/e10472/datatypes.htm (Section 'Declaring Variables for Multibyte Characters')
>
When declaring a CHAR or VARCHAR2 variable, to ensure that it can always hold n characters in any multibyte character set, declare its length in characters—that is, CHAR(n CHAR) or VARCHAR2(n CHAR), where n does not exceed FLOOR(32767/4) = 8191.
>
What i feel is you getting confused with the SQL data-type 'VARCHAR2' (i.e. used in specifying column type) and PL/SQL data-type 'VARCHAR2' (i.e. used while declaring variables)
Then check this : difference between BYTE & CHAR
Read and thoroughly research each comment given by the Experts there.

Data length error in record 86.

Data length error in record 86.
Message no. FV147
Diagnosis
An error occurred in the processing of the data to be imported. It is highly probable that this is a data error.
Contact your data provider.
System Response
Any account statement processing currently underway and any outstanding is being terminated.
Procedure
Check the structure of the supplied data. If the statement data you have obtained is error-free, you can simply restart the program. All those statements which have already been imported correctly will not be reimported.
{1:F01SCBLINBBXXXX3446100003}{2:O9400634140719SCBLINBBXXXX34461000031407190634N}{3:{108:00000000000718}}{4:
:20:14071905fr309439
:25:52205785839
:28C:611
:60F:D140718INR792788,04
:61:1407180718CR100000,00N169NONREF
:86:IN36701407187774 VIJBH14199069837
IN36701407187774 VIJBH14199069837
AGARWAL AGENCIES
:61:1407180718CR150000,00N169NONREF
:86:IN36701407187251 SBIN414199017384
IN36701407187251 SBIN414199017384
EAGLE FOOTWERE
:61:1407180718CR100000,00N169NONREF
:86:IN36701407187052 SAA96678573
IN36701407187052 SAA96678573
TANVEER TRADERS
:61:1407180718CR98000,00N169NONREF
:86:IN36701407186828 SBIN314199982628
IN36701407186828 SBIN314199982628
MODERN AGENCY
:61:1407180718CR179000,00N169NONREF
:86:IN36701407186029 SAA96670577
IN36701407186029 SAA96670577
BALAJI ENTERPRISES
:61:1407180718CR60000,00N169NONREF
:86:IN36701407185397 367845438
IN36701407185397 367845438
SAKSHI ENTERPRISES
:61:1407180718CR2000000,00N169NONREF
:86:IN3670140718H568 SBIN414199360804
IN3670140718H568 SBIN414199360804
RELAXO FOOTWEARS LIMITED
:61:1407180718CR38000,00N169NONREF
:86:IN3670140718G554 CBINH14199566672
IN3670140718G554 CBINH14199566672
WONDER WALK AGENCIES
:61:1407180718CR113000,00N169NONREF
:86:IN3670140718F851 JAKA140718621672
IN3670140718F851 JAKA140718621672
JYOTI SALES PROP MR AMIT VOHRA S
:61:1407180718CR54200,00N169NONREF
:86:IN3670140718F006 BKIDN14199343033
IN3670140718F006 BKIDN14199343033
SHAH FOOT WEAR
:61:1407180718CR64000,00N169NONREF
:86:IN3670140718F094 BKIDN14199343132
IN3670140718F094 BKIDN14199343132
MUSKAN TRADERS
:61:1407180718CR114500,00N169NONREF
:86:IN3670140718F423 SBIN414199302946
IN3670140718F423 SBIN414199302946
GOUTAM DISTRIBUTORS
:61:1407180718CR63000,00N169NONREF
:86:IN3670140718D651 SD1141261589
IN3670140718D651 SD1141261589
M K FOOTWEAR
:61:1407180718CR67913,00N169NONREF
:86:IN3670140718D057 SBIN414199247753
IN3670140718D057 SBIN414199247753
SSS PG STORES
:61:1407180718CR130000,00N169NONREF
:86:IN3670140718D183 UTBIN14199275937
IN3670140718D183 UTBIN14199275937
GOPAL SHOES
:61:1407180718CR48000,00N169NONREF
:86:IN3670140718C628 CBINH14199546949
IN3670140718C628 CBINH14199546949
AGGARWAL FOOTWEAR
:61:1407180718DR5000000,00N506PIRLXOIN01A00468
PIRLXOIN01A00468
:86:PIRLXOIN01A00468 SCBLR12014071800003757
CASH SCBLR12014071800003757
RELAXO FOOTWEARS LIMITED
SIN09373C0000423 00001 PIRLXOIN01A0
0468
PIRLXOIN01A00468
:61:1407180718DR4000000,00N506PIRLXOIN01A00469
PIRLXOIN01A00469
:86:PIRLXOIN01A00469 SIN09373Q0000468
PIRLXOIN01A00469-SIN09373Q0000468
SB3670140718HK96
SIN09373C0000424-00001 PIRLXOIN01A0
0469
:61:1407180718DR1699195,25N699TRF
:86:316031790865 PAY001
316031790865 PAY001
GRAND WISE ENTERPRISES LIMITED
AKMP037
USD28,030.8 60.5755/INR743.76 1
DEBIT IMEX CUSTOMER A/C
:61:1407180718CR480000,00N195NONREF
:86:IL36701407182157 BARBR52014071800734481
CASH BARBR52014071800734481
APNA FOOT WEAR
SENDER IFSCBARB0CHARMI
IL36701407182157
:61:1407180718CR235000,00N195NONREF
:86:IL36701407185517 SBINR52014071801147506
CASH SBINR52014071801147506
PRAKASH FOOT WEAR
FUND TRF FRM 33174969142 TO52205785
SENDER IFSCSBIN0016310
IL36701407185517
:61:1407180718CR500000,00N195NONREF
:86:IL36701407185083 SBINR12014071801142317
CASH SBINR12014071801142317
MODERN FOOTWEARS
SENDER IFSCSBIN0001521
IL36701407185083
:61:1407180718CR800000,00N195NONREF
:86:IL36701407184746 HDFCR52014071851912408
CASH HDFCR52014071851912408
FASHION SQUARE
SENDER IFSCHDFC0000412
IL36701407184746
:61:1407180718CR332000,00N195NONREF
:86:IL36701407184713 SBINR52014071801140001
CASH SBINR52014071801140001
WINGS POLYMERS
SENDER IFSCSBIN0001581
IL36701407184713
:61:1407180718CR450000,00N195NONREF
:86:IL36701407184302 FDRLR52014071800031798
CASH FDRLR52014071800031798
ABHINAV ENTERPRISE
SENDER IFSCFDRL0001492
IL36701407184302
:61:1407180718CR650000,00N195NONREF
:86:IL36701407183976 UCBAR32014071800058993
CASH UCBAR32014071800058993
GAYLORD SHOE AND CHAPPAL
SENDER IFSCUCBA0000048
IL36701407183976
:61:1407180718CR700000,00N195NONREF
:86:IL36701407183860 SBINR52014071801134507
CASH SBINR52014071801134507
FOOTWEAR HOUSE
RTGS TGH CHQ NO 172867
SENDER IFSCSBIN0008602
IL36701407183860
:61:1407180718CR250000,00N195NONREF
:86:IL36701407183487 SBINR52014071801131379
CASH SBINR52014071801131379
PRATAP AGENCY PROP MRS SUNITA KUMRA
SENDER IFSCSBIN0014152
IL36701407183487
:61:1407180718CR254740,00N195NONREF
:86:IL36701407182511 HDFCR52014071851915942
CASH HDFCR52014071851915942
HEPHZIBAH AGENCIES
SENDER IFSCHDFC0001498
IL36701407182511
:61:1407180718CR398000,00N195NONREF
:86:IL36701407182496 BARBR52014071800726312
CASH BARBR52014071800726312
RAZA FOOT WEAR
SENDER IFSCBARB0BASTIX
IL36701407182496
:61:1407180718CR300000,00N195NONREF
:86:IL36701407182349 KKBKR52014071800664337
CASH KKBKR52014071800664337
M M DISTRIBUTORS
PAYMENT
SENDER IFSCKKBK0000958
IL36701407182349
:61:1407180718CR61136,00N169NONREF
:86:IN3670140718C504 IOBAN14199026875
IN3670140718C504 IOBAN14199026875
M S CHINNS TRADERS
:61:1407180718CR79995,00N169NONREF
:86:IN3670140718C142 SBIN414199219784
IN3670140718C142 SBIN414199219784
FRONTIER TRADING COMPANY
:61:1407180718CR100000,00N169NONREF
:86:IN3670140718B731 SBIN414199200112
IN3670140718B731 SBIN414199200112
SHRI AMBEY TRADERS
:61:1407180718CR125000,00N169NONREF
:86:IN3670140718B521 N199140025581074
IN3670140718B521 N199140025581074
SHYAM BROTHERS
:61:1407180718CR68000,00N169NONREF
:86:IN3670140718A144 1205061871400003
IN3670140718A144 1205061871400003
POPULAR TRADERS PROP PISHORI LAL SETHI
:61:1407180718CR41000,00N169NONREF
:86:IN3670140718A044 P14071849681718
IN3670140718A044 P14071849681718
AKSHAY FOOTWEARS
:61:1407180718CR50000,00N169NONREF
:86:IN3670140718A099 BARBH14199284604
IN3670140718A099 BARBH14199284604
STAR ENTERPRISE
:61:1407180718CR100000,00N169NONREF
:86:IN3670140718A002 SAA21370357
IN3670140718A002 SAA21370357
JAI OMKAR ENTERPRISES
:61:1407180718CR120000,00N169NONREF
:86:IN36701407189725 UTBIN14199269504
IN36701407189725 UTBIN14199269504
SANTI STORES
:61:1407180718CR100000,00N169NONREF
:86:IN36701407189538 SBIN414199107266
IN36701407189538 SBIN414199107266
VINAYAK TRADING
:61:1407180718CR100000,00N169NONREF
:86:IN36701407189842 SAA3564919
IN36701407189842 SAA3564919
SKY STYLE MARKETING PROP.ABHISHEK S
:61:1407180718CR120000,00N169NONREF
:86:IN36701407189384 MAHBH14199609866
IN36701407189384 MAHBH14199609866
ROYAL FOOT WEAR
:62F:D140718INR1697499,29
:64:C140718INR59273846,71
-}{5:{CHK:CHECKSUM DISABLED}{MAC:MACCING DISABLED}}

SAP REPLAY
Regarding the incidence itself, kindly consider that The 86-record
limitation is not a bug of the program, but the standard design.
The error is coded as FV147, when the Note to Payee in Record 86
exceeds 65 characters in Program RFEKA400.
You will need to contact your Bank in order to obtain a correct file:
I have attached some documentation on this message that will allow your
bank to create it.
Otherwise, you may use the following user-exit (SAP NOTE 494777):CMOD
Enhancement Exit Name FEB00004 > EXIT_RFEKA400_001.
This User Exit is called in RFEKA400 in the line: PERFORM
PROCESS_RAW_DATA TABLES SWIFT. In Include ZXF01U06, you have
the option to process the raw data.
Hope this information is useful to you.

How to retreive the max data length of a column

Hello All,
I know how to do a select to get the max data length of a column it is this :
SELECT MAX(LENGTH(COLUMN_NAME) FROM table.
However, I need this information combined with my SQL that returns the Data_type and length from the USER_TAB_COLUMNS. So taking the emp example if the ename column was 50 as VARCHAR2 but the max data entered in it was just 20 I want the information like this:
SELECT COLUMN_NAME, DATA_LENGTH, and the Max length of 20
FROM USER_TAB_COLUMNS WHERE TABLE_NAME='EMP';
I don't know how to get the Max Length of the Column in this table. Can anyone suggest me a hint? An Inline view maybe?
Thanks

Still not sure about your requirements, but how about this
SQL> CREATE OR REPLACE FUNCTION get_max_length(p_table in varchar2, p_col in varchar2) return pls_integer
2 is
3    v_cnt pls_integer;
4 begin
5    execute immediate 'select max(length('||p_col||')) from '||p_table into v_cnt;
6    return v_cnt;
7 end get_max_length;
8 /
Function created.
SQL>
SQL> SELECT COLUMN_NAME,
2         DATA_LENGTH,
3         get_max_length(TABLE_NAME, COLUMN_NAME) max_length
4 FROM USER_TAB_COLUMNS
5 WHERE TABLE_NAME='EMP'
6 AND DATA_TYPE like '%CHAR%'
7 ;
COLUMN_NAME                    DATA_LENGTH MAX_LENGTH
ENAME                                   10          6
JOB                                      9          9
SQL>

'Input data length not a multiple of blocksize' error in CUP

Hello All
I receive the error below when trying to configure CUP. I got this error whilst trying to define the password for the RFC user created in the Connector screen in CUP. CUP doesn't accept the SAP password maintained in SU01. CUP only allows a 4 character password but SU01 is configured to only accept 8 characters. Full error message below.
'com.virsa.ae.commons.utils.StringEncrypter$EncryptionException: Input data length not a multiple of blocksize.'
Can anyone shed any light on this?

Hi All,
This issue is in Version 5.3 SP 7.1 of CUP. It occurs when we are trying to change the password for the CUP connector.
Please note that testing the connectors within the Content Administrator --> Maintain JCO Connections screens works fine and the risk analysis from RAR also works without issue. However, whenever we attempt to enter the password for CUP connecotr setup, it returns an error saying "Action Failed" with the 'Input data length not a multiple of blocksize' error showing in the trace logs.
We seem to be able to store a password of 4 characters e.g. 1234 but this then naturally fails the connection test.
Can anyone suggest a parameter setting to check or a resolution for this particular issue?
Thanks,
Simon

How to over weite old data length in data clusters.

Hello All,
I'm geting short dump CONNE_IMPORT_WRONG_COMP_LENG. bcoz of new data length of one field (Host) is not reflecting in Data Clustor.
How to over write old data length with new data length....
Thanks,

suresh8 wrote:
how to copy my old data in my i6?
Back up and restore your iPhone, iPad, or iPod touch using iCloud or iTunes - Apple Support
Import photos and videos from your iPhone, iPad, or iPod touch to your Mac or Windows PC - Apple Support
As for songs that are on your iPhone, those cannot be copied from the device to another location.

Querying CHAR columns with character length semantics unreliable

Hi again,
It appears that there is a bug in the JDBC drivers whereby it is highly unlikely that the values of CHAR columns that use character length semantics can be accurately queried using ResultSet.getString(). Instead, the drivers return the value padded with space (0x#20) characters out to a number of bytes equal to the number of characters multiplied by 4. The number of bytes varies depending on the number and size of any non-ascii characters stored in the column.
For instance, if I have a CHAR(1) column, a value of 'a' will return 'a ' (4 characters/bytes are returned), a value of '\u00E0' will return '\u00E0 ' (3 characters / 4 bytes), and a value of '\uE000' will return '\uE000 ' (2 characters / 4 bytes).
I'm currently using version 9.2.0.3 of the standalone drivers (ojdbc.jar) with JDK 1.4.1_04 on Redhat Linux 9, connecting to Oracle 9.2.0.2.0 running on Solaris.
The following sample code can be used to demonstrate the problem (where the DDL at the top of the file must be executed first):
import java.sql.*;
import java.util.*;
This sample generates another bug in the Oracle JDBC drivers where it is not
possible to query the values of CHAR columns that use character length semantics
and are NOT full of non-ascii characters. The inclusion of the VARCHAR2 column
is just a control.
CREATE TABLE TMP2
TMP_ID NUMBER(10) NOT NULL PRIMARY KEY,
TMP_CHAR CHAR(10 CHAR),
TMP_VCHAR VARCHAR2(10 CHAR)
public class ClsCharSelection
private static String createString(char character, int length)
char characters[] = new char[length];
Arrays.fill(characters, character);
return new String(characters);
} // private static String createString(char, int)
private static void insertRow(PreparedStatement ps,
int key, char character)
throws SQLException
ps.setInt(1, key);
ps.setString(2, createString(character, 10));
ps.setString(3, createString(character, 10));
ps.executeUpdate();
} // private static String insertRow(PreparedStatement, int, char)
private static void analyseResults(PreparedStatement ps, int key)
throws SQLException
ps.setInt(1, key);
ResultSet results = ps.executeQuery();
results.next();
String tmpChar = results.getString(1);
String tmpVChar = results.getString(2);
System.out.println(key + ", " + tmpChar.length() + ", '" + tmpChar + "'");
System.out.println(key + ", " + tmpVChar.length() + ", '" + tmpVChar + "'");
results.close();
} // private static void analyseResults(PreparedStatement, int)
public static void main(String argv[])
throws Exception
Driver driver = (Driver)Class.forName(
"oracle.jdbc.driver.OracleDriver").newInstance();
DriverManager.registerDriver(driver);
Connection connection = DriverManager.getConnection(
argv[0], argv[1], argv[2]);
PreparedStatement ps = null;
try
ps = connection.prepareStatement(
"DELETE FROM tmp2");
ps.executeUpdate();
ps.close();
ps = connection.prepareStatement(
"INSERT INTO tmp2 ( tmp_id, tmp_char, tmp_vchar " +
") VALUES ( ?, ?, ? )");
insertRow(ps, 1, 'a');
insertRow(ps, 2, '\u00E0');
insertRow(ps, 3, '\uE000');
ps.close();
ps = connection.prepareStatement(
"SELECT tmp_char, tmp_vchar FROM tmp2 WHERE tmp_id = ?");
analyseResults(ps, 1);
analyseResults(ps, 2);
analyseResults(ps, 3);
ps.close();
connection.commit();
catch (SQLException e)
e.printStackTrace();
connection.close();
} // public static void main(String[])
} // public class ClsColumnInsertion

FYI, this has been mentioned as early as November last year:
String with length 1 became 4 when nls_lang_semantics=CHAR
and was also brought up in Feburary:
JDBC thin driver pads CHAR col to byte size when NLS_LENGTH_SEMANTICS=CHAR

How to determine column length semantics through ANSI Dynamic SQL ?

I am looking for a way to determine the length semantics used for a column through ANSI Dynamic SQL.
I have a database with NLS_CHARACTERSET=AL32UTF8.
In this database I have the following table:
T1(C1 varchar2(10 char), C2 varchar2(40 byte))
When I describe this table in SQL*Plus, I get:
C1 VARCHAR2(10 CHAR)
C2 VARCHAR2(40)
In my Pro*C program (mode=ansi), I get the select statement on input, use PREPARE method to prepare it and then use the GET DESCRIPTOR method to obtain colum information for output:
GET DESCRIPTOR 'output_descriptor' VALUE :col_num
:name = NAME, :type = TYPE,
:length = LENGTH, :octet_length = OCTET_LENGTH
For both C1 and C2 I get the following:
:type=12
:length=40
:octet_length=40
So, even if I know that my database is AL32UTF8, there doesn't seem to be a way for me to determine whether char or byte length semantics were used in C1 and C2 column definitions.
Does anybody know how I can obtain this information through ANSI Dynamic SQL?
Note: the use of system views such as ALL_TAB_COLUMNS is not an option, since we wish to obtain this information even for columns in a complex select statements which may involve multiple tables.
Note: I believe OCI provides the information that we need through OCI_ATTR_DATA_SIZE (which is in bytes) and OCI_ATTR_CHAR_SIZE (which is in chars). However, switching to OCI is something we would like to avoid at this point.

Yes, I was wondering which forum would be the best for my question. I see similar questions in various forums, Call Interface, SQL and PL/SQL and Database - General. Unfortunately there is no Pro*C or Dynamic SQL forum which would be my first choice for posting this question.
Anyway I now posted the same question (same subject) in the Call Interface forum, so hopefully I'll get some answers there.
Thank you for the suggestion.

How to Compare Data length of staging table with base table definition

Hi,
I've two tables :staging table and base table.
I'm getting data from flatfiles into staging table, as per requirement structure of staging table and base table(length of each and every column in staging table is 25% more to dump data without any errors) are different for ex :if we've city column with varchar length 40 in staging table it has 25 in base table.Once data is dumped into staging table I want to compare actual data length of each and every column in staging table with definition of base table(data_length for each and every column from all_tab_columns) and if any column differs length I need to update the corresponding row in staging table which also has a flag called err_length.
so for this I'm using cursor c1 is select length(a.id),length(a.name)... from staging_table;
cursor c2(name varchar2) is select data_length from all_tab_columns where table_name='BASE_TABLE' and column_name=name;
But we're getting data atonce in first query whereas in second cursor I need to get each and every column and then compare with first ?
Can anyone tell me how to get desired results?
Thanks,
Mahender.

This is a shot in the dark but, take a look at this example below:
SQL> DROP TABLE STAGING;
Table dropped.
SQL> DROP TABLE BASE;
Table dropped.
SQL> CREATE TABLE STAGING
2 (
3          ID              NUMBER
4 ,       A               VARCHAR2(40)
5 ,       B               VARCHAR2(40)
6 ,       ERR_LENGTH      VARCHAR2(1)
7 );
Table created.
SQL> CREATE TABLE BASE
2 (
3          ID      NUMBER
4 ,       A       VARCHAR2(25)
5 ,       B       VARCHAR2(25)
6 );
Table created.
SQL> INSERT INTO STAGING VALUES (1,RPAD('X',26,'X'),RPAD('X',25,'X'),NULL);
1 row created.
SQL> INSERT INTO STAGING VALUES (2,RPAD('X',25,'X'),RPAD('X',26,'X'),NULL);
1 row created.
SQL> INSERT INTO STAGING VALUES (3,RPAD('X',25,'X'),RPAD('X',25,'X'),NULL);
1 row created.
SQL> COMMIT;
Commit complete.
SQL> SELECT * FROM STAGING;
        ID A                                        B                                        E
         1 XXXXXXXXXXXXXXXXXXXXXXXXXX               XXXXXXXXXXXXXXXXXXXXXXXXX
         2 XXXXXXXXXXXXXXXXXXXXXXXXX                XXXXXXXXXXXXXXXXXXXXXXXXXX
         3 XXXXXXXXXXXXXXXXXXXXXXXXX                XXXXXXXXXXXXXXXXXXXXXXXXX
SQL> UPDATE STAGING ST
2 SET     ERR_LENGTH = 'Y'
3 WHERE   EXISTS
4          (
5                  WITH    columns_in_staging AS
6                  (
7                          /* Retrieve all the columns names for the staging table with the exception of the primary key column
8                           * and order them alphabetically.
9                           */
10                          SELECT COLUMN_NAME
11                          ,       ROW_NUMBER() OVER (ORDER BY COLUMN_NAME) RN
12                          FROM    ALL_TAB_COLUMNS
13                          WHERE   TABLE_NAME='STAGING'
14                          AND     COLUMN_NAME != 'ID'
15                          ORDER BY 1
16                  ),      staging_unpivot AS
17                  (
18                          /* Using the columns_in_staging above UNPIVOT the result set so you get a record for each COLUMN value
19                           * for each record. The DECODE performs the unpivot and it works if the decode specifies the columns
20                           * in the same order as the ROW_NUMBER() function in columns_in_staging
21                           */
22                          SELECT ID
23                          ,       COLUMN_NAME
24                          ,       DECODE
25                                  (
26                                          RN
27                                  ,       1,A
28                                  ,       2,B
29                                  ) AS VAL
30                          FROM            STAGING
31                          CROSS JOIN      COLUMNS_IN_STAGING
32                  )
33                  /*      Only return IDs for records that have at least one column value that exceeds the length. */
34                  SELECT ID
35                  FROM
36                  (
37                          /* Join the unpivoted staging table to the ALL_TAB_COLUMNS table on the column names. Here we perform
38                           * the check to see if there are any differences in the length if so set a flag.
39                           */
40                          SELECT STAGING_UNPIVOT.ID
41                          ,       (CASE WHEN ATC.DATA_LENGTH < LENGTH(STAGING_UNPIVOT.VAL) THEN 'Y' END) AS ERR_LENGTH_A
42                          ,       (CASE WHEN ATC.DATA_LENGTH < LENGTH(STAGING_UNPIVOT.VAL) THEN 'Y' END) AS ERR_LENGTH_B
43                          FROM    STAGING_UNPIVOT
44                          JOIN    ALL_TAB_COLUMNS ATC     ON ATC.COLUMN_NAME = STAGING_UNPIVOT.COLUMN_NAME
45                          WHERE   ATC.TABLE_NAME='BASE'
46                  )       A
47                  WHERE   COALESCE(ERR_LENGTH_A,ERR_LENGTH_B) IS NOT NULL
48                  AND     ST.ID = A.ID
49          )
50 /
2 rows updated.
SQL> SELECT * FROM STAGING;
        ID A                                        B                                        E
         1 XXXXXXXXXXXXXXXXXXXXXXXXXX               XXXXXXXXXXXXXXXXXXXXXXXXX                Y
         2 XXXXXXXXXXXXXXXXXXXXXXXXX                XXXXXXXXXXXXXXXXXXXXXXXXXX               Y
         3 XXXXXXXXXXXXXXXXXXXXXXXXX                XXXXXXXXXXXXXXXXXXXXXXXXXHopefully the comments make sense. If you have any questions please let me know.
This assumes the column names are the same between the staging and base tables. In addition as you add more columns to this table you'll have to add more CASE statements to check the length and update the COALESCE check as necessary.
Thanks!

To increase the XMLtype column data length

Hi ,
I have created a Table with an XMLtype column , when I am checking the data length it is showing only 2000.
How can I increase the length.
DBMS_METADATA.GET_DDL('TABLE','CC_EVENT_MESSAGES','UNS_STAGING_DEV5')
CREATE TABLE "UNS_STAGING_DEV5"."CC_EVENT_MESSAGES"
   (    "SRC_SYSTEM_CD" VARCHAR2(10) NOT NULL ENABLE,
        "SRC_SEQUENCE_NUM" NUMBER NOT NULL ENABLE,
        "SRC_EVENT_NAME" VARCHAR2(255) NOT NULL ENABLE,
        "SRC_EVENT_XSD_NAME" VARCHAR2(255) NOT NULL ENABLE,
        "SRC_EVENT_DATE" DATE NOT NULL ENABLE,
        "INSERT_TS" TIMESTAMP (6) NOT NULL ENABLE,
        "PROCESSED_TS" TIMESTAMP (6),
        "STAGING_NUM" NUMBER NOT NULL ENABLE,
        "MESSAGE_STATE" VARCHAR2(10) NOT NULL ENABLE,
        "MESSAGE_FRAME" "SYS"."XMLTYPE" NOT NULL ENABLE
   ) SEGMENT CREATION IMMEDIATE
PCTFREE 0 PCTUSED 0 INITRANS 1 MAXTRANS 255
NOCOMPRESS LOGGING
STORAGE(INITIAL 1048576 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1
BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
TABLESPACE "UNS_STAGING_DEV5"
XMLTYPE COLUMN "MESSAGE_FRAME" STORE AS BASICFILE CLOB (
TABLESPACE "UNS_STAGING_DEV5" ENABLE STORAGE IN ROW CHUNK 8192 RETENTION
CACHE
STORAGE(INITIAL 65536 NEXT 65536 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1
BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT))
   CACHE
SQL> select OWNER,TABLE_NAME,column_name,data_type,data_length from dba_tab_columns where DATA_TYPE like '%XMLTYPE' and owner not in ('SYS','SYSTEM','XDB');
OWNER                TABLE_NAME           COLUMN_NAME     DATA_TYPE DATA_LENGTH
UNS_STAGING_DEV5     CC_EVENT_MESSAGES    MESSAGE_FRAME   XMLTYPE           2000

I have created a Table with an XMLtype column , when I am checking the data length it is showing only 2000.
Don't rely on this value, it's wrong.
XMLType datatype inherits the properties of its underlying LOB storage, in the present case CLOB, which can store TBs of data.

Length semantics

Hi,
There are odbc apis which have character i/o parameters. These arguments have length parameters associated with them. These lengths can be number of bytes or number of wide characters/code points. I want to know about these length semantics. I could not find any relevant documentation. It would be fine if somebody points me to such a reference.
Thanks and regards,
Vivek.

Hi,
What does codepoint mean
In simple terms Code point Assinging a distinct numeric value for each character.
As coming to length Semantics, that totally depends upon the Language setting like UTF-8. Since in Language Setting in order to maintain/store a Asian character it takes(Single Character).. it takes three code units some thing like that...
Let me put the nice link for you from where you can get some understanding about the length semantics...
Here we go finally got it.. for you... But nice link..
http://www.oracle.com/technology/oramag/oracle/03-nov/o63tech_glob.html
- Pavan Kumar N

Data Length Semantics?

Similar Messages

Maybe you are looking for