Kbase P129736: Error 1896 on BLOB/CLOB fields post OpenEdge 10.0B
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
17/07/2008 |
|
Status: Verified
SYMPTOM(s):
Error 1896 when running deployed r-code
** CRC for <filn> does not match CRC in <procedure>. Try recompiling. (1896)
Table contains at least one BLOB or CLOB field
incremental .df between production and development shows no differences
database was previously an OpenEdge 10.0B database
database has since updated to later OpenEdge release
FACT(s) (Environment):
OpenEdge 10.0B
OpenEdge 10.1x
All Supported Operating Systems
CAUSE:
Bug# OE00113034
CAUSE:
The CRC error on the lob objects is a consequence of a bug in the OpenEdge 10.0B release where the LOB object was erroneously included in the CRC calcuation.
One of the fields involved in the CRC calculation is the _Field._Fld-stlen field. For BLOB and CLOB fields, OpenEdge internally stores the LOB's storage object number which is generated after the lob-object is created. The object number of each BLOB/CLOB field is unique on any given database.
This object id of a blob/clob field is **not** relevant for the CRC calculation and should have been suppressed from the CRC calculation. Unfortuantely, the _Fld-stlen value cannot be changed after the field has been created. Note that the CRC is only calcuated once the table's schema is changed, so if changes had been made to this schema, a compile would not have worked, otherwise the compile would work without error.
Essentially if this table with the LOB had at some stage been part of a 10.0B release, you may experience this problem.
FIX:
This Solution pertains to environments using OpenEdge releases post 10.0B (ie 10.1x releases and beyond). Please refer to Progress Solution P100296, "BLOB/CLOB fields do not preserve the CRC in OpenEdge 10.0B" if using OpenEdge 10.0B version.
STEPS:
Create another incrental df file which updates the LOB field name from itself to a dummy and from a dummy back to itself. So that in the end nothing has changed, but the crc is recalculated when the .df is loaded into the production database.
1. Access the data-dictionary:
[deployment.db]
rename "myBlob" to another name (say) "myBlob1"
recreate "myBlob" (by copying "myBlob1")
delete "myBlob1"
2. Access the data-administration:
Connect to deployment.db and production.db schemas
Create an incremental.df file against the production.db
Example delta.df file:
UPDATE FIELD "myBlob" OF "OurTable"
ORDER 20
3. Deploy and load the incremental df file created in step 2 into the production database, this will trigger the correct crc for the
application code.