Re: ORA-01457

> 1. how datatype of the column is defined in Oracle table (NUMBER? NUMBER
> (11,2)?)

It is NUMBER(9,2)

> 2. what is the actual maximum data value of that column? are you
> outputting trace messages to show which row of the table is causing the
> error?

The actual maximum would fit in the variable. The program fails on the first FETCH.

---
Oracle replied to the TAR and referenced Note: 1011873.6  Here are
some snippets:

Creation Date: 	16-AUG-1995

Possible workaround: use COMP-1 or COMP-2 instead.  
  
Solution Explanation:  
=====================  
  
The problem was that PL/SQL was ignoring the scale and precision
values.
This was corrected in rdbms version 7.1.5 

-------------------------------------------------------------------------
My take on it:
It's really interesting:

1) It says "This was corrected in rdbms version 7.1.5", yet we
encounter this error using Pro*COBOL 8.1.7 reading from Oracle 7.3. 
It seems this bug is not fixed.

2) It says: "In Pro*COBOL, using host variables of type COMP-2 or
COMP-3 in embedded PL/SQL produces the error...", yet it says:
"Possible workaround: use COMP-1 or COMP-2 instead.".

It doesn't make sense that if COMP-2 causes the problem, to use COMP-2
as a workaround!

3) COMP-1 is too small to hold my number.  I need a variable with 11
digits of precision to the penny (no rounding off).  COMP-1 is not
designed to hold money -- it is for scientific notation, (scientific
data, not business dollars and cents).  It will cause serious roundoff
problems, which will prevent the program from balancing.  COMP-1 has
only 8 significant digits.

4) It's dated 1995.  It is fully 7 years old.

5) Maybe this is a new bug.  However, in Google, it seems that someone
reported the same problem on Aug 22, 2001.