LOB < 10 bytes cannot be fixed after re-creating the LOB

DBTOOL reports:

In the message if the number after "LOB" is 1 or 2, it indicates that the fragment is for LOB, otherwise it is a regular record (LOB 0).

The LOBs that DBTOOL reports warning are mini direct LOBs (of data length 1 to 10 bytes) that don't have connecting record fragments. "Mini-Lobs" cannot be fixed either by DBTOOL, D&L or re-importing the LOB as unlike records, LOBs under 10 bytes (mini-lobs) are allowed. 
 
A direct mini-LOB record is one that does not have a next fragment. It is allowed because it does not need to save the additional space for next rowid.

In OpenEdge 101C, there was a change to handle updates to mini-LOB records by deleting and re-creating it when the containing block is full.




 

The warnings raised for these direct mini LOBs are no longer legitimate since OpenEdge 10.1C and have been removed from DBTOOL in OpenEdge 11.7 

In OpenEdge 11.7, these Warnings will still be raised when:

1. For mini-LOBS (LOB 1 or LOB 2) that do have next fragments as they will need enough space to store 64bit rowids.
2. For normal records (LOB 0), where >= 10-byte is needed to reserve space for 64bit-dbkey.

DBTOOL Option 6 can fix these if there is enough space in the first block of the rowid to expand out the 10 bytes needed. When addressing this issue with a LOB field, run the utility must be run offline.

Otherwise DBTOOL cannot fix them and will report: In which case a dump / load is required to re-create these records and avoid the problem with deletion outlined in the Article Reference below.

Progress Articles: 

Undoing delete of BLOB/CLOB fields of less than 8 bytes can corrupt database if enough data is present.   
UNDO of transaction writing LOB data to large database corrupts database BI file