Oracle 11g 64 bit - "Value too large for column" when setting Varchar2

Hello guys,
I have a machine running Oracle 11g - 64bits. And I have a table that contains a VARCHAR2(2000) field.
When I try to set the value of this field to a string that contains double byte characters, I get this error:
ORA-12899: value too large for column "QAPBG1220_11"."MYTABLE"."MYFIELD" (actual: 2433, maximum: 2000).
Although the value I'm setting is only 811 characters (€ sign).
The weird thing is that when I try to run the same query on another PC with Oracle 11g, 32 bits, It runs normally and the values are updated!!
Anyone has any idea about this? It's driving me crazy
Thanks in advance
Zahraa

create table MYTABLE
MYTABLEID NUMBER(10) not null,
MYFIELD VARCHAR2(2000)
alter table MYTABLE
add constraint PK_MYTABLE primary key (MYTABLEID);
INSERT INTO MYTABLE (Mytableid, Myfield) VALUES(1, '€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€fds€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€')
COMMIT;
On the 32 bit, this works fine. I get the record with the values 1 and 2000 euro signs.
On the 64 bits, there is one machine (oracle 11.2.0.1.0) that adds the row, but when I view it, the value shows as "????"
and another machine (oracle 11.1.0.7.0) that throws an error:
- "String Literal is too long" : if there are more than 1333 euro characters
- Value too large for column .... : if there are less than 1333 and more than 666 characters.
Any ideas?

