Update trigger fails with value too large for column error on timestamp

Hello there,
I've got a problem with several update triggers. I've several triggers monitoring a set of tables.
Upon each update the updated data is compared with the current values in the table columns.
If different values are detected the update timestamp is set with the current_timestamp. That
way we have a timestamp that reflects real changes in relevant data. I attached an example for
that kind of trigger below. The triggers on each monitored table only differ in the columns that
are compared.
CREATE OR REPLACE TRIGGER T_ava01_obj_cont
BEFORE UPDATE on ava01_obj_cont
FOR EACH ROW
DECLARE
v_changed boolean := false;
BEGIN
IF NOT v_changed THEN
    v_changed := (:old.cr_adv_id IS NULL AND :new.cr_adv_id IS NOT NULL) OR
                 (:old.cr_adv_id IS NOT NULL AND :new.cr_adv_id IS NULL)OR
                 (:old.cr_adv_id IS NOT NULL AND :new.cr_adv_id IS NOT NULL AND :old.cr_adv_id != :new.cr_adv_id);
END IF;
IF NOT v_changed THEN
    v_changed := (:old.is_euzins_relevant IS NULL AND :new.is_euzins_relevant IS NOT NULL) OR
                 (:old.is_euzins_relevant IS NOT NULL AND :new.is_euzins_relevant IS NULL)OR
                 (:old.is_euzins_relevant IS NOT NULL AND :new.is_euzins_relevant IS NOT NULL AND :old.is_euzins_relevant != :new.is_euzins_relevant);
END IF;
[.. more values being compared ..]
    IF v_changed THEN
    :new.update_ts := current_timestamp;
END IF;
END T_ava01_obj_cont;Really relevant is the statement
:new.update_ts := current_timestamp;So far so good. The problem is, it works the most of time. Only sometimes it fails with the following error:
SQL state [72000]; error code [12899]; ORA-12899: value too large for column "LGT_CLASS_AVALOQ"."AVA01_OBJ_CONT"."UPDATE_TS"
(actual: 28, maximum: 11)
I can't see how the value systimestamp or current_timestamp (I tried both) should be too large for
a column defined as TIMESTAMP(6). We've got tables where more updates occur then elsewhere.
Thats where the most of the errors pop up. Other tables with fewer updates show errors only
sporadicly or even never. I can't see a kind of error pattern. It's like that every 10.000th update
or less failes.
I was desperate enough to try some language dependend transformation like
IF v_changed THEN
    l_update_date := systimestamp || '';
    select value into l_timestamp_format from nls_database_parameters where parameter = 'NLS_TIMESTAMP_TZ_FORMAT';
    :new.update_ts := to_timestamp_tz(l_update_date, l_timestamp_format);
END IF;to be sure the format is right. It didn't change a thing.
We are using Oracle Version 10.2.0.4.0 Production.
Did anyone encounter that kind of behaviour and solve it? I'm now pretty certain that it has to
be an oracle bug. What is the forum's opinion on that? Would you suggest to file a bug report?
Thanks in advance for your help.
Kind regards
Jan

Could you please edit your post and use formatting and tags. This is pretty much unreadable and the forum boogered up some of your code.
Instructions are here: http://forums.oracle.com/forums/help.jspa

Similar Messages

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.

'Value too large for column' error in msql

In my 9ilite database I have a table with a LONG column
In the documentation it says that a LONG column can hold upto 2 GB data
However when I try an insert more than 4097 characters into the column I get the error message on insert 'Value too large for column'
Is this a bug or is the documentation wrong
or am I doing something wrong ?
Any help would be much appreciated

