The simplest way to cause bi file growth is to have a transaction which "spans" user interface activity. A trivial example:
Code:
find first customer.
update custNum.
pause.
If a user executes something like this and "goes to lunch" (or leaves the screen idle for whatever reason) without completing the update the possibility of a transaction rollback still exists. That means that the bi cluster which contains the UNDO notes for the transaction cannot be reused. As other users in other sessions do work their bi notes will eventually fill all unused bi clusters. The bi file will then need to grow.
On busy systems this process can occur fairly rapidly and the bi file can grow quite large.
All because of poor transaction scoping in a single program.
This is a quite common problem in certain off the self packages as well as in custom code developed by inexperienced programmers. (It can also happen to experienced programmers but that takes more work and they at least know what to look for.)
The above example is trivial -- there are lots of other ways to cause this problem. An understanding of transaction scope is absolutely essential for any Progress programmer.