Special Operators

The following list describes the special operators.

DBOP_pass_through

This operator passes 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 globally unique identifier (GUID). This operator takes one input tree with any result type; output type is the same as input type.

DBOP_defined_by_GUID

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

DBOP_text_command

A command in a textual command language, typically a SQL expression. The language and its dialect are indicated in the guidDialect member of the DBTEXT structure 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", and so on. The textual command is stored in the pwszText member of the DBTEXT structure. This operator produces scalar- or table-valued output. It 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 only the FROM clause of a SQL statement to another consumer, the partial text will contain a string such as "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 that 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 each represented by a Boolean expression. The ORDER BY clause is represented by a sort list. All clauses must be present in the node, but they may be empty. An empty list is denoted by an *_anchor node with no *_element nodes attached to it. SQL scope (visibility) rules apply. The SQL DISTINCT option is specified by setting the fValue member 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

Refers 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.