ORA-12899 - is it possible to truncate automatically

I know why I am getting ORA-12899. Instead of rolling back the transaction, I am wondering if it is possible to let Oracle truncate data automatically so that update/insert succeeds. There are cases that auto-truncation is acceptable.
I am using Oracle 10 with Hibernate.
Thanks in advance.

Well,
>
ORA-12899:
value too large for column string (actual: string, maximum: string)
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).>
Now can you just tell what do you mean by "auto truncate" and how it does relate to this error? Also mention your db versio and o/s/.
HTH
Aman....

Similar Messages

ORA-12899 : Does it exist an option to truncate automaticly the data too...

Hi,
I work on a migration project : Sybase to Oracle 10g.
There are a lot of request INSERT writed in Sybase with data too long to be insert in a table.
Example :
create table MyTable (txt varchar(10))
insert into MyTable values ('AAAAAAAAAAAAAAAAA');
So, i have lot of error ORA-12899 ...
With Sybase, there isn't error because the data are automaticly truncated.
Does it exist an option with Oracle to have the same behavior ? Without option, i have to add substr in many request.
Any idea ?

Here is another possibility you may want to consider,
1. make the column generously large, enough that you can be sure it accommodates the longest string.
2. load the data
3. once the data is loaded write a simple query that tells you the length of the longest string that got loaded in the column
4. alter the column to be of a more reasonable size considering step 3.
This way, no need to substr everywhere and truncate values that should not have been truncated in the first place. If you do need to end up truncating the values, it will still be easier to do it once the data is loaded in a table than it is to cherrypick statements to modify in script.
HTH,
John.

File_To_RT data truncation ODI error ORA-12899: value too large for colum

Hi,
Could you please provide me some idea so that I can truncate the source data grater than max length before inserting into target table.
Prtoblem details:-
For my scenario read data from source .txt file and insert the data into target table.suppose source file data length exceeds max col length of the target table.Then How will I truncate the data so that data migration will be successful and also can avoid the ODI error " ORA-12899: value too large for column".
Thanks
Anindya

Bhabani wrote:
In which step you are getting this error ? If its loading step then try increasing the length for that column from datastore and use substr in the mapping expression.Hi Bhabani,
You are right.It is for Loading SrcSet0 Load data.I have increased the column length for target table data store
and then apply the substring function but it results the same.
If you wanted to say to increase the length for source file data store then please tell me which length ?Physical length or
logical length?
Thanks
Anindya

ORA-12899 error from function invoked from SQL*Loader

I am getting the above error when I call a function from my SQL*Loader script, and I am not seeing what the problem is. As far as I can see, there should be no problem with the field lengths, unless the length of the automatic variable within my function is somehow being set at 30? Here are the details (in the SQL*Loader script, the field of interest is the last one):
====
Error:
====
Record 1: Rejected - Error on table TESTM8.LET_DRIVE_IN_FCLTY, column DIF_CSA_ID.
ORA-12899: value too large for column "TESTM8"."LET_DRIVE_IN_FCLTY"."DIF_CSA_ID" (actual: 30, maximum: 16)
=======
Function:
=======
CREATE OR REPLACE FUNCTION find_MCO_id (di_oid_in DECIMAL)
RETURN CHAR IS mco_id CHAR;
BEGIN
SELECT AOL_MCO_LOC_CD INTO mco_id
FROM CONV_DI_FLCTY
WHERE DIF_INST_ELMNT_OID = di_oid_in;
RETURN TRIM(mco_id);
END;
==============
SQL*Loader Script:
==============
LOAD DATA
INFILE 'LET_DRIVE_IN_FCLTY.TXT'
BADFILE 'LOGS\LET_DRIVE_IN_FCLTY_BADDATA.TXT'
DISCARDFILE 'LOGS\LET_DRIVE_IN_FCLTY_DISCARDDATA.TXT'
REPLACE
INTO TABLE TESTM8.LET_DRIVE_IN_FCLTY
FIELDS TERMINATED BY '~' OPTIONALLY ENCLOSED BY '"'
DIF_DRIVE_IN_OID DECIMAL EXTERNAL,
DIF_FCLTY_TYPE_OID DECIMAL EXTERNAL NULLIF DIF_FCLTY_TYPE_OID = 'NULL',
DIF_INST_ELMNT_OID DECIMAL EXTERNAL,
DIF_PRI_PERSON_OID DECIMAL EXTERNAL NULLIF DIF_PRI_PERSON_OID = 'NULL',
DIF_SEC_PERSON_OID DECIMAL EXTERNAL NULLIF DIF_SEC_PERSON_OID = 'NULL',
DIF_CREATE_TS TIMESTAMP "yyyy-mm-dd-hh24.mi.ss.ff6",
DIF_LAST_UPDATE_TS TIMESTAMP "yyyy-mm-dd-hh24.mi.ss.ff6",
DIF_ADP_ID CHAR NULLIF DIF_ADP_ID = 'NULL',
DIF_CAT_CLAIMS_IND CHAR,
DIF_CAT_DIF_IND CHAR,
DIF_DAYLT_SAVE_IND CHAR,
DIF_OPEN_PT_TM_IND CHAR,
DIF_CSA_ID CONSTANT "find_MCO_id(:DIF_DRIVE_IN_OID)"
============
Table Definitions:
============
SQL> describe CONV_DI_FLCTY;
Name Null? Type
DIF_INST_ELMNT_OID NOT NULL NUMBER(18)
AOL_MCO_LOC_CD NOT NULL VARCHAR2(3)
SQL> describe LET_DRIVE_IN_FCLTY;
Name Null? Type
DIF_DRIVE_IN_OID NOT NULL NUMBER(18)
DIF_INST_ELMNT_OID NOT NULL NUMBER(18)
DIF_FCLTY_TYPE_OID NUMBER(18)
DIF_ADP_ID VARCHAR2(10)
DIF_CAT_DIF_IND NOT NULL VARCHAR2(1)
DIF_CAT_CLAIMS_IND NOT NULL VARCHAR2(1)
DIF_CSA_ID VARCHAR2(16)
DIF_DAYLT_SAVE_IND NOT NULL VARCHAR2(1)
DIF_ORG_ENTY_ID VARCHAR2(16)
DIF_OPEN_PT_TM_IND NOT NULL VARCHAR2(1)
DIF_CREATE_TS NOT NULL DATE
DIF_LAST_UPDATE_TS NOT NULL DATE
DIF_ITM_FCL_MKT_ID NUMBER(18)
DIF_PRI_PERSON_OID NUMBER(18)
DIF_SEC_PERSON_OID NUMBER(18)
=========================
Thanks for any help with this one!

