Integrated Indexes (OLE DB)

OLE DB indexes are designed for use with base tables (tables opened by IOpenRowset::OpenRowset). Providers built over command processors, such as SQL query processors, are expected to use indexes internally but not expose them through OLE DB. The primary consumers of OLE DB indexes are the following:

• Query processors accessing data in OLE DB providers, such as DBMS storage engines and ISAMs, which do not support commands.

• Service components or providers that implement IViewRowset, IViewFilter, or IViewSort.

OLE DB provides the ability to open separate rowsets over base tables and indexes, allowing the consumer to traverse each separately. However, certain providers can support indexes and base table data on the same rowset (also known as a clustered index). Providers can expose this as an integrated index by exposing IRowsetIndex directly on the base table rowset. This allows the consumer to set index ranges and seek index values directly on the base table rowset, without having a separate (and in this case redundant) index rowset. Such rowsets are said to have integrated index behavior. Providers can support separate indexes, integrated indexes, or both.

This section discusses requesting, using, and the structure of integrated indexes. The structure is more loosely defined than a nonintegrated index rowset. A useful element of integrated indexes, of course, is the ability to fetch data. The topic of row fetching includes rowset order, next fetch position, range, updating index rows, visibility of index changes, and the effect of changes on the next fetch position and index range. Accessors, the collection of information that describes how data is stored in the consumer's buffer, are discussed in light of methods and restrictions. Restrictions on integrated indexes and executing commands are discussed also. An integrated index code example is provided.