Varchar Type column value  too large  ERROR (ORA-12899)

Hi,
I'm using Build *"ODI_11.1.1.3.0_GENERIC_100623.1635"*
I'm trying to move data from SQL SERVER 2005 to Oracle DB 11.2.
Integration Knowledge Module is : IKM SQL INCREMENTAL UPDATE
Loading Knowledge Module : LKM SQL TO ORACLE
The problem is in VARCHAR type column with length 20.
The target column type is VARCHAR2 , length 20.
Integration fails on the LOADING STEP with message : java.sql.BatchUpdateException: ORA-12899: value too large for column "DW_WORKUSER"."C$_10PLFACT"."C65_SOURCENO" *(actual: 26, maximum: 20)*
Column mapping is executed on the Source.
In column mapping I'm not using any convertion, casting or any other logic, I'm just moving my column to the target table.
Can anyone make some suggestions ?

Hi,
This is due to bytes not chars. On your SQL server db you can have multibyte characters (as you can elsewhere). You may need to modify the C$/I$ and your target tables to bytes rather than chars. You may also want to check the CHARACTER_SETS that are used on the source and target.
eg
VARCHAR2(20 BYTE)
Cheers
Bos
Edited by: Bos on Apr 13, 2011 8:36 AM

Similar Messages

  • How to find the exact coloumn which fired the column value too large error

    Hi all
    I have a procedure which has a insert statement init.
    I have encountered an column value too large error in that procedure.
    I want to know exactly in which column the error has come
    Any ideas,
    Thanks
    Hari

    What is your insert statement? I get the exact column name here.
    SQL> create table sample1(col1 number(1), col2 number(3), col3 varchar2(2))
      2  /
    Table created.
    SQL> insert into sample1
      2  select 1, 2, 'A' from dual
      3  union
      4  select 1,333, 'B' from dual
      5  union
      6  select 2, 44, 'CCC' from dual
      7  /
    insert into sample1
    ERROR at line 1:
    ORA-12899: value too large for column "ETL_USER"."SAMPLE1"."COL3" (actual: 3,
    maximum: 2)
    SQL> Cheers
    Sarma.

  • Discoverer 'Value too large' error

    Hi All,
    I have been stuck with a problem with the Oracle Discoverer Plus 10g (10.1.2.55.26) since the last 2 days, tried out all the possible options mentioned on Forums and elsewhere, but somehow nothing seems to help. So I'm turning in to the experts for help. Below is a description:
    We have a report on Discoverer which is giving us the 'ORA-12899 value too large for column', whenever we try to schedule it thru the Scheduler. The report runs okay if we run manually. In order to remediate the problem, I did the following:
    1. Identify the Business Areas associated with that report, and map the column in question to its base table.
    2. Could see that the column is a varchar2 column, and so I altered its length from 50 to 200,
    3. Once the column was altered, I deleted it from all the complex folders on its Business Areas, and added it again by copying from the simple folder (which maps directly to the column in the table).
    4. Then I refreshed all the BA's so that the new column length would be picked up everywhere, and the refresh went successfully.
    5. I deleted all the existing scheduled workbooks with errors, and tried to schedule again.
    Even then, the workbook still throws the same 'ORA-12899 value too large for column (actual: 57, maximum:50)'. Not sure what step is missing while refreshing the EUL which is causing this error.
    Please advise!
    Thanks.

    Hi,
    Just wanted to mention that we were able to locate and fix the problem yesterday evening. There was another complex folder which also had the same element, and we missed changing that the first time. On doing that change, deleting and rescheduling the report, it started to work perfectly
    Thanks.

  • Value too large error, while upgrading

    Hi
    We have been upgrading EBS 11i to R12.1.1 on IBM AIX6.1 with db 11.2.0.3.
    while applying patch 6678700
    we faced an issue
    the worker fails saying:
    xxxxx/log> tail -f adwork002.log
    sqlplus -s APPS/***** @xxxx/apps/apps_st/appl/ap/12.0.0/patch/115/sql/apstca01.sql &un_ap &batchsize 24 40
    DECLARE
    ERROR at line 1:
    ORA-12899: value too large for column "AP"."AP_SUPPLIER_SITES_ALL"."CITY"
    (actual: 26, maximum: 25)
    ORA-06512: at line 631
    Time when worker failed: Sat Oct 26 2013 02:27:10
    what should we do?
    I searched on metalink. but could not find anything relevant.
    Thanks
    dba88

    dba88 wrote:
    Hi
    We have been upgrading EBS 11i to R12.1.1 on IBM AIX6.1 with db 11.2.0.3.
    while applying patch 6678700
    we faced an issue
    the worker fails saying:
    xxxxx/log> tail -f adwork002.log
    sqlplus -s APPS/***** @xxxx/apps/apps_st/appl/ap/12.0.0/patch/115/sql/apstca01.sql &un_ap &batchsize 24 40
    DECLARE
    ERROR at line 1:
    ORA-12899: value too large for column "AP"."AP_SUPPLIER_SITES_ALL"."CITY"
    (actual: 26, maximum: 25)
    ORA-06512: at line 631
    Time when worker failed: Sat Oct 26 2013 02:27:10
    what should we do?
    I searched on metalink. but could not find anything relevant.
    Thanks
    dba88
    Please see (Apstca01.Sql Faile In 6678700 (Doc ID 1449827.1)).
    Thanks,
    Hussein

  • ODI Datastore Length differs with the DB length -IKM throws value too large

    ODI datastore when reverse engineered shows different length to that of the datalength in the actual db.
    ODI Datastore column details: char(44)
    Target db column : varchar2(11 char)
    The I$ table inserts char44 into varchar2(11char) in the target. As the source column value is empty ODI throws
    "ORA-12899: value too large for column (actual: 44, maximum: 11).

    Yes. I have reverse engineered the target also.
    source datatype     varchar2(11 char)
    After Reverse Engineering
    odi datstore datatype-Source :  char(44)
    target datatype: varchar2(11 char)
    after Reverse Engineering
    odi datstore datatype-Target :  char(44)
    Since the target datastore is char(44) in ODI Datastore and the values in the source column are null/spaces, the IKM inserts them into the target Column which is of 11 Char and the above mentioned value too large error occurs.
    There are no junk values seen on the column and I tried with substr(column,1,7) and
    Trim functions too and it does not help.

  • SQL Error: ORA-12899: value too large for column

    Hi,
    I'm trying to understand the above error. It occurs when we are migrating data from one oracle database to another:
    Error report:
    SQL Error: ORA-12899: value too large for column "USER_XYZ"."TAB_XYZ"."COL_XYZ" (actual: 10, maximum: 8)
    12899. 00000 - "value too large for column %s (actual: %s, maximum: %s)"
    *Cause:    An attempt was made to insert or update a column with a value
    which is too wide for the width of the destination column.
    The name of the column is given, along with the actual width
    of the value, and the maximum allowed width of the column.
    Note that widths are reported in characters if character length
    semantics are in effect for the column, otherwise widths are
    reported in bytes.
    *Action:   Examine the SQL statement for correctness.  Check source
    and destination column data types.
    Either make the destination column wider, or use a subset
    of the source column (i.e. use substring).
    The source database runs - Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production
    The target database runs - Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
    The source and target table are identical and the column definitions are exactly the same. The column we get the error on is of CHAR(8). To migrate the data we use either a dblink or oracle datapump, both result in the same error. The data in the column is a fixed length string of 8 characters.
    To resolve the error the column "COL_XYZ" gets widened by:
    alter table TAB_XYZ modify (COL_XYZ varchar2(10));
    -alter table TAB_XYZ succeeded.
    We now move the data from the source into the target table without problem and then run:
    select max(length(COL_XYZ)) from TAB_XYZ;
    -8
    So the maximal string length for this column is 8 characters. To reduce the column width back to its original 8, we then run:
    alter table TAB_XYZ modify (COL_XYZ varchar2(8));
    -Error report:
    SQL Error: ORA-01441: cannot decrease column length because some value is too big
    01441. 00000 - "cannot decrease column length because some value is too big"
    *Cause:   
    *Action:
    So we leave the column width at 10, but the curious thing is - once we have the data in the target table, we can then truncate the same table at source (ie. get rid of all the data) and move the data back in the original table (with COL_XYZ set at CHAR(8)) - without any issue.
    My guess the error has something to do with the storage on the target database, but I would like to understand why. If anybody has an idea or suggestion what to look for - much appreciated.
    Cheers.

    843217 wrote:
    Note that widths are reported in characters if character length
    semantics are in effect for the column, otherwise widths are
    reported in bytes.You are looking at character lengths vs byte lengths.
    The data in the column is a fixed length string of 8 characters.
    select max(length(COL_XYZ)) from TAB_XYZ;
    -8
    So the maximal string length for this column is 8 characters. To reduce the column width back to its original 8, we then run:
    alter table TAB_XYZ modify (COL_XYZ varchar2(8));varchar2(8 byte) or varchar2(8 char)?
    Use SQL Reference for datatype specification, length function, etc.
    For more info, reference {forum:id=50} forum on the topic. And of course, the Globalization support guide.

  • I am getting error "ORA-12899: value too large for column".

    I am getting error "ORA-12899: value too large for column" after upgrading to 10.2.0.4.0
    Field is updating only through trigger with hard coded value.
    This happens randomly not everytime.
    select * from v$version
    Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
    PL/SQL Release 10.2.0.4.0 - Production
    CORE     10.2.0.4.0     Production
    TNS for Linux: Version 10.2.0.4.0 - Production
    NLSRTL Version 10.2.0.4.0 - Production
    Table Structure
    desc customer
    Name Null? Type
    CTRY_CODE NOT NULL CHAR(3 Byte)
    CO_CODE NOT NULL CHAR(3 Byte)
    CUST_NBR NOT NULL NUMBER(10)
    CUST_NAME CHAR(40 Byte)
    RECORD_STATUS CHAR(1 Byte)
    Trigger on the table
    CREATE OR REPLACE TRIGGER CUST_INSUPD
    BEFORE INSERT OR UPDATE
    ON CUSTOMER FOR EACH ROW
    BEGIN
    IF INSERTING THEN
    :NEW.RECORD_STATUS := 'I';
    ELSIF UPDATING THEN
    :NEW.RECORD_STATUS := 'U';
    END IF;
    END;
    ERROR at line 1:
    ORA-01001: invalid cursor
    ORA-06512: at "UPDATE_CUSTOMER", line 1320
    ORA-12899: value too large for column "CUSTOMER"."RECORD_STATUS" (actual: 3,
    maximum: 1)
    ORA-06512: at line 1
    Edited by: user4211491 on Nov 25, 2009 9:30 PM
    Edited by: user4211491 on Nov 25, 2009 9:32 PM

    SQL> create table customer(
      2  CTRY_CODE  CHAR(3 Byte) not null,
      3  CO_CODE  CHAR(3 Byte) not null,
      4  CUST_NBR NUMBER(10) not null,
      5  CUST_NAME CHAR(40 Byte) ,
      6  RECORD_STATUS CHAR(1 Byte)
      7  );
    Table created.
    SQL> CREATE OR REPLACE TRIGGER CUST_INSUPD
      2  BEFORE INSERT OR UPDATE
      3  ON CUSTOMER FOR EACH ROW
      4  BEGIN
      5  IF INSERTING THEN
      6  :NEW.RECORD_STATUS := 'I';
      7  ELSIF UPDATING THEN
      8  :NEW.RECORD_STATUS := 'U';
      9  END IF;
    10  END;
    11  /
    Trigger created.
    SQL> insert into customer(CTRY_CODE,CO_CODE,CUST_NBR,CUST_NAME,RECORD_STATUS)
      2                values('12','13','1','Mahesh Kaila','UPD');
                  values('12','13','1','Mahesh Kaila','UPD')
    ERROR at line 2:
    ORA-12899: value too large for column "HPVPPM"."CUSTOMER"."RECORD_STATUS"
    (actual: 3, maximum: 1)
    SQL> insert into customer(CTRY_CODE,CO_CODE,CUST_NBR,CUST_NAME)
      2                values('12','13','1','Mahesh Kaila');
    1 row created.
    SQL> set linesize 200
    SQL> select * from customer;
    CTR CO_   CUST_NBR CUST_NAME                                R
    12  13           1 Mahesh Kaila                             I
    SQL> update customer set cust_name='tst';
    1 row updated.
    SQL> select * from customer;
    CTR CO_   CUST_NBR CUST_NAME                                R
    12  13           1 tst                                      Urecheck your code once again..somewhere you are using record_status column for insertion or updation.
    Ravi Kumar

  • EXEC SQL Error: ORA-01401: Inserted value too large for column

    Getting this SQL Error: ORA-01401: Inserted value too large for column..on an EXEC SQL Insert statement when writing to an
    external Oracle DB from SAP.
    On further analysis..it appears that this happens to the fields..when the string length matches the field length.
    Example:  Plant field is defined as char(4) on the SAP side and it is a Varchar2(4) on the Oracle side.
    When a value like '1015' is passed thru a variable in the insert statement then this ORA-01401 error pops up.
    No error:
       - if the value '1015' is passed directly in the insert statement to the external table  (or)
       - when a value with 3 chars or less(like the first three chars..101) is passed thru a variable  defined as 'Plant(4) type c'.
       - when using EXEC sql within SAP
       - when reading from the external db table
    This was working ok until the  Oracle Patch P9147110 was installed recently.
    Any suggestions !

    Hello Dvas,
    what's the characterset of your external database?
    What's the column definition in your external database (byte or character based)?
    If you use a characeterset like UTF8 it is possible, that one character needs more than one byte and then you will run into such kind of issues if the definition is too small.
    Regards
    Stefan

  • Getting error ORA-01401: inserted value too large for column

    Hello ,
    I have Configured the scenario IDOC to JDBC .In the SXMB_MONI am getting the succes message .But in the Adapter Monitor am getting the error message as
    ORA-01401: inserted value too large for column and the entries also not inserted in to the table.I hope this is because of the date format only.In Oracle table date field has defined in the format of '01-JAN-2005'.I am also passing the date field in the same format only for INVOICE_DATE and INVOICE_DUE_DATE.Please see the target structure .
    <?xml version="1.0" encoding="UTF-8" ?>
    - <ns:INVOICE_INFO_MT xmlns:ns="http://sap.com/xi/InvoiceIDoc_Test">
    - <Statement>
    - <INVOICE_INFO action="INSERT">
    - <access>
      <INVOICE_ID>0090000303</INVOICE_ID>
      <INVOICE_DATE>01-Dec-2005</INVOICE_DATE>
      <INVOICE_DUE_DATE>01-Jan-2005</INVOICE_DUE_DATE>
      <ORDER_ID>0000000000011852</ORDER_ID>
      <ORDER_LINE_NUM>000010</ORDER_LINE_NUM>
      <INVOICE_TYPE>LR</INVOICE_TYPE>
      <INVOICE_ORGINAL_AMT>10000</INVOICE_ORGINAL_AMT>
      <INVOICE_OUTSTANDING_AMT>1000</INVOICE_OUTSTANDING_AMT>
      <INTERNAL_USE_FLG>X</INTERNAL_USE_FLG>
      <BILLTO>0004000012</BILLTO>
      <SHIPTO>40000006</SHIPTO>
      <STATUS_ID>O</STATUS_ID>
      </access>
      </INVOICE_INFO>
      </Statement>
      </ns:INVOICE_INFO_MT>
    Please let me know what are all the possible solution to fix the error and to insert the entries in the table.
    Thanks in Advance!

    Hi muthu,
    // inserted value too large for column
    When your oracle insertion throws this error, it implies that some value that you are trying to insert into the table is larger than the allocated size.
    Just check the format of your table and the respective size of each field on your oracle cleint by using the command,
    DESCRIBE <tablename> .
    and then verify it with the input. I dont think the problem is with the DATE format because if it is not a valid date format, you would have got on error like
    String Literal does not match type
    Hope this helps,
    Regards,
    Bhavesh

  • Replicat error: ORA-12899: value too large for column ...

    Hi,
    In our system Source and Target are on the same physical server and in the same Oracle instance. Just different schemes.
    Tables on the target were created as 'create table ... as select * from ... source_table', so they have a similar structure. Table names are also similar.
    I started replicat, it worked fine for several hours, but when I inserted Chinese symbols into the source table I got an error:
    WARNING OGG-00869 Oracle GoldenGate Delivery for Oracle, OGGEX1.prm: OCI Error ORA-12899: value too large for column "MY_TARGET_SCHEMA"."TABLE1"."*FIRSTNAME*" (actual: 93, maximum: 40) (status = 12899), SQL <INSERT INTO "MY_TARGET_SCHEMA"."TABLE1" ("USERID","USERNAME","FIRSTNAME","LASTNAME",....>.
    FIRSTNAME is Varchar2(40 char) field.
    I suppose the problem probably is our database is running with NLS_LENGTH_SEMANTICS='CHAR'
    I've double checked tables structure on the target - it's identical with the source.
    I also tried to manually insert this record into the target table using 'insert into ... select * from ... ' statement - it works. The problem seems to be in the replicat.
    How to fix this error?
    Thanks in advance!
    Oracle GoldenGate version: 11.1.1.1
    Oracle Database version: 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
    NLS_LANG: AMERICAN_AMERICA.AL32UTF8
    NLS_LENGTH_SEMANTICS='CHAR'
    Edited by: DeniK on Jun 20, 2012 11:49 PM
    Edited by: DeniK on Jun 23, 2012 12:05 PM
    Edited by: DeniK on Jun 25, 2012 1:55 PM

    I've created the definition files and compared them. They are absolutely identical, apart from source and target schema names:
    Source definition file:
    Definition for table MY_SOURCE_SCHEMA.TABLE1
    Record length: 1632
    Syskey: 0
    Columns: 30
    USERID 134 11 0 0 0 1 0 8 8 8 0 0 0 0 1 0 1 3
    USERNAME 64 80 12 0 0 1 0 80 80 0 0 0 0 0 1 0 0 0
    FIRSTNAME 64 160 98 0 0 1 0 160 160 0 0 0 0 0 1 0 0 0
    LASTNAME 64 160 264 0 0 1 0 160 160 0 0 0 0 0 1 0 0 0
    PASSWORD 64 160 430 0 0 1 0 160 160 0 0 0 0 0 1 0 0 0
    TITLE 64 160 596 0 0 1 0 160 160 0 0 0 0 0 1 0 0 0
    Target definition file:
    Definition for table MY_TAEGET_SCHEMA.TABLE1
    Record length: 1632
    Syskey: 0
    Columns: 30
    USERID 134 11 0 0 0 1 0 8 8 8 0 0 0 0 1 0 1 3
    USERNAME 64 80 12 0 0 1 0 80 80 0 0 0 0 0 1 0 0 0
    FIRSTNAME 64 160 98 0 0 1 0 160 160 0 0 0 0 0 1 0 0 0
    LASTNAME 64 160 264 0 0 1 0 160 160 0 0 0 0 0 1 0 0 0
    PASSWORD 64 160 430 0 0 1 0 160 160 0 0 0 0 0 1 0 0 0
    TITLE 64 160 596 0 0 1 0 160 160 0 0 0 0 0 1 0 0 0
    Edited by: DeniK on Jun 25, 2012 1:56 PM
    Edited by: DeniK on Jun 25, 2012 1:57 PM

  • Snapshot refresh error:  ora-01401 inserted value too large for column

    I have an error ora-01401 "Inserted value too large for column" when I try to do a refresh on a group at the materialized view site.
    My model is 1 master replicating to a readonly materialized view site. I have 2 refresh groups for separate sets of tables. 1 refresh group work fine...the other I got the above error.
    I have doubled the rbs and system tablespace without any help thinking that I must be running out of default rollback segment space.
    Anyone has this before?

    The error is related to a field, not to any tablespace. This normaly happens to me when I change the lenght or resolution of a field in the base tables. The structure changes don't "flow" to the materialized view! I must "regenerate" them. Normally droping and creating it again to make them receive the new lenght of that field.
    Sometimes, when the field changed is not part of any primary key I have changes directly the field in the materialized view as if it was a normal table.
    Hope this helps
    Luis

  • Data Profiling - Value too large for column error

    I am running a data profile which completes with errors. The error being reported is an ORA 12899 Value too large for column actual (41 maximum 40).
    I have checked the actual data in the table and the maximum is only 40 characters.
    Any ideas on how to solve this. Even though it completes no actual profile is done on the data due to the error.
    OWB version 11.2.0.1
    Log file below.
    Job     Rows Selected     Rows Inserted     Rows Updated     Rows Deleted     Errors     Warnings     Start Time     Elapsed Time     
    Profile_1306385940099                                   2011-05-26 14:59:00.0     106     
    Data profiling operations complete.                                             
    Redundant column analysis for objects complete in 0 s.                                              
    Redundant column analysis for objects.                                              
    Referential analysis for objects complete in 0.405 s.                                              
    Referential analysis for objects.                                              
    Referential analysis initialization complete in 8.128 s.                                             
    Referential analysis initialization.                                             
    Data rule analysis for object TABLE_NAME complete in 0 s.                                             
    Data rule analysis for object TABLE_NAME                                             
    Functional dependency and unique key discovery for object TABLE_NAME complete in 0 s.                                             
    Functional dependency and unique key discovery for object TABLE_NAME                                             
    Domain analysis for object TABLE_NAME complete in 0.858 s.                                             
    Domain analysis for object TABLE_NAME                                             
    Pattern analysis for object TABLE_NAME complete in 0.202 s.                                             
    Pattern analysis for object TABLE_NAME                                             
    Aggregation and Data Type analysis for object TABLE_NAME complete in 9.236 s.                                             
    Aggregation and Data Type analysis for object TABLE_NAME                                             
    Functional dependency and unique key discovery for object TABLE_NAME complete in 0 s.                                             
    Functional dependency and unique key discovery for object TABLE_NAME                                             
    Domain analysis for object TABLE_NAME complete in 0.842 s.                                             
    Domain analysis for object TABLE_NAME                                             
    Pattern analysis for object TABLE_NAME complete in 0.187 s.                                             
    Pattern analysis for object TABLE_NAME                                             
    Aggregation and Data Type analysis for object TABLE_NAME complete in 9.501 s.                                             
    Aggregation and Data Type analysis for object TABLE_NAME                                             
    Functional dependency and unique key discovery for object TABLE_NAME complete in 0 s.                                             
    Functional dependency and unique key discovery for object TABLE_NAME                                             
    Domain analysis for object TABLE_NAME complete in 0.717 s.                                             
    Domain analysis for object TABLE_NAME                                             
    Pattern analysis for object TABLE_NAME complete in 0.156 s.                                             
    Pattern analysis for object TABLE_NAME                                             
    Aggregation and Data Type analysis for object TABLE_NAME complete in 9.906 s.                                             
    Aggregation and Data Type analysis for object TABLE_NAME                                             
    Functional dependency and unique key discovery for object TABLE_NAME complete in 0 s.                                             
    Functional dependency and unique key discovery for object TABLE_NAME                                             
    Domain analysis for object TABLE_NAME complete in 0.827 s.                                             
    Domain analysis for object TABLE_NAME                                             
    Pattern analysis for object TABLE_NAME complete in 0.187 s.                                             
    Pattern analysis for object TABLE_NAME                                             
    Aggregation and Data Type analysis for object TABLE_NAME complete in 9.172 s.                                             
    Aggregation and Data Type analysis for object TABLE_NAME                                             
    Functional dependency and unique key discovery for object TABLE_NAME complete in 0 s.                                             
    Functional dependency and unique key discovery for object TABLE_NAME                                             
    Domain analysis for object TABLE_NAME complete in 0.889 s.                                             
    Domain analysis for object TABLE_NAME                                             
    Pattern analysis for object TABLE_NAME complete in 0.202 s.                                             
    Pattern analysis for object TABLE_NAME                                             
    Aggregation and Data Type analysis for object TABLE_NAME complete in 9.313 s.                                             
    Aggregation and Data Type analysis for object TABLE_NAME                                             
    Execute data prepare map for object TABLE_NAME complete in 9.267 s.                                             
    Execute data prepare map for object TABLE_NAME                                             
    Execute data prepare map for object TABLE_NAME complete in 10.187 s.                                             
    Execute data prepare map for object TABLE_NAME                                             
    Execute data prepare map for object TABLE_NAME complete in 8.019 s.                                             
    Execute data prepare map for object TABLE_NAME                                             
    Execute data prepare map for object TABLE_NAME complete in 5.507 s.                                             
    Execute data prepare map for object TABLE_NAME                                             
    Execute data prepare map for object TABLE_NAME complete in 10.857 s.                                             
    Execute data prepare map for object TABLE_NAME                                             
    Parameters                                             
    O82647310CF4D425C8AED9AAE_MAP_ProfileLoader                              1     2011-05-26 14:59:00.0     11     
    ORA-12899: value too large for column "SCHEMA"."O90239B0C1105447EB6495C903678"."ITEM_NAME_1" (actual: 41, maximum: 40)                                             
    Parameters                                             
    O68A16A57F2054A13B8761BDC_MAP_ProfileLoader                              1     2011-05-26 14:59:11.0     5     
    ORA-12899: value too large for column "SCHEMA"."O0D9332A164E649F3B4D05D045521"."ITEM_NAME_1" (actual: 41, maximum: 40)                                             
    Parameters                                             
    O78AD6B482FC44D8BB7AF8357_MAP_ProfileLoader                              1     2011-05-26 14:59:16.0     9     
    ORA-12899: value too large for column "SCHEMA"."OBF77A8BA8E6847B8AAE4522F98D6"."ITEM_NAME_2" (actual: 41, maximum: 40)                                             
    Parameters                                             
    OA79DF482D74847CF8EA05807_MAP_ProfileLoader                              1     2011-05-26 14:59:25.0     10     
    ORA-12899: value too large for column "SCHEMA"."OB0052CBCA5784DAD935F9FCF2E28"."ITEM_NAME_1" (actual: 41, maximum: 40)                                             
    Parameters                                             
    OFFE486BBDB884307B668F670_MAP_ProfileLoader                              1     2011-05-26 14:59:35.0     9     
    ORA-12899: value too large for column "SCHEMA"."O9943284818BB413E867F8DB57A5B"."ITEM_NAME_1" (actual: 42, maximum: 40)                                             
    Parameters

    Found the answer. It was the database character set for multi byte character sets.

  • Rawtohex  - How to Insert ? ORA-12899: value too large for column

    Hi,
    Can any one please help me to resolve the following issue ?
    Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
    PL/SQL Release 10.2.0.4.0 - Production
    Name Null? Type
    ABC_OID NOT NULL RAW(8)
    ABC_NAME NOT NULL VARCHAR2(30 CHAR)
    UPDATE_TIME NOT NULL DATE
    UPDATE_BY_WORKER_NO NOT NULL NUMBER
    I'm able to insert 1st 2 records but when am inseerting 3rd one am getting error:-
    insert into caps.ABC_LOOKUP values( rawtohex('SERIES'), 'SERIES','19-FEB-09','1065449')
    insert into caps.ABC_LOOKUP values(rawtohex('FAMILY'),'FAMILY','19-FEB-09','1065449')
    Insert into caps.ABC_LOOKUP values(rawtohex('CONNECTOR'),'CONNECTOR','19-FEB-09','1065449')
    ERROR at line 1:
    ORA-12899: value too large for column
    "XYZ"."ABC_LOOKUP"."ABC_OID" (actual: 9, maximum: 8)
    Thanks in Advance.....

    Yes, Done...
    Actually I suggested same thing to them (application), But they did not agree with me then i got confused :-)
    Now the same thing worked well..Thanks a lot for your time

  • Java.sql.BatchUpdateException: ORA-12899[ value too large for column.......

    Hi All,
    I am using SOA 11g(11.1.1.3). I am trying to insert data in to a table coming from a file. I have encountered the fallowing error.
    Exception occured when binding was invoked.
    Exception occured during invocation of JCA binding: "JCA Binding execute of Reference operation 'insert' failed due to: DBWriteInteractionSpec Execute Failed Exception.
    *insert failed. Descriptor name: [UploadStgTbl.XXXXStgTbl].*
    Caused by java.sql.BatchUpdateException: ORA-12899: value too large for column "XXXX"."XXXX_STG_TBL"."XXXXXX_XXXXX_TYPE" (actual: 20, maximum: 15)
    *The invoked JCA adapter raised a resource exception.*
    *Please examine the above error message carefully to determine a resolution.*
    The data type of the column errored out is VARCHAR2(25). I found related issue in metalink, java.sql.BatchUpdateException (ORA-12899) Reported When DB Adapter Reads a Row From a Table it is Polling For Added Rows [ID 1113215.1].
    But the solution seems not applicable in my case...
    Can anyone encountered same issue?? Is this a bug? If it is a bug, do we have patch for this bug??
    Please help me out...
    Thank you all...
    Edited by: 806364 on Dec 18, 2010 12:01 PM

    It didn't work.
    After I changed length of that column of the source datastore (from 15 to 16), ODI created temporary tables (C$ with I$) with larger columns (16 instead of 15) but I got the same error message.
    I'm wondering why I have to extend length of source datastore in the source model if there are no values in the source table with a length greather than 15....
    Any other idea? Thanks !

  • Adding virtual column: ORA-12899: value too large for column

    I'm using Oracle 11g, Win7 OS, SQL Developer
    I'm trying to add virtual column to my test table, but getting ORA-12899: value too large for column error. Below are the details.
    Can someone help me in this?
    CREATE TABLE test_reg_exp
    (col1 VARCHAR2(100));
    INSERT INTO test_reg_exp (col1) VALUES ('ABCD_EFGH');
    INSERT INTO test_reg_exp (col1) VALUES ('ABCDE_ABC');
    INSERT INTO test_reg_exp (col1) VALUES ('WXYZ_ABCD');
    INSERT INTO test_reg_exp (col1) VALUES ('ABCDE_PQRS');
    INSERT INTO test_reg_exp (col1) VALUES ('ABCD_WXYZ');
    ALTER TABLE test_reg_exp
    ADD (col2 VARCHAR2(100) GENERATED ALWAYS AS (REGEXP_REPLACE (col1, '^ABCD[A-Z]*_')));
    SQL Error: ORA-12899: value too large for column "COL2" (actual: 100, maximum: 400)
    12899. 00000 -  "value too large for column %s (actual: %s, maximum: %s)"
    *Cause:    An attempt was made to insert or update a column with a value
               which is too wide for the width of the destination column.
               The name of the column is given, along with the actual width
               of the value, and the maximum allowed width of the column.
               Note that widths are reported in characters if character length
               semantics are in effect for the column, otherwise widths are
               reported in bytes.
    *Action:   Examine the SQL statement for correctness.  Check source
               and destination column data types.
               Either make the destination column wider, or use a subset
               of the source column (i.e. use substring).When I try to select, I'm getting correct results:
    SELECT col1, (REGEXP_REPLACE (col1, '^ABCD[A-Z]*_'))
    FROM test_reg_exp;Thanks.

    Yes RP, it working if you give col2 size >=400.
    @Northwest - Could you please test the same w/o having a regex clause in col2?
    I doubt on the usage of a REGEX in this dynamic col case.
    Refer this (might help) -- http://www.oracle-base.com/articles/11g/virtual-columns-11gr1.php
    Below snippet from above link.... see if this helps...
    >
    Notes and restrictions on virtual columns include:
    Indexes defined against virtual columns are equivalent to function-based indexes.
    Virtual columns can be referenced in the WHERE clause of updates and deletes, but they cannot be manipulated by DML.
    Tables containing virtual columns can still be eligible for result caching.
    Functions in expressions must be deterministic at the time of table creation, but can subsequently be recompiled and made non-deterministic without invalidating the virtual column. In such cases the following steps must be taken after the function is recompiled:
    Constraint on the virtual column must be disabled and re-enabled.
    Indexes on the virtual column must be rebuilt.
    Materialized views that access the virtual column must be fully refreshed.
    The result cache must be flushed if cached queries have accessed the virtual column.
    Table statistics must be regathered.
    Virtual columns are not supported for index-organized, external, object, cluster, or temporary tables.
    The expression used in the virtual column definition has the following restrictions:
    It cannot refer to another virtual column by name.
    It can only refer to columns defined in the same table.
    If it refers to a deterministic user-defined function, it cannot be used as a partitioning key column.
    The output of the expression must be a scalar value. It cannot return an Oracle supplied datatype, a user-defined type, or LOB or LONG RAW.
    >
    Edited by: ranit B on Oct 16, 2012 11:48 PM
    Edited by: ranit B on Oct 16, 2012 11:54 PM

Maybe you are looking for