There are transactions in CGI Advantage Financial that have anywhere from a simple tab to ones with over ten tabs. Some of these tabs are the only historical source of information while others update one or more inquiries. Given that certain transactions make many system updates and others make only a small number of updates, not all transactions and transaction tabs should have the same line limits. Restrictions should be placed judiciously on those transaction components that require large amounts of memory or for other reasons such as forms printing. Checking limits will also have a performance impact that should be reserved for those transactions that need the limits. The application will always look up each tab of a transaction to determine if there is a limit. If there is, then the application will determine if that limit is exceeded by counting the number of records for that tab. If no limit exists, then the counting and subsequent evaluation will not occur. This line limit feature only occurs when the property EnforceMaxLineLimit is set to true in the ADV30Params.ini file.
Limits are enforced through the Transaction Component Requirements (DCREQ) page. A limit can be placed on the number of lines for a transaction type and transaction component combination by creating a record with a Property Name of MAX_LINE_LIMIT and a chosen limit in the Property Value. Updates to this reference page will require all application servers (VLSs dedicated to online/offline processing) are brought down and then brought up.
Limits are evaluated in one of two situations. The first is online when an insert of a line is attempted. The second is offline when an entire transaction is to be inserted. When a limit is exceeded online, the user s returned to where the action was taken that inserted more rows into a component than allowed without any new lines. A common error will be issued stating the limit that was exceeded. The exceeding of a limit offline will result in that common error in the Job Log.
Putting limits into place or reducing them after transactions have been created that are larger than the new limit will cause problems when performing many actions on those larger transactions. This situation cannot be avoided except by putting limits on all components before transaction processing and never reducing those limits. Such setup is impractical and bad for performance. Limits will be an evolving maintenance issue in Advantage. When a temporary increase of the limit is often the only solution that can be taken, it should be taken with caution. Once over a limit, a temporary increase will only ensure the current action is possible. When the time comes to perform certain other actions on the transaction, then the limit will have to be increased again.
When a transaction first encounters a memory problem, it may have been the largest transaction to date, or it could have just been the first large transaction of many to compete for limited resources and cause a memory problem. Such factors have to be considered when setting limits. Most often limits are in a range that allows for normal load processing and not high volume processing as that would require the use of smaller limits. Keep in mind that a component line limit is not a guaranteed solution to prevent all memory problems as many factors other than transaction size determine memory availability.
Other exceptions are those actions that do not create lines. The following is a list of actions that perform limit checking. Following that is a list of those actions that do not check limits. The common difference between the two groups is that the 1st group creates new lines and the second only updates existing lines.
Common actions that perform limit checking:
Insert Line
Insert Copied Line
Copy Forward
Cancellation Draft Creation
Modification Draft Creation
Copy Transaction
Recurring Transaction Triggers
Unarchive
Many different types of transactions contain actions in the tab level and record level menus where lines within the transaction are created by the action. Each of these can present the situation where a line limit is exceeded. In many cases, the solution is to reduce the number of parent lines within the transaction so that the action does not create as many children lines.