Even though the INT64 data type is available, Progress Software Corporation does not recommend that you completely change all INTEGER expressions to INT64 expressions in your existing applications, nor that you use INT64 exclusively in new applications. External interfaces, such as .NET, ODBC, JAVA, and OCX, will not work smoothly or efficiently if you do. There is no performance penalty for using INT64 in ABL (as all values are stored internally as INT64 and all operations are performed as INT64), but do not ignore your application's interactions with external interfaces.

Instead of a global change, you should plan carefully and specify as INT64 only those fields, program variables, and so forth, that actually have a chance of needing a value outside the -2147483648 to +2147483647 range of INTEGER data.

In deciding whether a field will need more than 2^31-1, consider not only how large the field needs to be at the present time, but also consider how large the field will need to be over the life span of the application. As an example, consider the CustNum field in the sample Sports database. After being in business a long time, the customer numbers of old (now non-existent) customers usually cannot be re-used, so they occupy CustNum values even though the total of current customers is far less.