BI threshold

R

ravi_gupta2u

Member
Hi,

I am facing BI threshold(BI size is exceeding) issue for a perticular process. So could anybody let me know the available options to get rid of this issue.

Thanks

Ravi
 
ravi_gupta2u said:
Could you please explain with a example to write the code for same?
Thanks in advance.
Click to expand...

There is no easy way to demonstrate how to correctly scope a program.

If your program is not overly large you could post it and I will have a look to see if I can spot the problem, no promises tho.
 
We do cover this topic every couple of weeks so you could try browsing older threads but, as Stuart says and as the threads will show, there is no easy way to explain this. Particularly in an online forum with little or no information about the circumstances.

If you are very, very lucky your code is short and simple, you can post it and we can tell you what is wrong.

Otherwise the fact that you are asking this question at all very strongly suggests that your organization needs to invest in some training. At the very least sit down with the documentation and carefully review the concepts of record and transaction scope -- you don't say what version of Progress you're using but the basics don't really change.

Transaction scoping is a fundamental Progress programming topic. I strongly suggest that you find a class or hire a mentor. It will be much more effective for both you and your employer in both the short term and the long term.
 
Hi,

One of the developer has define one stream and wrote "output to" to this stream twice and he did not close this stream at all.
This program being calls through a program and calls other programs also.

Is this can be a possible reason for this BI threshold issue. Please let me know.
Thanx
 
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.
 
The example you supplied there Tom reminded me of a story I heard many years ago, although it may have been an "Urban Myth" about a system that was scoped to the initial login screen and when a user switched off his machine instead of logging out at 17:00, triggered a transaction rollback that resulted in the loss of a full days work.
 
I'm sure that it has really happened. More than once.

One particular instance that I am painfully knowledgeable about:

A million or so years ago when I first started coding Progress there was a lot of noise in the trade rags about how vital it was to have "undo" functionality in every application. Naturally this was mistranslated as a requirement that users always be able to undo everything and someone who shall remain nameless thought that it would be a good idea to implement a transaction just as you describe right in the login screen.

It made a nice demo.
 
Winchester said:
why ?
tough it cost a larger disk space.. but it may help to solved, doesnt it ?
sorry.. im just newbie..
CMIIW
Click to expand...

Because it wont solve the problem. I didn't see any numbers for how big the bi file is growing. So it is is a bit hard for me to decide if there is a valid (known) reason for the bi file to grow and if -bithold is set very low then you might decide to increasec this parameter.
But the way the question was posted leads me to believe that you got a transaction somewhere which is bigger then it should be. There are many times that people confuse business transactions with database transactions.
most times this is what needs to be solved.

Casper.
 
You must log in or register to reply here.
Back
Top