Progress r-code is generated by the Compiler when it compiles a procedure or an application. To redeploy or port the r-code, it may or may not need to be recompiled. The following rules apply to determine when the code must be recompiled:
1. Display Type Changes
If the procedure does not include any UI code, it will not be bound to a specific display type. In this case the r-code is compatible between GUI and ChUI clients.
- When an application needs to be ported from a Graphical User Interface ( GUI ) display environment to a Character User Interface ( CHUI or TTY ) or vice versa. there is a Display Type Change.
- Code that includes UI interaction (frame definitions, message statements etc.) must be recompiled.
Example:
To deploy a Windows GUI application on a TTY or CHUI client, the code needs to be recompiled because of the change in the application's display architecture. Failing to do so will result in the error:
Program <program-name> was compiled under another incompatible display environment. Cannot run without recompile. (4438)
2. Database Type
Code that does not perform database access will not be bound to a database type. In this case the r-code is compatible between database types.
OpenEdge, ORACLE, ODBC-compliant, and DB2/400:
- Code that includes database interaction (= any FIND, FOR EACH or QUERY on database buffers) will be bound to a specific database type (OpenEdge, or the foreign database in case of DataServer).
Example:
Porting an application that is compiled against an ORACLE DataServer on a Linux machine to a character application accessing an ORACLE DataServer on a Hewlett-Packard (HP) machine, you do not have to recompile if the ORACLE release level does not change. However, porting the same application to connect to an OpenEdge database, or a DataServer for MSSQL running on Windows, the Database Type changes and therefore a recompile is required.
3. R-code Version Change
It is always recommended to compile the code on the same release it's intended to run. This helps confirm the code does not try to use features not available in the release, and will ensure fixes for bugs in the r-code generation take effect.
- Between Major OpenEdge releases, a recompile is always be required as the r-code version always changes between major versions.
- Between Minor OpenEdge releases, forward-compatibility is guaranteed for r-code, but not backwards-compatibility. Code compiled in a lower minor release will run in a higher minor release; the other way around is not guaranteed.
- Between Minor versions or update releases, the r-code version number may remain the same, but using new ABL features added in a later minor release or update will break compatibility with earlier versions."
Examples:
- Migrating from Progress 9.x to OpenEdge 10.x, or from OpenEdge 10.x to 11.x will require a recompile as those are changes between Major releases.
- Code compiled under OpenEdge 10.2A will run in OpenEdge 10.2B, but may be missing optimizations.
- Code compiled under OpenEdge 10.2B may run under OpenEdge 10.2A or not depending on features used; If the 10.2B code makes use of any new features (ie. the JSON-related features, STOP-AFTER blocks etc.), this code will fail when run in 10.2A.
- Code compiled under OpenEdge 12.0 will not run under any earlier release because of the implicit r-code version change in the higher (major) release.
- Code compiled under OpenEdge 12.8.9 for a specific defect fix may require recompilation for deployment to an OpenEdge 12.8.8 environment.
See also:
https://docs.progress.com/bundle/openedge-abl-manage-applications/page/R-code-version-compatibility.html
Porting across r-code versions sometimes requires recompiling. The r-code version always changes between major releases. It might or might not change between minor point releases depending on the added functionality.
If you port to:
A lower or higher major release, you must recompile.
A higher point release within a major release, you might or might not need to recompile, depending on the new functionality in the point release.
A lower point release within a major release, you might or might not need to recompile. However, it is highly recommended that you recompile.
4. Platform Architecture Change (32-bit vs. 64-bit OpenEdge)
The OpenEdge 10.1x and 10.2X release series use different r-code formats for the different bit-levels, and recompiling is needed when the bit-level of the deployment changes.
This applies only to the OpenEdge 10.1x and 10.2x release series. Releases prior to 10.1A and starting with 11.0 use a unified r-code format which is portable between 32-bit and 64-bit OpenEdge releases.
Examples:
- When migrating an OpenEdge 10.1C application from a Windows 32-bit platform to an HP-UX 11 64-BIT platform,
- When migrating from OpenEdge 10.2B 32-bit to OpenEdge 10.2B 64-bit on the same 64-bit Operating System
For further details Refer to Article OpenEdge 10.x and 11.x R-CODE bit compatibility rules
5. Database Schema Changes:
It is always recommended to compile application code using the same database schema it's intended to run against. This helps verify compatibility between code and schema, and allows newly added indexes to be used in statically defined database references.
Changing the definitions of the Database Application Schema may require code to be recompiled, depending on the changes made:
- Changing column order does not require recompiling as long as the r-code position remains unchanged.
- Adding indexes to a table does not require recompiling.
- Adding, renaming or removing fields in the table will require a recompile in most cases.
For further details on how data Schema Definitions affect .r portability, refer to Article Cyclic Redundancy Check Explained
6. R-code is not platform dependent
Compiled r-code files are portable between different Operating Systems, within the rules and restrictions outlined above,.
Example:
R-code generated on a OpenEdge 10.2B 64-bit 4GL Development System license running on HP-UX 64-bit will run on an OpenEdge 10.2B AppServer license 64-bit for Windows 64-bit.
If this is not the case, this should be considered a Defect, and should be reported to Progress Software Customer Support.
7. References to Progress embedded classes and OpenEdge classes
To support OOABL, Progress introduced:
- a number of classes embedded into the language,
- as well as classes on top of the language in order to perform various functionality for application developers and those used by tools in the Progress development environment, like the Data Administration.
It is sometimes necessary to change these classes for bug fixes and enhancements and when a significant change is made to one of these classes from one version to the next, incompatibility can occur which will result in the following error:
Could not access element '<element>' of class '<class>' using object of type '<type>' - caller compilation is out of sync with class compilation. (12882)
More information regarding this error is provided in the following Article: What does the message compilation is out of date mean ?
When error 12882 occurs while running code compiled on a different version than the environment in which it's running, the ABL code which references objects in any of the below namespaces must be recompiled in the current version. These classes generally begin with the following namespaces:
- Progress.<category>.<>
- Progress.ApplicationServer
- Progress.BPM
- Progress.Data
- Progress.IO
- Progress.Json
- Progress.Lang.
- Progress.Reflect
- Progress.Security
- Progress.Util
- Progress.Web
- Progress.Windows
- OpenEdge.<category>.<>
- OpenEdge.ABLUnit
- OpenEdge.BusinessLogic
- OpenEdge.Core
- OpenEdge.DataAdmin
- OpenEdge.Logging
- OpenEdge.Mobile
- OpenEdge.Net
- OpenEdge.Security
- OpenEdge.Web