Similar Messages

  • Oracle : ORA-12899: value too large for column

    Hi Experts,
    I am loading multibyte data from fixed width flat file to Oracle database(which is a utf8 characterset) via Informatica. I have set utf8 as characterset in both source and target definitions.
    Source flat file data : Münchener(this flat file data was loaded from external oracle database where data looks like Münchener)
    When I load the data I am getting below error
    ORA-12899: value too large for column "schema_name"."table"."column" (actual: 513, maximum: 512)
    I know we can declare the data type as varchar2(512 char) instead of varchar2(512 byte). Please let me know the other solution to load multibyte data into target utf8 database.

    You answered your own question and there isn't another solution. You need to increase that column.
    alter table "schema_name"."table" ("column" varchar2(513)); ---Though you should increase it to be the max length that column will ever be. If you don't know pad it. Pad it high. Oracle is very good at handling the space with the varchar2 datatype.

  • 'ORA-01401 inserted value too large for column' - 9i

    I am migrating a java application from 8i to 9i. The application is writing data to a oracle 8i database without any problem.
    When the underlying database source is switched to oracle 9i database(same databaseschema as 8i) by pointing to 9i instance , the application is
    encountering the error: 'ORA-01401 inserted value too large for column' when trying to insert a particular field. The fileld is declared as varchar2(400) in the both the database.
    The debug output from application also shows that the column data being inserted as 10 characters.The insert statement from SQLPLUS works fine. So it's looks like an issue with the JDBC driver for the 9i server. I am wondering if anyone has observed such strange behavior.
    Thanks
    Vijay

    Vijay,
    Are you using OCI driver ? There is a known issue with OCI driver when using setFixedCHAR before an INSERT statement. This problem only happens with a string of length zero. There is no known issue with THIN Driver. This is fixed in Oracle9i Release 2.
    regards
    Debu Panda
    Oracle

  • 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

  • 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

  • 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.

  • Install fails due to ORA-12899: value too large for column

    Hi,
    Our WCS 11g installation on Tomcat 7 fails giving a "ORA-12899: value too large for column".
    As per the solution ticket https://support.oracle.com/epmos/faces/DocumentDisplay?id=1539055.1 we have to set "-Dfile.encoding=UTF-8" in tomcat.
    We have done this beforehand by setting the variable in catalina.bat in tomcat 7 bin as shown below
    But still we get the same error while installation.
    If anybody has faced this , let us know how you resolved it

    We were unable to install WCS on Tomcat 7 but on Tomcat 6 by specifying "-Dfile.encoding=UTF-8" in java options using "Tomcat Configure" it was succesful.
    An alternative we found was to increase the value of the column itself.
    Using command
    ALTER TABLE csuser.systemlocalestring
    MODIFY value varchar2 (4000)

  • 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

  • ORA-12899: value too large for column

    Hi Experts,
    I am getting data from erp systems in the form of feeds,in particular one column length in feed is 3 only.
    In target table also corresponded column also length is varchar2(3)
    but when i am trying to load same into db ti showing error like:
    ORA-12899: value too large for column
    emp_name (actual: 4, maximum: 3)
    i am using data base version :
    Oracle Database 11g Express Edition Release 11.2.0.2.0 - Production
    but this is resolved when the time of increasing target column length to varchar2(5) from varchar2(3)..but i checked length of that column in feed is 3 only...
    my question is why we need to increase the target column length?
    Thanks,
    Surya

    >
    my question is why we need to increase the target column length?
    >
    That can be caused if the two systems are using different character sets. If one is using a single-byte character set like ASCII and the other uses multi-byte like UTF16.
    Three BYTES is three bytes but three CHAR is three bytes in ASCII but six bytes for UTF16.
    Do you know what character sets are being used?
    See the Database Concepts doc
    http://docs.oracle.com/cd/B28359_01/server.111/b28318/datatype.htm
    >
    Length Semantics for Character Datatypes
    Globalization support allows the use of various character sets for the character datatypes. Globalization support lets you process single-byte and multibyte character data and convert between character sets. Client sessions can use client character sets that are different from the database character set.
    Consider the size of characters when you specify the column length for character datatypes. You must consider this issue when estimating space for tables with columns that contain character data.
    The length semantics of character datatypes can be measured in bytes or characters.
    •Byte semantics treat strings as a sequence of bytes. This is the default for character datatypes.
    •Character semantics treat strings as a sequence of characters. A character is technically a codepoint of the database character set.
    For single byte character sets, columns defined in character semantics are basically the same as those defined in byte semantics. Character semantics are useful for defining varying-width multibyte strings; it reduces the complexity when defining the actual length requirements for data storage. For example, in a Unicode database (UTF8), you must define a VARCHAR2 column that can store up to five Chinese characters together with five English characters. In byte semantics, this would require (5*3 bytes) + (1*5 bytes) = 20 bytes; in character semantics, the column would require 10 characters.
    VARCHAR2(20 BYTE) and SUBSTRB(<string>, 1, 20) use byte semantics. VARCHAR2(10 CHAR) and SUBSTR(<string>, 1, 10) use character semantics.
    The parameter NLS_LENGTH_SEMANTICS decides whether a new column of character datatype uses byte or character semantics. The default length semantic is byte. If all character datatype columns in a database use byte semantics (or all use character semantics) then users do not have to worry about which columns use which semantics. The BYTE and CHAR qualifiers shown earlier should be avoided when possible, because they lead to mixed-semantics databases. Instead, the NLS_LENGTH_SEMANTICS initialization parameter should be set appropriately in the server parameter file (SPFILE) or initialization parameter file, and columns should use the default semantics.

  • 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

  • Inserted value too large for column error while scheduling a job

    Hi Everyone,
    I am trying to schedule a PL SQL script as a job in my Oracle 10g installed and running on Windows XP.
    While trying to Submit the job I get the error as "Inserted value too large for column:" followed by my entire code. The code is correct - complies and runs in Oracle ApEx's SQL Workshop.
    The size of my code is 4136 character, 4348 bytes and 107 lines long. It is a code that sends an e-mail and has a +utl_smtp.write_data([Lots of HTML])+
    There is no insert statement in the code whatsoever, the code only queries the database for data...
    Any idea as to why I might be getting this error??
    Thanks in advance
    Sid

    The size of my code is 4136 character, 4348 bytes and 107 lines long. It is a code that sends an e-mail and has a utl_smtp.write_data(Lots of HTML)SQL variable has maximum size of 4000

  • Fdpstp failed due to ora-12899 value too large for column

    Hi All,
    User facing this problem while running the concurrent program.
    the program is complted but with rhis error.
    fdpstp failed due to ora-12899 value too large for column
    Can any one tell me the excat solution for this?
    RDBMS : 10.2.0.3.0
    Oracle Applications : 11.5.10.2

    User facing this problem while running the concurrent program.
    the program is complted but with rhis error.Is this a seeded or custom concurrent program?
    fdpstp failed due to ora-12899 value too large for column
    Can any one tell me the excat solution for this?Was this working before? If yes, any changes been done recently?
    Can other users run the same concurrent program with no issues?
    Please post the contents of the concurrent request log file here.
    Please ask your developer to open the file using Reports Builder and compile the report and run it (if possible) with the same parameters.
    OERR: ORA-12899 value too large for column %s (actual: %s, maximum: %s) [ID 287754.1]
    Thanks,
    Hussein

  • Value too large for column "OIMDB"."UPA_FIELDS"."FIELD_NEW_VALUE"

    I am running OIM 9.1.0.1849.0 build 1849.0 on Windows Server 2003
    I see the following stack trace repeatedly in c:\jboss-4.0.3SP1\server\default\log\server.log
    I am hoping someone might be able help me resolve this issue.
    Thanks in advance
    ...Lyall
    java.sql.SQLException: ORA-12899: value too large for column "OIMDB"."UPA_FIELDS"."FIELD_NEW_VALUE" (actual: 2461, maximum: 2000)
         at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:112)
         at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:331)
         at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:288)
         at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:745)
         at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:216)
         at oracle.jdbc.driver.T4CPreparedStatement.executeForRows(T4CPreparedStatement.java:966)
         at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1170)
         at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3339)
         at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:3423)
         at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:227)
         at com.thortech.xl.dataaccess.tcDataBase.writePreparedStatement(Unknown Source)
         at com.thortech.xl.dataobj.PreparedStatementUtil.executeUpdate(Unknown Source)
         at com.thortech.xl.audit.auditdataprocessors.UserProfileRDGenerator.insertUserProfileChangedAttributes(Unknown Source)
         at com.thortech.xl.audit.auditdataprocessors.UserProfileRDGenerator.processUserProfileChanges(Unknown Source)
         at com.thortech.xl.audit.auditdataprocessors.UserProfileRDGenerator.processAuditData(Unknown Source)
         at com.thortech.xl.audit.genericauditor.GenericAuditor.processAuditMessage(Unknown Source)
         at com.thortech.xl.audit.engine.AuditEngine.processSingleAudJmsEntry(Unknown Source)
         at com.thortech.xl.audit.engine.AuditEngine.processOfflineNew(Unknown Source)
         at com.thortech.xl.audit.engine.jms.XLAuditMessageHandler.execute(Unknown Source)
         at com.thortech.xl.schedule.jms.messagehandler.MessageProcessUtil.processMessage(Unknown Source)
         at com.thortech.xl.schedule.jms.messagehandler.AuditMessageHandlerMDB.onMessage(Unknown Source)
         at sun.reflect.GeneratedMethodAccessor127.invoke(Unknown Source)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
         at java.lang.reflect.Method.invoke(Method.java:324)
         at org.jboss.invocation.Invocation.performCall(Invocation.java:345)
         at org.jboss.ejb.MessageDrivenContainer$ContainerInterceptor.invoke(MessageDrivenContainer.java:475)
         at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:149)
         at org.jboss.ejb.plugins.MessageDrivenInstanceInterceptor.invoke(MessageDrivenInstanceInterceptor.java:101)
         at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:48)
         at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:106)
         at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:335)
         at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:166)
         at org.jboss.ejb.plugins.RunAsSecurityInterceptor.invoke(RunAsSecurityInterceptor.java:94)
         at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:192)
         at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122)
         at org.jboss.ejb.MessageDrivenContainer.internalInvoke(MessageDrivenContainer.java:389)
         at org.jboss.ejb.Container.invoke(Container.java:873)
         at org.jboss.ejb.plugins.jms.JMSContainerInvoker.invoke(JMSContainerInvoker.java:1077)
         at org.jboss.ejb.plugins.jms.JMSContainerInvoker$MessageListenerImpl.onMessage(JMSContainerInvoker.java:1379)
         at org.jboss.jms.asf.StdServerSession.onMessage(StdServerSession.java:256)
         at org.jboss.mq.SpyMessageConsumer.sessionConsumerProcessMessage(SpyMessageConsumer.java:904)
         at org.jboss.mq.SpyMessageConsumer.addMessage(SpyMessageConsumer.java:160)
         at org.jboss.mq.SpySession.run(SpySession.java:333)
         at org.jboss.jms.asf.StdServerSession.run(StdServerSession.java:180)
         at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:748)
         at java.lang.Thread.run(Thread.java:534)
    2008-09-03 14:32:43,281 ERROR [XELLERATE.AUDITOR] Class/Method: UserProfileRDGenerator/insertUserProfileChangedAttributes encounter some problems: Failed to insert change record in table UPA_FIELDS

    Thankyou,
    Being the OIM noob that I am, had no idea where to look.
    We do indeed have some user defined fields of 4000 characters.
    I am now wondering if I can disable auditing, or maybe increase the size of the auditing database column?
    Also, I guess I should raise a defect in OIM as the User Interface should not allow the creation of a user field for which auditing is unable to cope.
    I also wonder if the audit failures (other than causing lots of stack traces) causes any transaction failures due to transaction rollbacks?
    Edited by: lyallp on Sep 3, 2008 4:01 PM

  • 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

  • Error on reverse on XML: value too large for column

    Hi All,
    I am trying to reverse engineer while creating the data model on XML technology.
    My JDBC URL on data server reads this:
    jdbc:snps:xml?d=../demo/abc/CustomerPartyEBO.xsd&s=MYEBO
    I get an error while doing the reverse.
    java.sql.SQLException: ORA-12899: value too large for column "PINW"."SNP_REV_KEY_COL"."KEY_NAME" (actual: 102, maximum: 100)
    After doing some check through selective reverse, found that this is happening only for few tables, whose names are quite longer.
    Tried setting the "maximum column name length" and "maximum table name length" to 120 and even higher values on XML technology from Topology Manager. No luck there.
    Thanks in advance for any help here.

    That is not the place to change.
    The error states that the SNP_REV_KEY_COL.KEY_NAME in the Work Repository schema PINW has maximum length defined to be 100.
    I donot know if Oracle will support this change but you will have to make a change to the Work Repository table SNP_REV_KEY_COL and change the column lengths as a workaround.

Maybe you are looking for