I changed one line of the function to:
RETURN CHAR IS mco_id VARCHAR2(16);
But I still get the same error:
ORA-12899: value too large for column "TESTM8"."LET_DRIVE_IN_FCLTY"."DIF_CSA_ID" (actual: 30, maximum: 16)
I just am not seeing what is being defined as 30 characters. Any ideas much appreciated!

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.

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

Imp/exp ORA-12899: value too large for column

imp/exp ORA-12899: value too large for column
source :
os: linux as 4 update4
.bash_profile NLS_LANG=AMERICAN_AMERICA.US7ASCII
for run exp bill/admin001 file=bill0518.dmp bill rows=y
oracle: 10.2.1
NLS_LANGUAGE AMERICAN
NLS_TERRITORY AMERICA
NLS_CHARACTERSET US7ASCII
target :
os: linux as 4 update4
.bash_profile NLS_LANG=AMERICAN_AMERICA.AL32UTF8
for run
imp bill/admin001 file=bill0518.dmp
oracle: 10.2.1
NLS_LANGUAGE AMERICAN
NLS_TERRITORY AMERICA
NLS_CHARACTERSET AL32UTF8
imp log
Import: Release 10.2.0.1.0 - Production on Wed May 16 14:57:59 2007
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Produc tion
With the Partitioning, Real Application Clusters, OLAP and Data Mining options
Export file created by EXPORT:V10.02.01 via conventional path
import done in US7ASCII character set and AL16UTF16 NCHAR character set
import server uses AL32UTF8 character set (possible charset conversion)
export client uses AL32UTF8 character set (possible charset conversion)
. importing BILL's objects into BILL
. . importing table "MY_SESSION" 44 rows imported
. . importing table "T1"
IMP-00019: row rejected due to ORACLE error 12899
IMP-00003: ORACLE error 12899 encountered
ORA-12899: value too large for column "BILL"."T1"."NAME" (actual: 62, maximum: 5 0)
Column 1 1
Column 2 ÖÐ¹úÈË. 0 rows impo rted
Import terminated successfully with warnings.

Yes it's probably due to different char sets
A way around it it to change the DB setup on the new database to use CHAR as default for varchar2 rows, and then use datapump to do your import/export, because datapump uses the default varchar2 type when creating tables that includes varchar2 (which is normally byte). Exp/imp uses the varchar2 type that is in the original database
Best regards
/Klaus

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.

ORA-12899 mapping error

Hello!
I have only just started to work with OWB and I'm trying to build the staging area for our data warehouse. I've done mappings for all the necessary tables and each time I try to run the mapping I encounter the following error.
Warning
ORA-12899: liian suuri arvo sarakkeelle (nykyinen arvo: , enimmäisarvo: )
Warning
ORA-06502: PL/SQL: numeerinen virhe tai arvovirhe : Bulk Bind: Truncated Bind
Warning
CursorFetchMapTerminationRTV20007
Don't mind the finnish language, the error codes should speak for themselves. Note however that the warning doesn't even mention which field is in question. On some tables it DOES give me the field name in the error message and says that the "current length" is for example 33 and the max length is 30. The field length is copied exactly from the source table in the mapping. I've checked and double checked it. This problem can be circumvented by enlarging the target table field length and then the mapping runs fine. But when I afterwards look for any values that have a length of 33, I can't find them. All values where under 30 as they should be.
Then on some tables I get the error I've pasted to the top. It doesn't even mention the field in question so I'm having a hard time fixing this. In any case I don't want to have to enlarge the targe table field lengths just to get the data in.
Is this a bug or have I done something wrong perhaps? Any help would be most appreciated.
Versions:
OWB Client: 10.2.0.2.8
Repository: 10.2.0.2.0 (problem? DBA said there was a problem patching this)
Source DB: Oracle 9i
Target DB: Oracle 10g
Regards,
Erik

