Special Operators

[This is preliminary documentation and subject to change.]

DBOP_pass_through

Pass the entire subtree to a provider. All operations on the subtree are to be delegated to the provider, including parts of global tree operations such as validation, and can therefore be unexpectedly expensive. The command tree must be self-contained. The provider is identified with a string or a GUID. One input tree with any result type, output type is the same as input type.

DBOP_defined_by_GUID

This is a major means of extensibility: An operator not included explicitly in this enumerated type, known to both consumer and provider by its GUID. Consumer and provider must also agree on count, type, etc. for the operator. The cost of leaving the set of possible operators mostly undefined here is that type checking is entirely left to the provider implementation. Additional node information may be provided in the DBBYGUID struct inside the node. The information stored in pbInfo is provider-specific.

typedef struct tagDBBYGUID {
    BYTE    *    pbInfo;    // extra node information
    ULONG        cbInfo;    // size of the data in pbInfo
    GUID         guid;      // this node's GUID
} DBBYGUID;
 

DBOP_text_command

A command in a textual command language, typically an SQL expression. The language and its dialect are indicated in the guidDialect of the DBTEXT struct stored in the value field in the node structure. Fixed values are defined for SQL-92, SQL-92-intermediate, SQL-92-entry, T-SQL, and Access SQL. In SQL, possible subtrees in the OLE DB command tree are references with strings "::1", "::2", etc. The textual command is stored in the pwszText field of the DBTEXT structure. Scalar- or table-valued output. This operator is used by OLE DB consumers to communicate complete or partial SQL-statements. If the operator has no inputs, then the text stored in pwszText should contain a complete SQL statement. If the operator has an input, then the DBOP_text_command contains a partial SQL statement and its input is the operator to which the partial statement corresponds. For example, if an OLE DB consumer wants to communicate just the FROM clause of a SQL statement to some other consumer, then the partial text will contain a string like "FROM T1, T2" and the input to the operator will be a DBOP_from_list_anchor.

DBOP_SQL_select

The equivalent of a SQL SELECT statement, with its component clauses SELECT, FROM, WHERE, GROUP BY, HAVING, and ORDER BY, in this sequence. The SELECT and GROUP-BY clauses are represented by project lists. The FROM clause input, represented by a from_list_anchor, contains from_list_elements that take a table-valued expression as input. The table-valued expression may refer to a base table, a subquery, or a table-valued result generated by an OLE DB query processor. The WHERE and HAVING clauses are represented by a Boolean expression each. The ORDER BY clause is represented by a sort list. All clauses must be present in the node, but may be empty. An empty list is denoted by a *_anchor node with no *_element nodes attached to it. SQL scoping (visibility) rules apply. The SQL DISTINCT option is specified by setting the fValue field of the SQL_select node as TRUE. The output is a table. If an ORDER BY clause is given and DISTINCT is not specified, then the output is an ordered table. If DISTINCT is specified and no ORDER BY clause is specified, then the output is a unique table. If both DISTINCT and an ORDER BY clause are specified, then the output is an ordered-unique table.

DBOP_remote_table

Refer directly to a table in an external data source without creating a synonym for it beforehand. Its children are identical to that of the DBOP_create_synonym node and the external data source is identified in the same way.