Undoing delete of BLOB/CLOB fields of less than 8 bytes can corrupt database if enough data is present.

Inserting BLOB/CLOB fields of less than 8 bytes can corrupt the database.

This happens if:

• The dbkey pointers for the Storage Area where the BLOB/CLOB resides moves from 32-bit range into 64-bit range
• Multiple users are updating the BLOB/CLOB fields of this table at the same time (with different records)
• Operations are performed that UNDO the delete of BLOB/CLOB data.

Issues can manifest in different ways, including:

• Remote Server processes crashing
• The database performing ABNORMAL SHUTDOWN
• The BI file being corrupted, causing crash recovery to fail on next startup (also when the database is shut down normally requiring Logical UNDO)

The data changes triggering this issue are propagated via Replication.
 

Defect that can lead to corrupted internal control structures when crossing the recid 32/64-bit boundary:

1. The minimum lob length to enact small lob records is not calculated properly
2. When a transaction that created/updated lobs needs to be rolled back, not enough space was reserved to allow a redo of the undo

Upgrade to OpenEdge 11.3.3 or later
Upgrade to OpenEdge 11.5.0 or later

1. Fixed the calculations to determine if a 64 bit continuation marker will fit in the current rm block during update and undo delete processing. 
2. Code was changed to save enough space for undo delete when < 64 bit continuation can be added. 
3. For small blobs (between 4 and 8 bytes) ensure enough space is reserved to allow undo of a delete to be successful without requiring a record continuation.

Progress Article:

 UNDO of transaction writing LOB data to large database corrupts database BI file