Space allocation issue with LOB objects created by an ODBC client

Space allocation issue with LOB objects created by an ODBC client
SQL engine is not using the database block efficiently to create LOB records in a Type II Storage Area
LOB objects are being created with ODBC SQL connection
BLOB is in a Type II Storage Area that shows excessive space usage after being loaded by ODBC client
1000 Blobs of 159 KB each result in 1.4GB space usage as opposed to an estimated 150 MB
Physical storage being used by the LOB Storage Area is confirmed by "prostrct statistics" as 1.4 GB

LOB Storage Area:
1 records per block
512 cluster size
8 KB database block size
Using default create and toss limits for a database block

LOB objects are stored in their own TYPE II Storage area with 1 record per block as recommended by Article P88663, Best practices with BLOB/CLOB fields   

Multiple users are not creating and updating records on the LOB table simultaneously

The code in the SQL engine to append data to an existing lob fragment was not working properly.   Each SQLPutData() of 1KB was creating a new record to hold the lob fragment rather than appending the next 1KB to the existing record.  This issue has been in the product since lobs were introduced.

Upgrade to OpenEdge 10.2B04, 11.0 or later where this issue has been fixed so that each record holding the lob data will now grow to 32K across 4 x 8K blocks (for example) before a new record fragment is created for the LOB segment.

Note, this issue affects only LOBS created via the SQL engine, it cannot be reproduced with ABL code in OpenEdge 10.1B02 and above.
 

Change the Records per Block to 8 or 16 for an 8KB database blocksize to allow more recids available for each database block to fill.  The ideal value depends on the size of the LOB object that the ODBC client is creating. First verify in a test environment.