Relaxing CRC Validation Rules for pre-compiled r-code

When a DataServer application is presented to a non-matching schema holder the application partner may be able to avoid the recompilation of r-code despite schema inconsistencies should the application partner or ISV desire to ship r-code instead of source code. If adding a new field or modifying certain field attributes of an existing field in the database does not change the logical record position, the OpenEdge data type or the number of extents of a field being referenced by the r-code, r-code can still be run against the non-compliant schema without recompilation.

Internally, the DataServer schema holder stores the table CRC value for each user table loaded into the schema holder. This CRC value is the currency/signature for that particular table and is compared against the CRC value stored in the r-code if that particular table (the signature at the time of compile) is referenced by the r-code. Any mismatch between the two values is reported as CRC mismatch error. Normally, this problem is corrected by recompiling r-code for the application against the schema holder that had been modified since the last r-code compilation. This is the best way to both avoid CRC failure and ensure that there will be no inconsistencies in the CRC values or application behavior due to inconsistencies. However, it is now possible to run r-code against a schema holder logical database that has been updated with the following server changes: