We get sometimes the following error from our partner’s database:
<i>ORA-01438: value larger than specified precision allows for this column</i>
The full response looks like the following:
<?xml version="1.0" encoding="windows-1251"?>
<response>
<status_code></status_code>
<error_text>ORA-01438: value larger than specified precision allows for this column ORA-06512: at "UMAIN.PAY_NET_V1_PKG", line 176 ORA-06512: at line 1</error_text>
<pay_id>5592988</pay_id>
<time_stamp></time_stamp>
</response>
What can be the cause for this error?
Kiquenet
14.5k35 gold badges148 silver badges243 bronze badges
asked Oct 8, 2008 at 4:30
1
The number you are trying to store is too big for the field. Look at the SCALE and PRECISION. The difference between the two is the number of digits ahead of the decimal place that you can store.
select cast (10 as number(1,2)) from dual
*
ERROR at line 1:
ORA-01438: value larger than specified precision allowed for this column
select cast (15.33 as number(3,2)) from dual
*
ERROR at line 1:
ORA-01438: value larger than specified precision allowed for this column
Anything at the lower end gets truncated (silently)
select cast (5.33333333 as number(3,2)) from dual;
CAST(5.33333333ASNUMBER(3,2))
-----------------------------
5.33
answered Apr 29, 2010 at 23:44
Gary MyersGary Myers
35k3 gold badges49 silver badges74 bronze badges
1
The error seems not to be one of a character field, but more of a numeric one. (If it were a string problem like WW mentioned, you’d get a ‘value too big’ or something similar.) Probably you are using more digits than are allowed, e.g. 1,000000001 in a column defined as number (10,2).
Look at the source code as WW mentioned to figure out what column may be causing the problem. Then check the data if possible that is being used there.
answered Oct 8, 2008 at 4:56
ThorstenThorsten
12.9k17 gold badges60 silver badges79 bronze badges
Further to previous answers, you should note that a column defined as VARCHARS(10) will store 10 bytes, not 10 characters unless you define it as VARCHAR2(10 CHAR)
[The OP’s question seems to be number related… this is just in case anyone else has a similar issue]
answered Oct 8, 2008 at 6:49
cagcowboycagcowboy
30k11 gold badges70 silver badges93 bronze badges
1
This indicates you are trying to put something too big into a column. For example, you have a VARCHAR2(10) column and you are putting in 11 characters. Same thing with number.
This is happening at line 176 of package UMAIN. You would need to go and have a look at that to see what it is up to. Hopefully you can look it up in your source control (or from user_source). Later versions of Oracle report this error better, telling you which column and what value.
Dave Jarvis
30.5k41 gold badges179 silver badges317 bronze badges
answered Oct 8, 2008 at 4:35
WW.WW.
23.8k13 gold badges95 silver badges121 bronze badges
0
FYI:
Numeric field size violations will give
ORA-01438: value larger than specified precision allowed for this column
VARCHAR2 field length violations will give
ORA-12899: value too large for column…
Oracle makes a distinction between the data types of the column based on the error code and message.
answered Jun 27, 2016 at 15:14
One issue I’ve had, and it was horribly tricky, was that the OCI call to describe a column attributes behaves diffrently depending on Oracle versions. Describing a simple NUMBER column created without any prec or scale returns differenlty on 9i, 1Og and 11g
answered Oct 8, 2008 at 5:12
Robert GouldRobert Gould
68.8k61 gold badges188 silver badges272 bronze badges
From http://ora-01438.ora-code.com/ (the definitive resource outside of Oracle Support):
ORA-01438: value larger than specified precision allowed for this column
Cause: When inserting or updating records, a numeric value was entered that exceeded the precision defined for the column.
Action: Enter a value that complies with the numeric column’s precision, or use the MODIFY option with the ALTER TABLE command to expand the precision.
http://ora-06512.ora-code.com/:
ORA-06512: at stringline string
Cause: Backtrace message as the stack is unwound by unhandled exceptions.
Action: Fix the problem causing the exception or write an exception handler for this condition. Or you may need to contact your application administrator or DBA.
answered Oct 8, 2008 at 14:00
warrenwarren
32.7k21 gold badges86 silver badges124 bronze badges
It might be a good practice to define variables like below:
v_departmentid departments.department_id%TYPE;
NOT like below:
v_departmentid NUMBER(4)
answered Apr 30, 2010 at 2:00
gokhantgokhant
961 silver badge3 bronze badges
It is also possible to get this error code, if you are using PHP and bound integer variables (oci_bind_by_name with SQLT_INT).
If you try to insert NULL via the bound variable, then you get this error or sometimes the value 2 is inserted (which is even more worse).
To solve this issue, you must bind the variable as string (SQLT_CHR) with fixed length instead. Before inserting NULL must be converted into an empty string (equals to NULL in Oracle) and all other integer values must be converted into its string representation.
answered Jan 13, 2022 at 11:13
Following is my code, I dont understand what I’m doing wrong. Any help will be greatly appreciated
CREATE OR REPLACE
PROCEDURE COMP_LATE_FEE(LATE_APT_FINE IN NUMBER, LATE_GRG_FINE IN NUMBER)
AS
DIFF NUMBER;
TYPE MBCUR IS REF CURSOR RETURN MONTHLY_BILL%ROWTYPE;
MONBILL MBCUR;
MBREC MONTHLY_BILL%ROWTYPE;
BEGIN
--DIFF := FLOOR(SYSDATE - (TRUNC(SYSDATE,'MM')));
--DBMS_OUTPUT.PUT_LINE(DIFF);
OPEN MONBILL FOR
-- checking the status of all last month's bills
SELECT * FROM MONTHLY_BILL
WHERE STATUS = 'PENDING' AND SYSDATE > ED_DT;
FETCH MONBILL INTO MBREC;
-- adding the late fee amount for any bills that are past the due date
-- due date = last day of the month
DIFF := FLOOR(ABS(MBREC.ED_DT - (TRUNC(SYSDATE,'MM'))));
UPDATE MONTHLY_BILL
SET LATE_FEE = DIFF * LATE_APT_FINE
WHERE BILL_NUM = MBREC.BILL_NUM;
-- if a garage is rented by the resident then the respective additional fee is included
IF (MBREC.GARAGE_RENT != 0) THEN
UPDATE MONTHLY_BILL
SET LATE_FEE = LATE_FEE + DIFF * LATE_GRG_FINE
WHERE BILL_NUM = MBREC.BILL_NUM;
END IF;
COMMIT;
CLOSE MONBILL;
END;
/
The procedure compiled without any err. But I get the following err when i call the proc
BEGIN
COMP_LATE_FEE(70,20);
END;
/
Error report:
ORA-01438: value larger than specified precision allowed for this column
ORA-06512: at "LALLURI.COMP_LATE_FEE", line 19
ORA-06512: at line 2
01438. 00000 - "value larger than specified precision allowed for this column"
*Cause: When inserting or updating records, a numeric value was entered
that exceeded the precision defined for the column.
*Action: Enter a value that complies with the numeric column's precision,
or use the MODIFY option with the ALTER TABLE command to expand
the precision.
You may also want to
see this article about the ORA-12899 which is returned if a value larger than
column’s width is inserted in the column. Similarly, ORA-01438 is returned if value being inserted is larger than what
is defined for the NUMBER datatype column. Number datatype columns are defined
in precision and scale (NUMBER(p,s)). If you define a number column as “NUMBER(5,2)”,
it would mean that maximum width of the data could be 5 digits, out of which 2
will be decimal part (for example 123.45). Following are some examples that
explain this concept further.
— In the following example,
the inserted value should only have 2 digits, and both digits should be in
the decimal part of the number
SQL>
create table test (sal number(2,2));
Table
created.
SQL>
insert into test values(2.3333);
insert
into test values(2.3333)
*
ERROR
at line 1:
ORA-01438:
value larger than specified precision allowed for this column
SQL>
insert into test values(2.3);
insert
into test values(2.3)
*
ERROR
at line 1:
ORA-01438:
value larger than specified precision allowed for this column
SQL>
insert into test values(2);
insert
into test values(2)
*
ERROR
at line 1:
ORA-01438:
value larger than specified precision allowed for this column
SQL>
insert into test values(.2);
1
row created.
SQL>
— In the following example,
the inserted value should only have 2 digits for precision part only as no
decimal could be inserted in this column, although INSERT statement would
succeed if decimal value is mentioned.
SQL>
create table test (sal number(2));
Table
created.
SQL>
insert into test values(2.1);
1
row created.
SQL>
insert into test values(2.11);
1
row created.
SQL>
insert into test values(2.111);
1
row created.
SQL>
insert into test values(2.1110000);
1
row created.
SQL>
insert into test values(22.1110000);
1
row created.
SQL>
insert into test values(223.1110000);
insert
into test values(223.1110000)
*
ERROR
at line 1:
ORA-01438:
value larger than specified precision allowed for this column
SQL>
select * from test;
SAL
———-
2
2
2
2
22
— In the following example,
maximum 6 digits could be inserted in the column out of which 4 have to be
decimal part. As soon as we try to insert 3 digits in precision part,
ORA-01438 would be returned because 4 places have to be reserved for the decimal
part.
SQL>
create table test (sal number(6,4));
Table
created.
SQL>
insert into test values(25.65743);
1
row created.
SQL>
insert into test values(2534333.65743);
insert
into test values(2534333.65743)
*
ERROR
at line 1:
ORA-01438:
value larger than specified precision allowed for this column
SQL>
insert into test values(253433.65743);
insert
into test values(253433.65743)
*
ERROR
at line 1:
ORA-01438:
value larger than specified precision allowed for this column
SQL>
insert into test values(2534.65743);
insert
into test values(2534.65743)
*
ERROR
at line 1:
ORA-01438:
value larger than specified precision allowed for this column
SQL>
insert into test values(2.65743);
1
row created.
SQL>
insert into test values(22.65743);
1
row created.
SQL>
insert into test values(223.65743);
insert
into test values(223.65743)
*
ERROR
at line 1:
ORA-01438:
value larger than specified precision allowed for this column
SQL>
insert into test values(243.5);
insert
into test values(243.5)
*
ERROR
at line 1:
ORA-01438:
value larger than specified precision allowed for this column
SQL>
select * from test;
SAL
———-
25.6574
2.6574
22.6574
Problem
16:59:00 [43446] ERROR SQLExecute: oexec(1:13) failed, ORA-01438: value larger than specified precision allows for this column.
16:59:00 [43446] ERROR ODBC [01000] ORA-01438: value larger than specified precision allows for this column (DBError=1438)
16:59:00 [43446] ERROR MAD_PkgExecStmt: SQLExecute(mpi_memhead) failed.
16:59:00 [43446] ERROR MAD_PkgDbxPutAcb: tabName ‘mpi_memhead’, row 0, op ‘UPDATE’ failed.
16:59:00 [43446] ERROR MPI_MemDbSegPut: MAD_PkgDbxPutAcb(mpi_memhead) failed.
16:59:00 [43446] ERROR MPI_MemDbPut: MPI_MemDbSegPut(101) failed.
16:59:00 [43446] ERROR USR=rwuser, IXN=MEMPUT, ERR=EODBC, MSG=member 00999:023729180013118, unable to insert/update/delete member data.
16:59:00 [43446] ERROR MPI_IxnExec_ODBC: ixn failed due to ODBC error, disconnecting.
ORA-01438: value larger than specified precision allowed for this column
Resolving The Problem
This error was a result of using the same memrecno in testing an excessive number of updates. The excessive amount of updates to the single member caused the memseqno field to be constantly updated to the point it exceeded the number size of the database field, in this case it was Oracle number(5) making the max number 99999 (sql server would have been 32767).
[{«Product»:{«code»:»SSLVY3″,»label»:»Initiate Master Data Service»},»Business Unit»:{«code»:»BU059″,»label»:»IBM Software w\/o TPS»},»Component»:»Not Applicable»,»Platform»:[{«code»:»PF025″,»label»:»Platform Independent»}],»Version»:»Version Independent»,»Edition»:»»,»Line of Business»:{«code»:»LOB10″,»label»:»Data and AI»}}]
Error Message
Using cov2sde command may generate the following error: SDE Error(-51) Underlying DBMS error Extended error code(1438): ORA-01438: value larger than specified precision allows for this column.
Cause
Attribute values of the coverage in one or more NUMBER fields are too large for the new fields created in the Oracle table.
Cov2sde first creates an Oracle table to receive the data. This new table’s NUMBER fields are defined from the output/display column and decimals fields specified for the coverage’s INFO table.
To illustrate, assume we have a single parcel coverage with an AREA field whose output/display width is 3, and its decimal column is set to 1 decimal place. When this AREA field is added to the new Oracle table it will be defined as NUMBER(3,1). The 3 indicates the maximum number of digits Oracle will store in this number field. The 1 means that one of those three digits is reserved for a position to the right of the decimal point. Thus, if the area value in the coverage is 12.3, it would be a legitimate number, but an area value of 123.4 would not be¹.
¹Koch, G., and K. Loney, «Creating, Dropping, and Altering Tables and Views,» Oracle: The Complete Reference, Electronic Edition (1997):383.
Solution or Workaround
Changing the output/display column width in the INFO table to a width larger than the attribute value before loading the coverage into the Oracle table eliminates the error, and should allow the data to load.
In the previous example, changing the column width from 3 to 4 or higher will correct the problem.
Find offending INFO column(s) and increase output/display width size using ArcCatalog™
or INFO
.
Note: ArcINFO™ Workstation refers to the column as Output width.
ArcInfo™ Desktop refers to the column as Display width.