Limited portability across user interfaces — 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.

Time-stamp-based r-code requires a copy of new database for upgrades — When you modify the schema of your application database, you invalidate the existing r-code because you change the database's time stamps. To deploy an upgrade, therefore, you must provide users with a new database (with the correct time stamps) for each new version of the application. Users are then required to dump their old data and load it into the new database. This is a time consuming process for larger databases. For very large databases, the time required to perform a dump and load can be unacceptable. Progress Software Corporation recommends that you use CRC checked sums instead of time stamps for more flexibility.