Solution ID: 297
SYMPTOM(s):
** CRC for <filn> does not match CRC in <procedure>. Try recompiling. (1896)
** Database is not consistent with <procedure>--try recompiling. (482)
FIX:
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. Please note that different dictionary element changes require you to recompile, depending 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.
Please note that "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
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 UNDER -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 error:
"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..