For detailed information on how to code these operations, see Btrieve API Guide. This section explains how to optimize your use of these operations for best performance.

Descriptor
Also called the Extended Expression. The whole contents of the data buffer which describes how the Btrieve extended operation should be accomplished.

Filter
A portion of the Extended Expression which describes a selection criteria to apply to the records being selected.

Condition
A portion of a filter that uses a single logical operator.

Connector
A Boolean operator that connects a condition to what follows it. Either AND, OR, or NONE

Extractor
A portion of the Extended Expression which defines what data to return.

Key
A whole index definition which may have multiple segments. Get operations require the MicroKernel to move through the data file along a single key path.

Key Segment
Compound indices, also called multi-segmented keys, can have multiple segment definitions. Each segment defines an offset, length, data type, and so on.

(Field1 = AAA AND (Field2 = AAA AND (Field3 = AAA)))
The MKDE retrieves record 1 and stops searching with status 64 (Optimization limit exceeded). The last record examined that satisfies the optimization criteria is record 1 which becomes the current record. Engines before Pervasive.SQL 2000 SP3 can optimize only one condition and thus leave the current record at record 3.

(Field1 = AAA OR (Field2 = AAA OR (Field3 = AAA)))
The MKDE retrieves records 1, 2, 3, 4, 5, 6, 7, 10, 13 & 14 and returns with status 9 (End of file reached). No condition can be optimized since the first condition contains an OR connector. The current record becomes record 14.

(Field1 = BBB AND (Field2 = BBB OR (Field3 = BBB)))
The MKDE would retrieve records 5, 7, 8, 9 & 11 and return with status 64. The first condition was optimized, but the second condition was not since it contained an OR connector. The last record examined that satisfies the optimization criteria is record 12 which becomes the current record.

(Field4 = OOO AND (Field2 = BBB AND (Field3 = BBB)))
The MKDE retrieves records 2 & 8 and return with status 9. No condition can be optimized to the first key segment, so the following segments cannot be optimized. The current record becomes record 14.

(Field1 = BBB AND (first byte of Field2 = B AND (Field3 = BBB)))
The MKDE retrieves record 8 and returns with status 64. The first two conditions can be optimized, but since the second condition is a substring, the third condition cannot be optimized. The last record examined that satisfies the optimization criteria is record 9. Engines prior to Pervasive.SQL 2000 SP3 can optimize only one condition and thus return with record 12 as the current record.

(Field1 = BBB AND (Field2 = Field3))
This is done by using the +64 bias on the comparison code, which indicates that the second operand is another field of the record, rather than a constant. The MKDE retrieves records 4, 8 & 12 and returns with status 64. The first condition can be optimized, but since the second condition does not compare to a constant, it cannot be optimized. The last record examined that satisfies the optimization criteria is record 12.

(Field1<= BBB AND (Field2 <= BBB AND (Field3 <= BBB)))
The MKDE retrieves records 1, 2, 4, 5, 7, & 8 and returns with status 64. The first condition can be optimized, but since it does not have a logical operator of EQ, the following conditions cannot be optimized. The last record examined that satisfies the optimization criteria is record 12.

(Field1= BBB AND (Field2 < BBB AND (Field3 < BBB)))
The MKDE retrieves record 4 and returns with status 64. The first condition can be optimized, but since the second condition does not have a logical operator of EQ, it cannot be optimized. The last record examined that satisfies the optimization criteria would be record 12.

(Field1= BBB AND (Field2 = BBB AND (Field3 < BBB)))
The MKDE retrieves record 7 and returns with status 64. The first two conditions can be optimized because they use EQ, but the third condition cannot. The last record examined that satisfies the optimization criteria is record 9. Engines prior to Pervasive.SQL 2000 SP3 can optimize on only one condition and so the current record would be 12.

(Field2>= AAA AND (Field2 <= BBB AND (Field1 >= AAA) AND (Field1 <= BBB))))
The MKDE retrieves records 1, 2, 4, 5, 6, 7, 8 & 9 and returns with status 64. The first three conditions cannot be optimized to the first key segment, but since they are all ANDed together, the fourth condition can be used to optimize the search. The second condition would be optimizable if it occurred immediately after the fourth condition. But since it is out of position relative to the key segments, it cannot be optimized. Since only one key segment is optimized, the last record examined that satisfies the optimization criteria would be record 12. Note that there is a defect in Pervasive.SQL 2000 SP3 that prevents optimization unless the optimizable condition occurs first. So the SP3 engine would retrieve the same records, but would return status 9.