Feedback
 
Did this article resolve your question/issue?

   

Your feedback is appreciated.

Please tell us how we can make this article more useful. Please provide us a way to contact you, should we need clarification on the feedback provided or if you need further assistance.

Characters Remaining: 1025

 


Article

Do I Need to Recompile .r Code When Porting/Deploying an Application ?

« Go Back

Information

 
Article Number000001558
EnvironmentProduct: OpenEdge
Version: All supported versions
OS: All Supported Platforms
Question/Problem Description
R-code portability rules
When do I need to recompile?
Do I need to recompile my .r code when porting/deploying an application?
Do I need to recompile between platforms?
Is r-code portable across platforms?
Is .r code portable across machines?
Do I need to recompile when I move application from windows to UNIX?
.r code portability
r-code compatibility
Steps to Reproduce
Clarifying Information
Error Message
Defect/Enhancement Number
Cause
Resolution

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

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)".

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.

2.  Database Type

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.

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.

3.  R-code Version Change

A recompile will always be required when moving to a different Major OpenEdge release 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, the r-code version number may remain the same, but using new ABL features added in a later minor release will break compatibility with earlier minor 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.

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.

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.  

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 000011613, OpenEdge 10.x and 11.x R-CODE bit compatibility rules   

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.

5. Database Schema Changes:

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 000001453, Cyclic Redundancy Check Explained   

It is always recommended to compile the code using the same database schema it's intended to run against. This helps verify compatibiltiy between code and schema, and allows newly added indexes to be used in statically defined database references.

6. R-code is NOT platform dependent

Within the rules and restrictions outlined above, the .r files are portable between different Operating Systems.

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

Since OOABL was introduced, Progress introduced a number of classes that are embedded into the language, as well as classes on top of the language that were created in order to perform various functionality for application developers as well as for use by tools like the Data Administration and other tools in the Progress development environment.

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, an 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)

When the above error occurs when 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.

More information regarding this error is provided here
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
Workaround
Notes
Attachment 
Last Modified Date9/10/2019 8:45 PM