This issue will only affect databases that:
- Were converted with conv910 conv1011 utilities from a prior OpenEdge 10.1B database
- Were previously an OpenEdge 10 database upgraded to OpenEdge 10.1B or later OpenEdge 10 version
- And since using the OpenEdge 10.1B or later database, have records with rowids in 64-bit range.
Since 64-bit dbkey support was introduced in OpenEdge 10.1B, there is an implicit requirement that any record in a Type II area must have at least 10 bytes, otherwise there is the possibility that the next fragment may point to a 64 bit rowid which will not fit in the space of the original fragment.
With OpenEdge 10.1B record version, non-schema records size will always be larger than 10 bytes. When a new record is created, the new version of a record has an array field header that assures the size of the record will always be larger than 10 bytes, therefore newly 10.1B created non-schema records will never have this issue.
Any schema-modifications by a pre-OpenEdge 10.1B client server connection to the OpenEdge 10.1B database modifying the schema, will however not have this guarantee. Schema records that were created in a pre-10.1B version, do not have the array header so the size of the record (or fragment) can be smaller than 10 bytes. So any records that have a <10 byte header, if the next fragment points to a 64 bit recid, it will not fit in the space of the original fragment. This causes the database crash with error 822 during the time of the update/delete and subsequent bi redo during crash recovery.
