Try OpenEdge Now
skip to main content
Developing AppServer Applications
Design and Implementation Considerations : Secondary performance considerations : ABL browse design considerations
 

ABL browse design considerations

In an ABL client application, the ABL browse widget is bound to a query at compile time and controls record retrieval and presentation at run time.
In a traditional client/server application where a browse query satisfies a large number of records, the browse widget does not require all records to be delivered immediately; it caches some records not initially in the browse view port and, transparent to the user, requests additional records when the user scrolls to the end of the browse records. Therefore, there are no significant time delays relating to the delivery of a complete set of results prior to viewing data in the browse widget.
If browse data is to be retrieved from an AppServer, the following actions must occur:
1. A query running on an AppServer must gather data from the database
2. Results must be returned to the client application using temp-table parameters
3. The ABL client application must open the browse query against the returned temp-table
This implies that if the remote query satisfies a large number of records, there might be a significant delay prior to viewing data in the browse widget. You might choose to accept this delay since once this delay is incurred no further network access is required. However, if this time behavior is unacceptable, consider choosing alternatives such as:
*Limiting the number of records that are delivered to the client application. For example, transfer only the first 200 records to the client application.
*Creating your own caching and delivery scheme, using the APPEND option of temp-table parameters. For example, transfer to the client application the first 200 records and an indicator as to whether there are more records available. The client application can then notify the user that there are additional records available. If the user actually requires the additional records, the client application can request the next batch of records from the AppServer agent, using the APPEND option, to add to the records that already have been transferred. For information about the APPEND option of temp-table parameters, see OpenEdge Getting Started: ABL Essentials.
Note: This alternative assumes that the AppServer agent building the original query is dedicated in state-reset or state-aware operating mode or is bound in stateless operating mode to the client application.