Kbase 13635: Why INDEXED-REPOSITION can't use more than one index
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
10/05/1998 |
|
Why INDEXED-REPOSITION can't use more than one index
A new feature in the browse beginning in Version 7.3 is INDEXED-
REPOSITION. When implementing a browse with INDEXED-REPOSITION, it is
possible to reposition the query to a particular record much faster
than on the 7.2 browse. One of the limitations of INDEXED-REPOSITION,
however, is the fact that the query cannot make use of more than one
index.
This is because INDEXED-REPOSITION is implemented by throwing away the
result-list and instead using the server's single-index repositioning
capability to move to various records in the query. The use of
multiple indexes requires a result-list, so INDEX-REPOSITION and
multiple indexing are by definition incompatible.
When repositioning to a RECID, far from the current location in the
result-list, there are two choices: one, to go about building up the
result-list until you reach the target record (thus putting the
server, result-list, and browse all in sync) or two, to use the
server's index to jump immediately to where you want to be. This
notion of disregarding the result-list is one reason that the
scrollbar thumb in the browse moves to the middle after an indexed-
reposition and never moves. With no result-list, the browse no longer
"knows" where it is in relation to the complete set of records. What
that buys in return is speed. Without having to build and retain
the result-list, repositioning is much faster.
Progress Software Technical Support Note # 13635