You have run into some bug in handling intermediate results in Oracle 9i Lite. You can by pass the bug as follows in Java.
public static oracle.lite.poljdbc.BLOB createBlob(Connection conn,
byte[] data)
throws SQLException, IOException
oracle.lite.poljdbc.BLOB blob = new oracle.lite.poljdbc.BLOB(
(oracle.lite.poljdbc.OracleConnection)conn);
OutputStream writer = blob.getBinaryOutputStream();
writer.write(data);
writer.flush();
writer.close();
return blob;
public static void insertRow(Connection conn, int num,
oracle.lite.poljdbc.BLOB blob)
throws SQLException
PreparedStatement ps = conn.prepareStatement(
"insert into TEST_BLOB values (?, ?)");
ps.setInt(1, num);
ps.setBlob(2, blob);
ps.execute();

Inserted value too large for column Error

I have this table:
CREATE TABLE SMt_Session
     SessionID int NOT NULL ,
     SessionUID char (36) NOT NULL ,
     UserID int NOT NULL ,
     IPAddress varchar2 (15) NOT NULL ,
     Created timestamp NOT NULL ,
     Accessed timestamp NOT NULL ,
     SessionInfo nclob NULL
and this insert from a sp (sp name is SMsp_SessionCreate):
     Now := (SYSDATE);
     SessionUID := SYS_GUID();
     /*create the session in the session table*/
     INSERT INTO SMt_Session
               ( SessionUID ,
               UserID ,
               IPAddress ,
               Created ,
               Accessed )
     VALUES           ( SMsp_SessionCreate.SessionUID ,
               SMsp_SessionCreate.UserID ,
               SMsp_SessionCreate.IPAddress ,
               SMsp_SessionCreate.Now ,
               SMsp_SessionCreate.Now );
It looks like the param SessionUID is the one with trouble, but the length of sys_guid() is 32, and my column has 36.
IPAddress is passed to the sp with value '192.168.11.11', so it should fit.
UserID is 1.
I am confused, what is the column with problem ?

CREATE OR REPLACE PROCEDURE SMsp_SessionCreate
     PartitionID IN      INT ,
     UserID IN      INT ,
     IPAddress IN      VARCHAR2 ,
     SessionID IN OUT      INT,
     SessionUID IN OUT      CHAR,
     UserName IN OUT      VARCHAR2,
     UserFirst IN OUT      VARCHAR2,
     UserLast IN OUT      VARCHAR2,
     SupplierID IN OUT      INT,
     PartitionName IN OUT      VARCHAR2,
     Expiration IN      INT ,
     RCT1 OUT      GLOBALPKG.RCT1
AS
     Now DATE;
     SCOPE_IDENTITY_VARIABLE INT;
