What dictionary changes force recompiling Progress r-code: Time Stamp and CRC?

What dictionary changes force recompiling: Time Stamp and CRC?
When does the Time Stamp change?
When does the CRC change?

This Article applies releases up to Progress 9.1x (inclusive) only. For later releases, refer to Article  What dictionary changes force recompiling in OpenEdge?   

SYSTEM INTEGRITY

PROGRESS ensures that the program running only has references to files that have remained unchanged since the last compile. This prevents programming runtime errors, in particular writes to the database with internal inconsistencies when data structures between code and database no longer match.

In versions below Progress 6.2F, a file-level time stamp in the database schema is checked against the corresponding time stamp embedded into the object code at compile time. The time stamps may in fact be different but the structure the same if, for example, the database was created from a .df file.  
In Progress 6.2F and later, a Cyclic Redundancy Check (CRC) can be instead using the -crc startup option.
Progress 7 and later uses CRC by default. The CRC is calculated to determine if the database structure at run time and the structure in place at compile time are the same.  
Starting with Progress 7, use of timestamps is deprecated and supported for legacy purposes only. The use of timestamps is strongly discouraged in the later releases.

Different Dictionary element changes that require code to be recompiled, depends on whether PROGRESS checks timestamps or CRC.

DICTIONARY CHANGES THAT DO NOT REQUIRE RECOMPILING

As a 4GL, the Progress Data Dictionary includes features that effectively replace functional application code in a 4GL environment.  Any change to one of these items will not force a recompile of the object code.

However: If the code is not recompiled, the change will not take effect. Without recompiling, Data Dictionary changes will not be included in the r-code. For example: After adding Data Validation statements or making Security Changes, the old r-code continues to allow updates without enforcing the new validation and the new security is not in effect.
             
These application-oriented changes include adding, changing, or removing:

• APPEARANCE:    Format, Column-label, Label, Decimal
• DATA ENTRY:    Initial Value, Mandatory entry, Case sensitivity, Validation expression, Delete validation, Security
• USER INFO:     Help messages, Validation message, Description
• Adding a Table (and its associated fields and indexes) not referenced in any deployed source code (yet).

DICTIONARY CHANGES THAT REQUIRE RECOMPILING (TIME STAMP)

Following modifications to the Application Schema will force a recompile:

• Deleted the file
• Changed the file name
• Changed the file language (changing indexing collation sequence)
• Added or deleted a field
• Changed a field: name, order; any change to a schema-holding database for gateways/data servers (foreign database field type, length, offset, or case)
• Added or deleted an index
• Changed an index: name, uniqueness requirement, field component, number, ascending/descending, abbreviate option.

"Referencing" a file includes using the LIKE statement to define variables based on dictionary entries. Also, you cannot change a field's extent or data type without deleting the original field and adding a new one, so the impact is the same.


DICTIONARY CHANGES THAT REQUIRE RECOMPILING (CRC)

In addition to the items listed above that require recompiling for Timestamps, the following dictionary elements are also used to calculate the CRC and therefore force a recompile if the CRCs are used:

• Field Decimals
• Index number (system-determined at index create time)

When an incremental .df which is for a subset of a full database is loaded, any indices defined there take on a number which is set to sequence all indices in the database.
Therefore, a database with file one and index one followed by file two and index two, cannot be dumped independently then loaded file two followed by file one. The indices in the different databases will have different idx-num values, which will result in a different CRC. To examine the _idx-num values, run this procedure:

  FOR EACH _Index:
      FIND _File OF _Index.
      DISPLAY _File-name _Idx-num _Index-name.
  END.

The following errors indicate CRC mismatches:  
Recompile the .r code for the program which generated the error.  If using multiple databases, ensure the schemas match before recompiling.  If using -crc, load the same .df file into the compile-against database as the one being used in for deployment.  This ensures that all indices are numbered sequentially from start to finish.

In Progress 8 idx-num is not part of CRC, the code does not show indexes listed as part of the dictionary that affects CRC.  For further elaboration on the subject, refer to Article  Cyclic Redundancy Check Explained