R-code, or run-time code, is precompiled code. When you compile a source procedure, ABL places the compiled version of the procedure into a file that has the same name as the source procedure with a .r extension. For a complete discussion of r-code, see R-code Features and Functions.

Like encrypted source, r-code is not readable to the human eye and therefore protects your application from users attempting to make changes.

Developer product requirements and r-code portability

R-code is portable between any two environments if the following are true:

  • The user interface is the same—MS-Windows or character mode.
Note: If a procedure contains no code that writes to the screen, its r-code is portable across user interfaces. For example, this is typical of database schema trigger procedures.
  • The database type (the DataServer or combination of DataServers connected during compilation) is the same.
  • The r-code version is the same.

For more details about these requirements and how they affect r-code portability, see R-code Features and Functions.

User product requirements

Any OpenEdge client, server, or standalone database product can run r-code.

Advantages of r-code

R-code provides the following advantages over other code formats:

  • Speed — This format is faster because the r-code does not have to compile at run time.
  • Application protection — Like encrypted source, r-code protects your application from possible user changes.
  • Good for internationalization — R-code is the only code format that can contain multiple text segments. This means that the same application can contain strings for multiple spoken languages (French and German, for example).
  • Prevents database modifications — CRC-based r-code is more tightly coupled to the database than encrypted or unencrypted source. For each table in the database, ABL calculates a CRC value that represents the structure of the table. A CRC value ensures that the tables in the database match those in the r-code. However, a CRC value is not specific to a particular database.

    You can further restrict access to your application database with the DBRSTRCT utility. This procedure restricts everyone's access to the database, including your own. After you run this procedure, no one can write or compile code that updates the database or changes the database's schema. The only code that can access the database is r-code that you compiled before running the DBRSTRCT utility. This level of database protection is available only with r-code. For more information about the DBRSTRCT utility, see Deployment Topics and Tasks.

Possible drawbacks of r-code

R-code has the following possible drawbacks:

  • Limited portability across user interfaces — The section above on "Developer product requirements and r-code portability" describes the limitations of r-code portability. Depending on the number of incompatible environments requiring a separate compilation, you might have to keep track of multiple r-code trees.
  • Loss of compile-time flexibility — Because you deliver your application in a precompiled format, you cannot make use of compile-time functionality. For example, you cannot pass arguments to include files to determine sort order, field lists, etc. Users therefore cannot specify their preferences before compilation.
  • More to manage at the development site — R-code's limited portability often requires you to manage multiple code trees for a single version of a single application. As you modify or fix your application and create new versions, the number of code trees can become quite large.

    R-code is also tightly coupled with the application database. This tight coupling requires you to keep a copy of all of your application databases that have different CRC values. After numerous upgrades and fixes, the number of databases can grow quite large.