Hey!
No I am not using a view or a procedure in the mapping, if I understood you correctly. It's an extremely simple mapping where I move the source data straight from the operative system to the target table. I believe this happens via database links. Or at least I think so judging by the PL/SQL generated by the OWB.
The error is limited to VARCHAR2-fields. I'm guessing it might have something to do with scandic letters and/or umlauts and such.
Thanks anyways for your answer.

Insert error ORA-12899, How to avoid it?

When I insert a new row in my table, and if the value for the column foo char(20) has 22 characters, then i get the following error ORA-12899.
Is there a way to configure oracle to autmatically truncate the value to 20 characters, so it fits in the column ?.
Whe are migrating from Informix Dynamic Server to[b] Oracle 10g XE, and Informix has this feature, so in my application i did´nt have to worry about this kind of problem.

Í'm missing something, because it does´nt work for me, also I read the link you sended to me, here is the steps I´m following to configure this parameter:
1.- Connect with sys user as sysdba
2.- Run the sentence ALTER SYSTEM SET NLS_DATE_FORMAT = 'DD/MM/YYYY' SCOPE = SPFILE
2.- Shutdown and restart the Oracle server
3.- Connect as userxx
4.- Execute the following query select date1 from inventory and it displays :
date1
12-DEC-06
31-DEC-06
5.- Execute the following query[b] select date1 from inventory where date1 > '31/12/2006' and it throws an exception ORA-01843: not a valid month
4.- Connect with sys user as sysdba
5.- Execute the sentence SHOW PARAMETERS, and the nls_date_format has the value 'DD/MM/YYYY'
Is this the correct way to configure this parameter ?
What I´m doing wrong ?
My Oracle 10g XE server is running on CentOS 4.4.

FRM-41735 + ORA-12899

Thrz an application running in forms 6i in our office.....its been workin fine since 2-3 year ..but today ...when i used the form... i.e entered the particular number to select my data
i get this error
FRM-41734 KEYNXT attempt trigger raised unhandled exception ORA-12899
How to over come this error!!!???

Sounds like you have a field in your form that is set smaller than the data precision of the column in the table. The ORA-12899 is a "value too large for column string" error. Is it possible that someone altered the table to increase the size of a column?
Craig...

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

Hi! I need to load a GET url that si very long. On other browsers, I can load the url. In firefox 3.6, no. There is an addons or a plugin so I can extend this limit? If yes, is possible to load automatically this addons when loading a certain page? thanks

Hi!
I need to load a GET url that si very long. On other browsers, I can load the url. In firefox 3.6, no.
There is an addons or a plugin so I can extend this limit? If yes, is possible to load automatically this addons when loading a certain page? thanks
The url is sometingh like this (this is correctly loaded, but it could be longer)

Firefox should have problems with long GET data appended to an URL (long would be over 64k).<br />
If there are problems then it is possible that an extension is the cause of that.
Start Firefox in [[Safe Mode]] to check if one of your add-ons is causing your problem (switch to the DEFAULT theme: Tools > Add-ons > Themes).
See [[Troubleshooting extensions and themes]] and [[Troubleshooting plugins]]

Warning - 1241024 - Possible string truncation in column #

I am running the following command in a simple MaxL script, the output of which is sent to a text file:
display variable App.DB.SubVar;
The text file appears to have generated fine, with the substitution variable value displayed. However, the following warnings are returned each time from the stderr output. Should I be concerned? Is there any way to rectify this?
WARNING - 1241024 - Possible string truncation in column 3.
WARNING - 1241028 - Output column defined with warnings.
WARNING - 1241024 - Possible string truncation in column 4.
WARNING - 1241028 - Output column defined with warnings.

Hi John,
Many thanks for your response. The problem is a little confusing, as I cannot see how anything is being truncated here - indeed there are characters to spare! Could it be because the potential size of the substitution variable name is 320 bytes and the potential size of the substitution variable value is 256 bytes (11.1.2.1)? Could this be the cause of the warnings here?
Adding "set column_width 10;" does not appear to remove the warnings either unfortunately. Do you please have any other thoughts on how I might remove the warnings? It might allay the fears of the client later on!
James

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)

ORA-12899 - is it possible to truncate automatically

Similar Messages

Maybe you are looking for