Kbase P105083: CRC value changes when applying a df file to 9.1E or 10.1X database
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
8/10/2005 |
|
Status: Verified
FACT(s) (Environment):
Progress 9.1E
OpenEdge 10.1x
SYMPTOM(s):
CRC value changes when applying same df to 9.1E or 10.1X databases
The df file was not created from a 9.1E or 10.1X database
** CRC for <filn> does not match CRC in <procedure>. Try recompiling. (1896)
** Unable to run startup procedure <name>. (492)
Upgrading from Progress version 9.1X to Progress version 9.1E
Upgrading from Progress version 8.3X to Progress version 9.1E
No problem upgrading from Progress version 8.3X to all releases of version 9 except 9.1E
Some of the character fields have the LENGTH keyword
CAUSE:
Bug# 20050608-001
CAUSE:
The reason for the CRC difference is that some of the character fields have the LENGTH keyword. The LENGTH keyword represents the _Decimals value but should only exist for a character field if this is a DataServer schema. Progress schema should not have this keyword. In 9.1E, code was added to prevent this value from making it into the db if the field is not a decimal field.
So when you load the .df into 9.1E which contains a value for the LENGTH keyword the CRC will be different because we won't update the _Decimals value for a character field
FIX:
The bug is fixed in 9.1E02. You can either install the Service Pack 9.1E02, or perform the following workaround:
Before migrating to 9.1E or releases 10.1 and above, remove the LENGTH keyword or update the _decimals value for the field causing the problem.
You will need to recompile your application.
Before making changes to the database schema you should back up your database.