Try OpenEdge Now
skip to main content
DataServer for Oracle
Initial Programming Considerations : ABL issues : Compiling ABL procedures : r-code
r-code is generated when an ABL procedure is compiled. The compiled r-code is portable among machines. For example, r-code that you compile on a Sun machine can run on any other UNIX machine.
r-code is not portable among windowing systems; that is, r-code compiled for a character application will not run under Windows and r-code compiled for Windows will not run under a character application.
The r-code is also not portable among database management systems. For example, code that you have compiled for an Oracle database will not run with an OpenEdge database.
r-code is also not portable among different databases. 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.
The size of r-code can grow when you compile procedures against an Oracle database as compared with compiling against an OpenEdge database. The r-code for a DataServer application contains as text the portions of SQL statements that the DataServer passes to Oracle. The r-code descriptors for column references contain more attribute information than corresponding OpenEdge descriptors.
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.