Status: Verified
GOAL:
What dictionary changes force recompiling: Time Stamp and CRC?
GOAL:
When does the Time Stamp change?
GOAL:
When does the CRC change?
FACT(s) (Environment):
Progress 8.x
Progress 9.x
OpenEdge 10.x
All Supported Operating Systems
FIX:
SYSTEM INTEGRITY.
PROGRESS ensures that the program running only has references to files that have remained unchanged since the last compile. This prevents ungraceful programming runtime errors, as well as writes to the database with internal inconsistencies, which could occur if the software tried to address a non-existent or unrecognized data structure.
In versions below 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. In 6.2F and higher, you can use a Cyclic Redundancy Check (CRC) instead by using the -crc startup option.
Version 7 and later uses CRC by default. The CRC is calculated to see if the structure of the database at run time and the structure in place at compile time are the same.
The time stamps may in fact be different but the structure the same if, for example, the database was created from a .df file.
NOTE:
Different dictionary element changes require you to recompile, depends on whether PROGRESS checks timestamps or uses CRC.
DICTIONARY CHANGES THAT REQUIRE RECOMPILING (TIME STAMP)
You need to recompile any program that references a file where the modification to the dictionary did any of the following:
- Deleted the file;
- Changed the file name (existing code would crash);
- Changed the file language (alters indexing collation sequence);
- Added or deleted a field;
- Changed a field: name, order; any change to a schema-holding database for gateways (foreign database field type, length, offset, or case);
- Added or deleted an index; or
- Changed an index: name, uniqueness requirement, field component, number, ascending/descending, abbreviate option.
NOTE: "Referencing" a file includes using the LIKE statement to define working 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 DO NOT REQUIRE RECOMPILING
GUARANTEED APPLICATION FUNCTIONALITY.
As a 4GL, the PROGRESS Dictionary includes many features that, in effect, replace functional application code in a 3GL environment. Any change to one of these
items will NOT force a recompile of the object code.
However, it is important to remember if you do NOT recompile the code, the change WILL NOT TAKE EFFECT. In this case, making such a change without recompiling is like changing the underlying procedural source code in a 3GL and not releasing the compiled programs. If you have added data validation statements or made security changes, for example, the old 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
- Or adding a file (and its associated fields and indexes) if you don't have any source code that references it yet.
DICTIONARY CHANGES THAT REQUIRE RECOMPILING (CRC)
In addition to the items on. the list in the "Require Compile" section before, the following dictionary elements are also used to calculate the CRC and therefore these changes DO force a recompile (if the CRC option was used, 6.2F and higher only).
- File Name
- Field Order
- Field Decimals
- Index number (system-determined at index create time)
When you load a .df which is for a subset of a full database, any indices defined there take on a number which is set to sequence all indices in the database. Therefore, you CANNOT define a database with file one and index one followed by file two and index two, dump each file independently, and then load 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.
If you encounter errors
"CRC for <filn> does not match CRC in <procedure>. Try recompiling. (1896)"
or
"Database is not consistent with <procedure>--Try recompiling. (482)"
recompile the .r code for the program which generated the error. If using multiple databases, make the schemas match before recompiling. If using -crc, load the same .df file into your compile-against database as the one being used in the field for deployment. This ensures that all indices are numbered sequentially from start to finish.
Note: In version 8 idx-num is not part of CRC, the code does not show indexes listed as part of the dictionary that affects CRC. .