BEGIN
     Now := SYSDATE;
     -- the new Session UID
     SessionUID := SYS_GUID();
     /*Cleanup any old sessions for this user*/
     INSERT INTO SMt_Session_History
               ( UserID ,
               IPAddress ,
               Created ,
               LastAccessed ,
               LoggedOut )
     SELECT
               UserID,
               IPAddress,
               Created,
               Accessed,
               TO_DATE(Accessed + (1/24/60 * SMsp_SessionCreate.Expiration))
     FROM SMt_Session
     WHERE     UserID = SMsp_SessionCreate.UserID;
     --delete old
     DELETE FROM SMt_Session
     WHERE UserID = SMsp_SessionCreate.UserID;
     /*create the session in the session table*/
     INSERT INTO SMt_Session
               ( SessionUID ,
               UserID ,
               IPAddress ,
               Created ,
               Accessed )
     VALUES           ( SMsp_SessionCreate.SessionUID ,
               SMsp_SessionCreate.UserID ,
               SMsp_SessionCreate.IPAddress ,
               SMsp_SessionCreate.Now ,
               SMsp_SessionCreate.Now );
     SELECT SMt_Session_SessionID_SEQ.CURRVAL INTO SMsp_SessionCreate.SessionID FROM dual;
     --SELECT SMt_Session_SessionID_SEQ.CURRVAL INTO SCOPE_IDENTITY_VARIABLE FROM DUAL;
     --get VALUES to return
     SELECT u.AccountName INTO SMsp_SessionCreate.UserName FROM SMt_Users u WHERE u.UserID = SMsp_SessionCreate.UserID;
     SELECT u.SupplierID INTO SMsp_SessionCreate.SupplierID FROM SMt_Users u WHERE u.UserID = SMsp_SessionCreate.UserID;
     SELECT u.FirstName INTO SMsp_SessionCreate.UserFirst FROM SMt_Users u WHERE u.UserID = SMsp_SessionCreate.UserID;
     SELECT u.LastName INTO SMsp_SessionCreate.UserLast FROM SMt_Users u WHERE u.UserID = SMsp_SessionCreate.UserID;
     BEGIN
          FOR REC IN ( SELECT
               u.AccountName,
               u.SupplierID,
               u.FirstName,
               u.LastName FROM SMt_Users u
     WHERE     UserID = SMsp_SessionCreate.UserID
          LOOP
               SMsp_SessionCreate.UserName := REC.AccountName;
               SMsp_SessionCreate.SupplierID := REC.SupplierID;
               SMsp_SessionCreate.UserFirst := REC.FirstName;
               SMsp_SessionCreate.UserLast := REC.LastName;
          END LOOP;
     END;
     BEGIN
          FOR REC IN ( SELECT PartitionName FROM SMt_Partitions
     WHERE     PartitionID = SMsp_SessionCreate.PartitionID
          LOOP
               SMsp_SessionCreate.PartitionName := REC.PartitionName;
          END LOOP;
     END;
     /*retrieve all user roles*/
     OPEN RCT1 FOR
     SELECT RoleID     FROM SMt_UserRoles
     WHERE     UserID = SMsp_SessionCreate.UserID;
END;
this is the exact code of the sp. The table definition is this:
CREATE TABLE SMt_Session
SessionID int NOT NULL ,
SessionUID char (36) NOT NULL ,
UserID int NOT NULL ,
IPAddress varchar2 (15) NOT NULL ,
Created timestamp NOT NULL ,
Accessed timestamp NOT NULL ,
SessionInfo nclob NULL
The sp gets executed with this params:
PARTITIONID := -2;
USERID := 1;
IPADDRESS := '192.168.11.11';
SESSIONID := -1;
SESSIONUID := NULL;
USERNAME := '';
USERFIRST := '';
USERLAST := '';
SUPPLIERID := -1;
PARTITIONNAME := '';
EXPIRATION := 300;
if I ran the code inside the procedure in sql+ (not the procedure), it works. when i call the sp i get the error
inserted value too large for column
at line 48

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

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

Exporting Page fails with ORA-1401 inserted value too large for column

Hi Everyone,
I have a client what is getting the following error when
attempting to export a page using pageexp.cmd. A simple page
works for them but there main page does not. Here is the error:
Extracting Portal Page Data for Export...
begin
ERROR at line 1:
ORA-01401: inserted value too large for column
ORA-06512: at "PORTAL30.WWUTL_POB_EXPORT", line 660
ORA-06512: at "PORTAL30.WWUTL_POB_EXPORT", line 889
ORA-06512: at line 5
Has anyone seen this before?
Is there any way we can narrow down why this occurs?
There is no logging on this export option and the stored
procedures used are wrapped.
Any ideas?
Thanks
Oracle Portal Version: 3.0.9.8.0

we had this problem.
We talked to some oracle person who said some portlets on a page had trouble exporting.
Sure enough after we deleted all the portlets (one at a time to determine which one was giving us the problem. Turned out none of ours worked) the page exported and imported just fine.
Hopefully this is being worked on...

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

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)

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

Inserted value too large for column

Hi,
I have a table (desc below), with only one trigger wich fill the operatcreat, operatmodif, datecreat and datemodif column at insert and update for each row. When I try to insert, I got the following messages :
INSERT INTO tarifclient_element(tarifclient_code,article_code,prix) VALUES('12','087108',3.94);
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-01401: inserted value too large for column
SQL> desc tarifclient_element
Name Null? Type
TARIFCLIENT_CODE NOT NULL CHAR(10)
ARTICLE_CODE NOT NULL CHAR(20)
PRIX NUMBER
OPERATCREAT NOT NULL VARCHAR2(30)
OPERATMODIF VARCHAR2(30)
DATECREAT NOT NULL DATE
DATEMODIF DATE
NB : tarifclient_code is an ENABLED fk, article_code is a DISABLED fk. All values exists in both referenced tables.
Any idea ?

My trigger is not the problem, I tried to delete it and fill the columns manually and got the same error.
<BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>Originally posted by allanplumb ():
The SQL you have shown us looks OK
(to me, au moins). However, perhaps the
error is in the trigger which fills in
the two operativ fields. It would execute
at the same time as your insert, near
enough.
-- Allan Plumb<HR></BLOCKQUOTE>
null

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.

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 !

Rs.updateBoolean SQLException: ORA-12899: value too large for column

Complete error is SQLException: ORA-12899: value too large for column "SMSUSER"."PRUEBA"."VLOGIC" (actual: 4, maximum: 1)
Let's see the code:
PreparedStatement ps=null;
ResultSet rs=null;
try
ps=conn.prepareStatement("create table prueba(name varchar2(32),vlogic char(1) not null check(vlogic in (0,1)))");
ps.execute();
logger.info("Table created.");
ps=conn.prepareStatement("insert into prueba (name,vlogic) values ('user01',?)");
ps.setBoolean(1,true);
ps.executeUpdate();
logger.info("Data Inserted.");
ps=conn.prepareStatement("update prueba set vlogic=? where name=?");
ps.setBoolean(1,false);
ps.setString(2,"user01");
ps.executeUpdate();
logger.info("Data Updated.");
; Till here all runs ok, but if we try to modify vía Resulset.....
ps=conn.prepareStatement("select vlogic from prueba where name=? for update", ResultSet.TYPE_SCROLL_SENSITIVE, ResultSet.CONCUR_UPDATABLE, ResultSet.CLOSE_CURSORS_AT_COMMIT);
ps.setString(1,"user01");
rs=ps.executeQuery();
if (rs.next())
logger.info("Got record.");
rs.updateBoolean("vlogic",true);
rs.updateRow();
logger.info("Column updated.");
catch (SQLException E)
logger.info("SQLException: "+E.getMessage());
finally
closeResultSet(rs);
closePreparedStatement(ps);
The trouble is that when updating via resultset, what is going to be inserted is "true" or "false" and not "0" or "1" as with insertions and modifications via preparedStatements.
So systems returns error: SQLException: ORA-12899: value too large for column "SMSUSER"."PRUEBA"."VLOGIC" (actual: 4, maximum: 1)
Cause it is tryng to insert "true".
Can somebody tell me what's happenign here?
Thanks in advance.
Francisco Javier Ascanio Suárez.
E-mail: [email protected]

Ok, but why is this behaviour different in ResultSet statements than in Prepared Statements?
As you can see in my example, prepared statements with set boolean runs ok.
I like your "proper way", and it resolves my trouble, but it don't tells me why do I have to program a field update in different ways depending of Prepared Statements or updating resultsets.
Thanks in advance.

ORA-01401: inserted value too large for column

I am updating a couple dozen columns with this program. Is there a way to include the column name that caused the error in this message?
Thanks
H

10g includes the columnname when throwing an error:
michaels> create table t (a varchar2(2))
Table created.
michaels> insert into t values ('xyz')
insert into t values ('xyz')
Error at line 6
ORA-12899: value too large for column "T"."A" (actual: 3, maximum: 2)May we conclude you are not on 10g and up?

Update trigger fails with value too large for column error on timestamp

Similar Messages

Maybe you are looking for