When a user chooses a search key from the search page, the component processor will build a set of SQL statements to retrieve data from the database and store it into the buffer.
The component processor uses a specific set of rules to do this. If a field from a record is referenced on a page, then all fields/columns from that record definition and all rows that are subordinate to the search key are retrieved into the component buffer.
There are, however, a few exceptions to this rule. The first exception has to do with the data at level 0. If the only fields at level 0 are the search key and alternate search key,then the component processor will only retrieve those fields and not the entire row. However, if there is at least one field that is not a search field on the page at level 0, the component processor will retrieve the entire row and load it into the buffer.The second exception deals with related fields. If you have a related field on the page, the component processor will only retrieve that field from the database and place it in the buffer. It will not bring in any other columns or rows from the record definition associated with the related display.Other fields may also be retrieved. These fields consist of the following types of fields:
• Derived/Work Field
• Translate Table Field
If an entire row of data was brought into the buffer, any PeopleCode program on any field event within that record definition may be accessed and executed. Here are a few other rules for PeopleCode and the buffer allocation.
• If derived/work fields are brought into the buffers, any PeopleCode on that specific field maybe performed.
• PeopleCode on the related/display record definition is NOT performed.
If the component processor retrieves all of the data that is subordinate to an occurs-level (say all the records at a level) or when it can’t find any more child record definitions, it will retrieve the next row of data at the current occurs-level. It will continue to work its way down through the occurs levels.
If it is at all possible, I highly advise you to use views as the primary record of scroll areas.Using views eliminates the need for related displays and can enhance PeopleCode efficiency.
If an entire row of data was brought into the buffer, any PeopleCode program on any field event within that record definition may be accessed and executed. Here are a few other rules for PeopleCode and the buffer allocation.
• If derived/work fields are brought into the buffers, any PeopleCode on that specific field maybe performed.
• PeopleCode on the related/display record definition is NOT performed.
If the component processor retrieves all of the data that is subordinate to an occurs-level (say all the records at a level) or when it can’t find any more child record definitions, it will retrieve the next row of data at the current occurs-level. It will continue to work its way down through the occurs levels.
If it is at all possible, I highly advise you to use views as the primary record of scroll areas.Using views eliminates the need for related displays and can enhance PeopleCode efficiency.
No comments:
Post a Comment