Filtering records

<< Click to Display Table of Contents >>

Navigation:  Application development > Filtering records >

Filtering records

Previous pageReturn to chapter overviewNext page

This section is an overview of how to create an expression tree used in DbiAddFilter. This is a fairly complex undertaking. You would want to write an expression tree only when you need to efficiently generate a highly constrained view of the data in a table, by qualifying multiple, unindexed fields. (If the fields were all indexed, you might be able to use DbiSetToKey more easily.)

A filter is a mechanism that lets you qualify the data that a cursor displays, relieving the application of the task of testing each record. For a basic example, let's say you want to open a customer table but display only those customers living in California. To use a filter to accomplish this, you can write your application to define a filter for a cursor open on the Customer table, where customer.state= "CA". When the filter is activated, the BDE retrieves only those records that meet this condition, so your application can view and process only those records. For example, when your application calls DbiGetNextRecord, any records where the customer is not a resident of California are skipped.

To define a filter, the application calls DbiAddFilter, passing the cursor handle and the filter condition specification. The function returns the filter handle to the application. The DbiAddFilter parameter pcanExpr points to an expression tree of type pBYTE. The application can use the expression tree to specify the filter condition.

The advantage of using an expression tree to define a filter condition is that BDE can use it to optimize the filtering operation. The level of optimization depends on the driver's level of support for parsing the expression tree.

After defining the filter, the filter must be activated with DbiActivateFilter.