r-code is generated when an ABL procedure is compiled. The compiled r-code is portable across user interfaces. For example, r-code that you compile on Sun Solaris can run on any other UNIX system (character user interface).
r-code is not portable across Window systems; that is, r-code compiled for a character application will not run on Windows and r-code compiled for Windows will not run on a character user interface.
r-code is also not portable among database management systems. ABL generates calls that are specific to a database. For example:
Code that you compile for a database named sports will not run with a database named mysports.
Code that you compile for MS SQL Server will not run on an OpenEdge database.
Prior to OpenEdge Version 11, r-code stored the physical position of a database column. r-code was not compatible with the server schema if the position of a column changed on the server. In Version 11, r-code stores a logical identifier for the physical position of a database column. Therefore, in OpenEdge 11, column positions in the server table can be rearranged without the need to recompile. However, introducing a new column or deleting an existing column from an existing record structure always requires the r-code to be recompiled against the new schema layout.
The r-code is dependent only on a logical identification of the column, and not the physical position of the column. The logical identification, in the OpenEdge database, takes place before migrating to a foreign data source, and the logical identification does not change once the column is defined in the OpenEdge table. When the columns are rearranged on the server, the code need not be recompiled, but the foreign schema must be pulled back into the schema image. This is to ensure that the new physical position of a column is matched in the schema to the logical identifier that is also known to the r-code.
You can only run r-code or load data (.d file) while connected to a schema image that is derived from the same database that was migrated and connected to the server when the code was first compiled and/or the data was first dumped. This ensures that the same logical column identifier is preserved after migration and/or after any subsequent schema pulls.
Note: When the server table is re-pulled into the same schema image (after the columns are rearranged on the server), the logical column identifier is re-matched to the physical column position so that the r-code can find again the column in a run-time application.
See OpenEdge Deployment: Managing ABL Applications for more details on r-code portability.
The size of r-code grows significantly when you compile procedures against a MS SQL Server data source as compared to compiling against an OpenEdge database. The r-code for a DataServer application contains as text portions of SQL statements that the DataServer passes to the data source.