When the X/Open Company and the SQL Access Group developed the 1992 SQL CAE specification, they recognized that some data sources would need a way to process exceptions and additions to the standard SQL language. Thus, the SQL CAE specification defines a special "escape clause" method that can be used to send SQL language extensions directly to the data source.
A number of language features, such as outer joins and scalar function calls, are commonly implemented by DBMSs. However, the syntaxes for these features tend to be DBMS-specific, even when standard syntaxes have been defined in the various SQL standard specifications. Because of this, ODBC defines escape sequences that contain standard syntaxes for the following language features:
ODBC escape sequences use the "escape clause" method defined in the 1992 SQL CAE specification to send data-source specific SQL grammar to a data source (via the driver) for processing. The escape sequence used by ODBC is as follows:
{extension}
ODBC escape sequences are recognized and parsed by drivers. When a driver receives an escape sequence, it replaces it with the appropriate data source-specific SQL grammar before sending it to the data source for processing. Because the escape sequences are mapped by the driver to DBMS-specific syntaxes, an application can use either the escape sequence or DBMS-specific syntax. However, applications that use the DBMS-specific syntax will not be interoperable. When using the escape sequence, applications should make sure that the SQL_ATTR_NOSCAN statement attribute is turned off. Otherwise, the escape sequence will be sent directly to the data source, where it will generally cause a syntax error.
Drivers normally support only those escape sequences which they can map to underlying language features. For example, if the data source does not support outer joins, neither will the driver. To determine which escape sequences are supported, an application calls f90SQLGetTypeInfo and SQLGetInfo.