Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

QUICKDEX.MFS provides a good model for using an MFS to trap READNEXT requests. If the filing system SELECT call has returned a select mode of 1 (latent file select), QUICKDEX.MFS traps the READNEXT call. The MFS reads the %RECORDS% record from the current file, and returns it as the next block of keys. If another READNEXT call comes down to the MFS, QUICKDEX.MFS simply returns a false, since all keys were returned in the first call.

Extended (Resolved) Select

Unlike the simple SELECT statement, the extended BASIC+ SELECT ... BY statement results in a resolved list of record keys. Instead of simply initializing variables, the special SELECT processor executes a series of operations. Only when the operations are completed and when a list of record keys is available does the BASIC+ program proceed to the next statement.

The BASIC+ logic that generates a resolved list looks something like this:

 

Code Block
SELECT "FILENAME" BY "FIELD1" SETTING 0 ELSE
  CALL MSG(@window, "Select failed with status ":STATUS())
  RETURN 0
END
* resolved list now available
* (no BFS access required)
DONE = 0
LOOP
READNEXT @ID ELSE DONE = 1
UNTIL DONE DO
(etc.)
REPEAT

 

 

In order to resolve the select list, the special SELECT processor must examine each record in the file (or index). As a result, SELECT ... BY generates a series of filing system calls. In effect, the single BASIC+ SELECT statement compresses an entire SELECT ... READNEXT ... READ loop into a single statement, examining each record in the file.

When the READNEXT loop is completed and all records have been assembled, the SELECT processor sorts the records. The result is a resolved select list, with the keys in order according to sort criteria specified in the SELECT ... BY statement. The entire select list is then available in the system list variable and @LIST.ACTIVE is set to 3. Because the SELECT ... BY statement has completely resolved the select list, no further filing system calls are required. The READNEXT processor simply fetches the sorted keys from the system list variable, without requiring filing system READNEXT calls.

Indexed-Based SELECT

If the sort criteria passed in an extended BASIC+ SELECT statement represent indexed fields, there is no need for the SELECT processor to execute an entire SELECT ... READNEXT ... READ loop in order to build a resolved list of keys. Instead, the list can be constructed directly from the Btree index.

...