Application protection — Because encrypted source cannot be read by users, it protects your application from users by preventing them from making changes. Encrypted source shares this advantage with r-code, which also is not user-readable.

Less to manage at development site — Encrypting source code requires storing two code trees: the unencrypted source tree and the encrypted source tree (which must be kept in a parallel directory structure). While this is twice what is required with unencrypted source, it is still less than what is required for r-code.

Full portability — Like unencrypted source, encrypted source is completely portable across platforms and user interfaces (character mode and GUI). However, r-code is not portable across user interfaces.

Compile-time flexibility — Because encrypted code is not precompiled, your application can take advantage of compile-time functionality. For example, you might want to pass arguments to include files to determine sort order, field lists, etc. You can take advantage of this behavior at the user site, allowing users to specify their preferences before compilation. This option is not available with r-code, which you must compile at the development site.

Flexible index definitions — If users have full development OpenEdge products, they can modify their indexes without invalidating your application code (provided that you have not explicitly named indexes in your code). This flexibility is not available with r-code, since r-code that specifically references a new or changed index does not work. Because the index Cyclic Redundancy Check (CRC) value is checked at run time, not all r-code will be affected. Time-stamp-based r-code is even more restrictive.

Less space used on storage media — Encrypted source files usually occupy much less storage space than r-code files, making your physical media shipment smaller and less expensive. (Unencrypted source files also have this advantage over r-code files.)

Encryption keys — Encrypted source allows you to specify different encryption keys for different code trees or subsystems within a code tree. Therefore, it is possible to deploy an entire application at once, but only give the user encryption keys for certain parts of the application. This way, you can upgrade the user's application without physically distributing code a second time.