Kbase P94897: 4GL/ABL: What are the size limits of the Progress INTEGER data type?
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
11/3/2008 |
|
Status: Verified
GOAL:
4GL/ABL: What are the size limits of the Progress and OpenEdge INTEGER data type?
GOAL:
What are the maximum and minimum values of the Progress and OpenEdge INTEGER data type?
GOAL:
What is the upper limit of the Progress and OpenEdge INTEGER data type?
GOAL:
What is the lower limit of the Progress and OpenEdge INTEGER data type?
GOAL:
What are the size limits of the Progress and OpenEdge DECIMAL data type?
GOAL:
How to use the OpenEdge INT64 data type in 4GL/ABL?
FACT(s) (Environment):
All Supported Operating Systems
Progress 8.x
Progress 9.x
OpenEdge 10.x
FIX:
The range of a Progress INTEGER value is from -2,147,483,648 to +2,147,483,647.
The Progress DECIMAL data type may have up to 50 digits in length including up to 10 digits to the right of the decimal point.
Starting on OpenEdge Release 10.1B, the new INT64 data type was introduced. This data type stores values outside the -2147483648 to +2147483647 range of the Progress INTEGER data type and may be used with database fields, temp-table fields, program variables, parameters, and user defined functions' return values.
In OpenEdge Release 10.1A and earlier, all intermediate calculations are carried out in 32-bit arithmetic.
You can have code that contains an arithmetic calculation where the intermediate result cannot be stored in a 32-bit integer. This code gives an incorrect result even though the final result does not exceed the -2147483648 to +2147483647 range of INTEGER data. For example, 2,000,000,000 * 100 / 100 gives an incorrect result, even though the final result does not exceed 2 billion, because the intermediate result of 200 billion cannot be stored in a 32-bit integer.
Starting with Release 10.1B, all intermediate calculations are carried out in 64-bit arithmetic. For example, 2,000,000,000 * 100 / 100 gives the correct result whether the target field is INTEGER or INT64. And although 2,000,000,000 * 100 does not cause an overflow, the result must be assigned to an INT64 data type otherwise a run-time error will result.
If you have an existing field, program variable, or parameter defined with the INTEGER data type and you want to make it 64-bit capable, you need to change the data type to INT64.
You can change the data type of a database field via the Data Dictionary tool. Note that you can make this change without having to dump and load the data. However, when you change the data type of a database field, you change the Cyclic Redundancy Check (CRC) of the database table that contains the field. Therefore, you must recompile your r-code.
In addition, you should review your code for any references to the database field to determine whether there is a possibility of an overflow with the INTEGER data type.