The large size of lbi files is a problem in the application code itself and as such will be solved by fixing the Application code.
- Only subtransactions (a transaction block nested within another transaction block) and UNDO objects (variables and temp tables) are written to the ABL client local-before-image (lbi) file.
- Progress uses the lbi* file type to support the back-out of subtransaction and variables when an error occurs or the user session terminates their session before it has completed, for example.
- Whereas Transactions are recorded in the database Before-Image file, but unlike the database BI file, one LBI file is maintained for each user along with the other client-temp files like DBI, srt etc.
- These files are stored in the working directory by default or the location defined by the client-startup parameter -T. Ideally these should to be in a unique directory for each client and stored locally to the client.
The fact that LBI growth has been noted as a problem, reaching 2GB prior to OpenEdge 10.1C or breaching 2Gb in later versions, is a strong indicator that the 4GL code that triggers this growth is in need of revision.
Suggestions to review the application code to reduce the size of the lbi files:
1. Define variables as NO-UNDO, provided you don't need to back these variables values out in case of a system crash.
2. Define temp-tables as NO-UNDO, provided you don't need to back these values out in case of a system crash.
3. Reduce the size of transactions and sub-transactions. Recursive loops will for example cause the lbi file to grow.
4. Understand the record scope and transaction scope within your application in order to reduce it. The COMPILE LISTING option which will provide a view on record and transaction scope for each procedure. (Refer to the OpenEdge Development manual for further information on how this works and how to read the listing).
5. Enabling client logging could also help to identify the transaction scope at runtime. Example:
