(DM) The InfoType argument was SQL_DRIVER_HDESC, and the value pointed to by InfoValuePtr was not a valid descriptor handle.

(DM) The value specified for BufferLength was an odd number, and *InfoValuePtr was of a Unicode data type.

SQL_AF_ALL
SQL_AF_AVG
SQL_AF_COUNT
SQL_AF_DISTINCT
SQL_AF_MAX
SQL_AF_MIN
SQL_AF_SUM

An SQL92 Entry level – conformant driver will always return all of these options as supported.

The SQL92 or FIPS conformance level at which this feature needs to be supported is shown in parentheses next to each bitmask.

The following bitmasks are used to determine which clauses are supported:

SQL_AD_ADD_DOMAIN_CONSTRAINT = Adding a domain constraint is supported (Full level)

SQL_AD_ADD_DOMAIN_DEFAULT = <alter domain> <set domain default clause> is supported (Full level)

SQL_AD_CONSTRAINT_NAME_DEFINITION = <constraint name definition clause> is supported for naming domain constraint (Intermediate level)

SQL_AD_DROP_DOMAIN_CONSTRAINT = <drop domain constraint clause> is supported (Full level)

SQL_AD_DROP_DOMAIN_DEFAULT = <alter domain> <drop domain default clause> is supported (Full level)

The following bits specify the supported <constraint attributes> if <add domain constraint> is supported (the SQL_AD_ADD_DOMAIN_CONSTRAINT bit is set):

SQL_AD_ADD_CONSTRAINT_DEFERRABLE (Full level)
SQL_AD_ADD_CONSTRAINT_NON_DEFERRABLE (Full level)
SQL_AD_ADD_CONSTRAINT_INITIALLY_
DEFERRED (Full level)
SQL_AD_ADD_CONSTRAINT_INITIALLY_
IMMEDIATE (Full level)

The SQL92 or FIPS conformance level at which this feature needs to be supported is shown in parentheses next to each bitmask.

The following bitmasks are used to determine which clauses are supported:

 SQL_AT_ADD_COLUMN_COLLATION = <add column> clause is supported, with facility to specify column collation (Full level) (ODBC 3.0)

SQL_AT_ADD_COLUMN_DEFAULT = <add column> clause is supported, with facility to specify column defaults (FIPS Transitional level) (ODBC 3.0)

SQL_AT_ADD_COLUMN_SINGLE = <add column> is supported (FIPS Transitional level) (ODBC 3.0)

SQL_AT_ADD_CONSTRAINT = <add column> clause is supported, with facility to specify column constraints (FIPS Transitional level) (ODBC 3.0)

SQL_AT_ADD_TABLE_CONSTRAINT = <add table constraint> clause is supported (FIPS Transitional level) (ODBC 3.0)

 SQL_AT_CONSTRAINT_NAME_DEFINITION = <constraint name definition> is supported for naming column and table constraints (Intermediate level) (ODBC 3.0)

SQL_AT_DROP_COLUMN_CASCADE = <drop column> CASCADE is supported (FIPS Transitional level) (ODBC 3.0)

SQL_AT_DROP_COLUMN_DEFAULT = <alter column> <drop column default clause> is supported (Intermediate level) (ODBC 3.0)

SQL_AT_DROP_COLUMN_RESTRICT = <drop column> RESTRICT is supported (FIPS Transitional level) (ODBC 3.0)

SQL_AT_DROP_TABLE_CONSTRAINT_CASCADE (ODBC 3.0)

SQL_AT_DROP_TABLE_CONSTRAINT_RESTRICT = <drop column> RESTRICT is supported (FIPS Transitional level) (ODBC 3.0)

SQL_AT_SET_COLUMN_DEFAULT = <alter column> <set column default clause> is supported (Intermediate level) (ODBC 3.0)

The following bits specify the support <constraint attributes> if specifying column or table constraints is supported (the SQL_AT_ADD_CONSTRAINT bit is set):

SQL_AT_CONSTRAINT_INITIALLY_DEFERRED (Full level) (ODBC 3.0)
SQL_AT_CONSTRAINT_INITIALLY_IMMEDIATE (Full level) (ODBC 3.0)
SQL_AT_CONSTRAINT_DEFERRABLE (Full level) (ODBC 3.0)
SQL_AT_CONSTRAINT_NON_DEFERRABLE (Full level) (ODBC 3.0)

SQL_AM_CONNECTION = Connection level asynchronous execution is supported. Either all statement handles associated with a given connection handle are in asynchronous mode, or all are in synchronous mode. A statement handle on a connection cannot be in asynchronous mode while another statement handle on the same connection is in synchronous mode, and vice versa.

SQL_AM_STATEMENT = Statement level asynchronous execution is supported. Some statement handles associated with a connection handle can be in asynchronous mode, while other statement handles on the same connection are in synchronous mode.

SQL_AM_NONE = Asynchronous mode is not supported.

SQL_BRC_ROLLED_UP = Row counts for consecutive INSERT, DELETE, or UPDATE statements are rolled up into one. If this bit is not set, then row counts are available for each individual statement.

SQL_BRC_PROCEDURES = Row counts, if any, are available when a batch is executed in a stored procedure. If row counts are available, they may be rolled up or individually available, depending on the SQL_BRC_ROLLED_UP bit.

SQL_BRC_EXPLICIT = Row counts, if any, are available when a batch is executed directly by calling SQLExecute or SQLExecDirect. If row counts are available, they may be rolled up or individually available, depending on the SQL_BRC_ROLLED_UP bit.

SQL_BS_SELECT_EXPLICIT = The driver supports explicit batches that can have result-set generating statements.

SQL_BS_ROW_COUNT_EXPLICIT = The driver supports explicit batches that can have row-count generating statements.

SQL_BS_SELECT_PROC = The driver supports explicit procedures that can have result-set generating statements.

SQL_BS_ROW_COUNT_PROC = The driver supports explicit procedures that can have row-count generating statements.

The following bitmasks are used in conjunction with the flag to determine through which options bookmarks persist:

SQL_BP_CLOSE = Bookmarks are valid after an application calls SQLFreeStmt with the SQL_CLOSE option, or SQLCloseCursor to close the cursor associated with a statement.

SQL_BP_DELETE = The bookmark for a row is valid after that row has been deleted.

SQL_BP_DROP = Bookmarks are valid after an application calls SQLFreeHandle with a HandleType of SQL_HANDLE_STMT to drop a statement.

SQL_BP_TRANSACTION = Bookmarks are valid after an application commits or rolls back a transaction.

SQL_BP_UPDATE = The bookmark for a row is valid after any column in that row has been updated, including key columns.

SQL_BP_OTHER_HSTMT = A bookmark associated with one statement can be used with another statement. Unless SQL_BP_CLOSE or SQL_BP_DROP is specified, the cursor on the first statement must be open.

SQL_CL_START
SQL_CL_END

For example, an Xbase driver returns SQL_CL_START because the directory (catalog) name is at the start of the table name, as in \EMPDATA\EMP.DBF. An ORACLE Server driver returns SQL_CL_END, because the catalog is at the end of the table name, as in ADMIN.EMP@EMPDATA.

An SQL92 Full level – conformant driver will always return SQL_CL_START. A value of 0 is returned if catalogs are not supported by the data source. To find out whether catalogs are supported, an application calls SQLGetInfo with the SQL_CATALOG_NAME information type.

This InfoType has been renamed for ODBC 3.0 from the ODBC 2.0 InfoType SQL_QUALIFIER_LOCATION.

An SQL92 Full level – conformant driver will always return “Y”.

An empty string is returned if catalogs are not supported by the data source. To find out whether catalogs are supported, an application calls SQLGetInfo with the SQL_CATALOG_NAME information type. An SQL92 Full level – conformant driver will always return “.”.

This InfoType has been renamed for ODBC 3.0 from the ODBC 2.0 InfoType SQL_QUALIFIER_NAME_SEPARATOR.

An empty string is returned if catalogs are not supported by the data source. To find out whether catalogs are supported, an application calls SQLGetInfo with the SQL_CATALOG_NAME information type. An SQL92 Full level – conformant driver will always return “catalog”.

This InfoType has been renamed for ODBC 3.0 from the ODBC 2.0 InfoType SQL_QUALIFIER_TERM.

The following bitmasks are used to determine where catalogs can be used:

SQL_CU_DML_STATEMENTS = Catalogs are supported in all Data Manipulation Language statements: SELECT, INSERT, UPDATE, DELETE, and, if supported, SELECT FOR UPDATE and positioned update and delete statements.

SQL_CU_PROCEDURE_INVOCATION = Catalogs are supported in the ODBC procedure invocation statement.

SQL_CU_TABLE_DEFINITION = Catalogs are supported in all table definition statements: CREATE TABLE, CREATE VIEW, ALTER TABLE, DROP TABLE, and DROP VIEW.

SQL_CU_INDEX_DEFINITION = Catalogs are supported in all index definition statements: CREATE INDEX and DROP INDEX.

SQL_CU_PRIVILEGE_DEFINITION = Catalogs are supported in all privilege definition statements: GRANT and REVOKE.

A value of 0 is returned if catalogs are not supported by the data source. To find out whether catalogs are supported, an application calls SQLGetInfo with the SQL_CATALOG_NAME information type. An SQL92 Full level – conformant driver will always return a bitmask with all of these bits set.

This InfoType has been renamed for ODBC 3.0 from the ODBC 2.0 InfoType SQL_QUALIFIER_USAGE.

A column alias is an alternate name that can be specified for a column in the select list by using an AS clause. An SQL92 Entry level – conformant driver will always return “Y”.

SQL_CB_NULL = Result is NULL valued.

SQL_CB_NON_NULL = Result is concatenation of non-NULL valued column or columns.

An SQL92 Entry level – conformant driver will always return SQL_CB_NULL.

For example, to find out if a data source supports the conversion of SQL_INTEGER data to the SQL_BIGINT data type, an application calls SQLGetInfo with the InfoType of SQL_CONVERT_INTEGER. The application performs an AND operation with the returned bitmask and SQL_CVT_BIGINT. If the resulting value is nonzero, the conversion is supported.

The following bitmasks are used to determine which conversions are supported:

SQL_CVT_BIGINT (ODBC 1.0)
SQL_CVT_BINARY (ODBC 1.0)
SQL_CVT_BIT (ODBC 1.0)
SQL_CVT_CHAR (ODBC 1.0)
SQL_CVT_DATE (ODBC 1.0)
SQL_CVT_DECIMAL (ODBC 1.0)
SQL_CVT_DOUBLE (ODBC 1.0)
SQL_CVT_FLOAT (ODBC 1.0)
SQL_CVT_INTEGER (ODBC 1.0)
SQL_CVT_INTERVAL_YEAR_MONTH (ODBC 3.0)
SQL_CVT_INTERVAL_DAY_TIME (ODBC 3.0)
SQL_CVT_LONGVARBINARY (ODBC 1.0)
SQL_CVT_LONGVARCHAR (ODBC 1.0)
SQL_CVT_NUMERIC (ODBC 1.0)
SQL_CVT_REAL ODBC 1.0)
SQL_CVT_SMALLINT (ODBC 1.0)
SQL_CVT_TIME (ODBC 1.0)
SQL_CVT_TIMESTAMP (ODBC 1.0)
SQL_CVT_TINYINT (ODBC 1.0)
SQL_CVT_VARBINARY (ODBC 1.0)
SQL_CVT_VARCHAR (ODBC 1.0)

The following bitmask is used to determine which conversion functions are supported:

SQL_FN_CVT_CAST
SQL_FN_CVT_CONVERT

SQL_CN_NONE = Correlation names are not supported.

SQL_CN_DIFFERENT = Correlation names are supported, but must differ from the names of the tables they represent.

SQL_CN_ANY = Correlation names are supported and can be any valid user-defined name.

An SQL92 Entry level – conformant driver will always return SQL_CN_ANY.

The following bitmasks are used to determine which clauses are supported:

SQL_CA_CREATE_ASSERTION

The following bits specify the supported constraint attribute if the ability to specify constraint attributes explicitly is supported (see the SQL_ALTER_TABLE and SQL_CREATE_TABLE information types):

SQL_CA_CONSTRAINT_INITIALLY_DEFERRED
SQL_CA_CONSTRAINT_INITIALLY_IMMEDIATE
SQL_CA_CONSTRAINT_DEFERRABLE
SQL_CA_CONSTRAINT_NON_DEFERRABLE

An SQL92 Full level – conformant driver will always return all of these options as supported. A return value of 0 means that the CREATE ASSERTION statement is not supported.

The following bitmasks are used to determine which clauses are supported:

SQL_CCS_CREATE_CHARACTER_SET
SQL_CCS_COLLATE_CLAUSE
SQL_CCS_LIMITED_COLLATION

An SQL92 Full level – conformant driver will always return all of these options as supported. A return value of 0 means that the CREATE CHARACTER SET statement is not supported.

The following bitmask is used to determine which clauses are supported:

SQL_CCOL_CREATE_COLLATION

An SQL92 Full level – conformant driver will always return this option as supported. A return value of 0 means that the CREATE COLLATION statement is not supported.

The following bitmasks are used to determine which clauses are supported:

SQL_CDO_CREATE_DOMAIN = The CREATE DOMAIN statement is supported. (Intermediate level)

SQL_CDO_CONSTRAINT_NAME_DEFINITION = <constraint name definition> is supported for naming domain constraints (Intermediate level).

The following bits specify the ability to create column constraints:
SQL_CDO_DEFAULT = Specifying domain constraints is supported (Intermediate level)
SQL_CDO_CONSTRAINT = Specifying domain defaults is supported (Intermediate level)
SQL_CDO_COLLATION = Specifying domain collation is supported (Full level)

The following bits specify the supported constraint attributes if specifying domain constraints is supported (SQL_CDO_DEFAULT is set):

SQL_CDO_CONSTRAINT_INITIALLY_DEFERRED (Full level)
SQL_CDO_CONSTRAINT_INITIALLY_IMMEDIATE (Full level)
SQL_CDO_CONSTRAINT_DEFERRABLE (Full level)
SQL_CDO_CONSTRAINT_NON_DEFERRABLE (Full level)

A return value of 0 means that the CREATE DOMAIN statement is not supported.

The following bitmasks are used to determine which clauses are supported:

SQL_CS_CREATE_SCHEMA
SQL_CS_AUTHORIZATION
SQL_CS_DEFAULT_CHARACTER_SET

An SQL92 Intermediate level – conformant driver will always return the SQL_CS_CREATE_SCHEMA and SQL_CS_AUTHORIZATION options as supported. These must also be supported at the SQL92 Entry level, but not necessarily as SQL statements. An SQL92 Full level – conformant driver will always return all of these options as supported.

The SQL92 or FIPS conformance level at which this feature needs to be supported is shown in parentheses next to each bitmask.

The following bitmasks are used to determine which clauses are supported:

SQL_CT_CREATE_TABLE = The CREATE TABLE statement is supported. (Entry level)

SQL_CT_TABLE_CONSTRAINT = Specifying table constraints is supported (FIPS Transitional level)

SQL_CT_CONSTRAINT_NAME_DEFINITION = The <constraint name definition> clause is supported for naming column and table constraints (Intermediate level)

The following bits specify the ability to create temporary tables:

SQL_CT_COMMIT_PRESERVE = Deleted rows are preserved on commit. (Full level)
SQL_CT_COMMIT_DELETE = Deleted rows are deleted on commit. (Full level)
SQL_CT_GLOBAL_TEMPORARY = Global temporary tables can be created. (Full level)
SQL_CT_LOCAL_TEMPORARY = Local temporary tables can be created. (Full level)

The following bits specify the ability to create column constraints:

SQL_CT_COLUMN_CONSTRAINT = Specifying column constraints is supported (FIPS Transitional level)
SQL_CT_COLUMN_DEFAULT = Specifying column defaults is supported (FIPS Transitional level)
SQL_CT_COLUMN_COLLATION = Specifying column collation is supported (Full level)

The following bits specify the supported constraint attributes if specifying column or table constraints is supported:

SQL_CT_CONSTRAINT_INITIALLY_DEFERRED (Full level)
SQL_CT_CONSTRAINT_INITIALLY_IMMEDIATE (Full level)
SQL_CT_CONSTRAINT_DEFERRABLE (Full level)
SQL_CT_CONSTRAINT_NON_DEFERRABLE (Full level)

The following bitmask is used to determine which clauses are supported:

SQL_CTR_CREATE_TRANSLATION

An SQL92 Full level – conformant driver will always return these options as supported. A return value of 0 means that the CREATE TRANSLATION statement is not supported.

The following bitmasks are used to determine which clauses are supported:

SQL_CV_CREATE_VIEW
SQL_CV_CHECK_OPTION
SQL_CV_CASCADED
SQL_CV_LOCAL

A return value of 0 means that the CREATE VIEW statement is not supported.

An SQL92 Entry level – conformant driver will always return the SQL_CV_CREATE_VIEW and SQL_CV_CHECK_OPTION options as supported.

An SQL92 Full level – conformant driver will always return all of these options as supported.

SQL_CB_DELETE = Close cursors and delete prepared statements. To use the cursor again, the application must reprepare and reexecute the statement.

SQL_CB_CLOSE = Close cursors. For prepared statements, the application can call SQLExecute on the statement without calling SQLPrepare again.

SQL_CB_PRESERVE = Preserve cursors in the same position as before the COMMIT operation. The application can continue to fetch data or it can close the cursor and reexecute the statement without repreparing it.

SQL_CB_DELETE = Close cursors and delete prepared statements. To use the cursor again, the application must reprepare and reexecute the statement.

SQL_CB_CLOSE = Close cursors. For prepared statements, the application can call SQLExecute on the statement without calling SQLPrepare again.

SQL_CB_PRESERVE = Preserve cursors in the same position as before the ROLLBACK operation. The application can continue to fetch data or it can close the cursor and reexecute the statement without repreparing it.

SQL_INSENSITIVE = All cursors on the statement handle show the result set without reflecting any changes made to it by any other cursor within the same transaction.

SQL_UNSPECIFIED = It is unspecified whether cursors on the statement handle make visible the changes made to a result set by another cursor within the same transaction. Cursors on the statement handle may make visible none, some, or all such changes.

SQL_SENSITIVE = Cursors are sensitive to changes made by other cursors within the same transaction. 

An SQL92 Entry level – conformant driver will always return the SQL_UNSPECIFIED option as supported.

An SQL92 Full level – conformant driver will always return the SQL_INSENSITIVE option as supported.

This characteristic pertains only to the data source itself; it is not a characteristic of the driver that enables access to the data source. A driver that is read/write can be used with a data source that is read-only. If a driver is read-only, all of its data sources must be read-only, and must return SQL_DATA_SOURCE_READ_ONLY.

Note In ODBC 3.x, the value returned for this InfoType can also be returned by calling SQLGetConnectAttr with an Attribute argument of SQL_ATTR_CURRENT_CATALOG.

A FIPS Transitional level – conformant driver will always return the “1” value in the bitmask for the bits listed below. A value of 0 means that SQL92 datetime literals are not supported.

The following bitmasks are used to determine which literals are supported:

SQL_DL_SQL92_DATE
SQL_DL_SQL92_TIME
SQL_DL_SQL92_TIMESTAMP
SQL_DL_SQL92_INTERVAL_YEAR
SQL_DL_SQL92_INTERVAL_MONTH
SQL_DL_SQL92_INTERVAL_DAY
SQL_DL_SQL92_INTERVAL_HOUR
SQL_DL_SQL92_INTERVAL_MINUTE
SQL_DL_SQL92_INTERVAL_SECOND
SQL_DL_SQL92_INTERVAL_YEAR_TO_MONTH
SQL_DL_SQL92_INTERVAL_DAY_TO_HOUR

SQL_DL_SQL92_INTERVAL_DAY_TO_MINUTE
SQL_DL_SQL92_INTERVAL_DAY_TO_SECOND
SQL_DL_SQL92_INTERVAL_HOUR_TO_MINUTE
SQL_DL_SQL92_INTERVAL_HOUR_TO_SECOND
SQL_DL_SQL92_INTERVAL_MINUTE_TO_SECOND

SQL_DI_CREATE_INDEX
SQL_DI_DROP_INDEX

Dirty Read  Transaction 1 changes a row. Transaction 2 reads the changed row before transaction 1 commits the change. If transaction 1 rolls back the change, transaction 2 will have read a row that is considered to have never existed.

Nonrepeatable Read  Transaction 1 reads a row. Transaction 2 updates or deletes that row and commits this change. If transaction 1 attempts to reread the row, it will receive different row values or discover that the row has been deleted.

Phantom  Transaction 1 reads a set of rows that satisfy some search criteria. Transaction 2 generates one or more rows (either through inserts or updates) that match the search criteria. If transaction 1 reexecutes the statement that reads the rows, it receives a different set of rows.

If the data source supports transactions, the driver returns one of the following bitmasks:

SQL_TXN_READ_UNCOMMITTED = Dirty reads, nonrepeatable reads, and phantoms are possible.

SQL_TXN_READ_COMMITTED = Dirty reads are not possible. Nonrepeatable reads and phantoms are possible.

SQL_TXN_REPEATABLE_READ = Dirty reads and nonrepeatable reads are not possible. Phantoms are possible.

SQL_TXN_SERIALIZABLE = Transactions are serializable. Serializable transactions do not allow dirty reads, nonrepeatable reads, or phantoms.

An SQL92 Full level – conformant driver will usually return “Y” because it will support the DESCRIBE INPUT statement. Because this does not directly specify the underlying SQL support, however, describing parameters may not be supported, even in a SQL92 Full level – conformant driver.

The first set of two digits is the major ODBC version, as given by the constant SQL_SPEC_MAJOR.

The second set of two digits is the minor ODBC version, as given by the constant SQL_SPEC_MINOR.

The third set of four digits is the Driver Manager major build number.

The last set of four digits is the Driver Manager minor build number.

These information types are implemented by the Driver Manager alone.

The application should make a copy of the Driver Manager’s descriptor handle before calling SQLGetInfo with this information type, to ensure that the handle is not overwritten on output.

This information type is implemented by the Driver Manager alone.

This information type is implemented by the Driver Manager alone.

The application should make a copy of the Driver Manager’s statement handle before calling SQLGetInfo with this information type, to ensure that the handle is not overwritten on output.

This information type is implemented by the Driver Manager alone.

The following bitmask is used to determine which clauses are supported:

SQL_DA_DROP_ASSERTION

An SQL92 Full level – conformant driver will always return this option as supported.

The following bitmask is used to determine which clauses are supported:

SQL_DCS_DROP_CHARACTER_SET

An SQL92 Full level – conformant driver will always return this option as supported.

The following bitmask is used to determine which clauses are supported:

SQL_DC_DROP_COLLATION

An SQL92 Full level – conformant driver will always return this option as supported.

The following bitmasks are used to determine which clauses are supported:

SQL_DD_DROP_DOMAIN
SQL_DD_CASCADE
SQL_DD_RESTRICT

An SQL92 Intermediate level – conformant driver will always return all of these options as supported.

The following bitmasks are used to determine which clauses are supported:

SQL_DS_DROP_SCHEMA
SQL_DS_CASCADE
SQL_DS_RESTRICT

An SQL92 Intermediate level – conformant driver will always return all of these options as supported.

The following bitmasks are used to determine which clauses are supported:

SQL_DT_DROP_TABLE
SQL_DT_CASCADE
SQL_DT_RESTRICT

An FIPS Transitional level – conformant driver will always return all of these options as supported.

The following bitmask is used to determine which clauses are supported:

SQL_DTR_DROP_TRANSLATION

An SQL92 Full level – conformant driver will always return this option as supported.

The following bitmasks are used to determine which clauses are supported:

SQL_DV_DROP_VIEW
SQL_DV_CASCADE
SQL_DV_RESTRICT

An FIPS Transitional level – conformant driver will always return all of these options as supported.

The following bitmasks are used to determine which attributes are supported:

SQL_CA1_NEXT = A FetchOrientation argument of SQL_FETCH_NEXT is supported in a call to SQLFetchScroll when the cursor is a dynamic cursor.

SQL_CA1_ABSOLUTE = FetchOrientation arguments of SQL_FETCH_FIRST, SQL_FETCH_LAST, and SQL_FETCH_ABSOLUTE are supported in a call to SQLFetchScroll when the cursor is a dynamic cursor. (The rowset that will be fetched is independent of the current cursor position.)

SQL_CA1_RELATIVE = FetchOrientation arguments of SQL_FETCH_PRIOR and SQL_FETCH_RELATIVE are supported in a call to SQLFetchScroll when the cursor is a dynamic cursor. (The rowset that will be fetched is dependent of the current cursor position. Note that this is separated from SQL_FETCH_NEXT because in a forward-only cursor, only SQL_FETCH_NEXT is supported.)

SQL_CA1_BOOKMARK = A FetchOrientation argument of SQL_FETCH_BOOKMARK is supported in a call to SQLFetchScroll when the cursor is a dynamic cursor.

SQL_CA1_LOCK_EXCLUSIVE = A LockType argument of SQL_LOCK_EXCLUSIVE is supported in a call to SQLSetPos when the cursor is a dynamic cursor.

SQL_CA1_LOCK_NO_CHANGE = A LockType argument of SQL_LOCK_NO_CHANGE is supported in a call to SQLSetPos when the cursor is a dynamic cursor.

SQL_CA1_LOCK_UNLOCK = A LockType argument of SQL_LOCK_UNLOCK is supported in a call to SQLSetPos when the cursor is a dynamic cursor.

SQL_CA1_POS_POSITION = An Operation argument of SQL_POSITION is supported in a call to SQLSetPos when the cursor is a dynamic cursor.

SQL_CA1_POS_UPDATE = An Operation argument of SQL_UPDATE is supported in a call to SQLSetPos when the cursor is a dynamic cursor.

SQL_CA1_POS_DELETE = An Operation argument of SQL_DELETE is supported in a call to SQLSetPos when the cursor is a dynamic cursor.

SQL_CA1_POS_REFRESH = An Operation argument of SQL_REFRESH is supported in a call to SQLSetPos when the cursor is a dynamic cursor.

SQL_CA1_POSITIONED_UPDATE = An UPDATE WHERE CURRENT OF SQL statement is supported when the cursor is a dynamic cursor. (An SQL92 Entry level – conformant driver will always return this option as supported.)

SQL_CA1_POSITIONED_DELETE = A DELETE WHERE CURRENT OF SQL statement is supported when the cursor is a dynamic cursor. (An SQL92 Entry level – conformant driver will always return this option as supported.)

SQL_CA1_SELECT_FOR_UPDATE = A SELECT FOR UPDATE SQL statement is supported when the cursor is a dynamic cursor. (An SQL92 Entry level – conformant driver will always return this option as supported.)

SQL_CA1_BULK_ADD = An Operation argument of SQL_ADD is supported in a call to SQLBulkOperations when the cursor is a dynamic cursor.

SQL_CA1_BULK_UPDATE_BY_BOOKMARK = An Operation argument of SQL_UPDATE_BY_BOOKMARK is supported in a call to SQLBulkOperations when the cursor is a dynamic cursor.

SQL_CA1_BULK_DELETE_BY_BOOKMARK = An Operation argument of SQL_DELETE_BY_BOOKMARK is supported in a call to SQLBulkOperations when the cursor is a dynamic cursor.

SQL_CA1_BULK_FETCH_BY_BOOKMARK = An Operation argument of SQL_FETCH_BY_BOOKMARK is supported in a call to SQLBulkOperations when the cursor is a dynamic cursor.

An SQL92 Intermediate level – conformant driver will usually return the SQL_CA1_NEXT, SQL_CA1_ABSOLUTE, and SQL_CA1_RELATIVE options as supported, because it supports scrollable cursors through the embedded SQL FETCH statement. Because this does not directly determine the underlying SQL support, however, scrollable cursors may not be supported, even for an SQL92 Intermediate level – conformant driver.

The following bitmasks are used to determine which attributes are supported:

SQL_CA2_READ_ONLY_CONCURRENCY = A read-only dynamic cursor, in which no updates are allowed, is supported. (The SQL_ATTR_CONCURRENCY statement attribute can be SQL_CONCUR_READ_ONLY for a dynamic cursor).

SQL_CA2_LOCK_CONCURRENCY = A dynamic cursor that uses the lowest level of locking sufficient to ensure that the row can be updated is supported. (The SQL_ATTR_CONCURRENCY statement attribute can be SQL_CONCUR_LOCK for a dynamic cursor.) These locks must be consistent with the transaction isolation level set by the SQL_ATTR_TXN_ISOLATION connection attribute.

SQL_CA2_OPT_ROWVER_CONCURRENCY = A dynamic cursor that uses the optimistic concurrency control comparing row versions is supported. (The SQL_ATTR_CONCURRENCY statement attribute can be SQL_CONCUR_ROWVER for a dynamic cursor.)

SQL_CA2_OPT_VALUES_CONCURRENCY = A dynamic cursor that uses the optimistic concurrency control comparing values is supported. (The SQL_ATTR_CONCURRENCY statement attribute can be SQL_CONCUR_VALUES for a dynamic cursor.)

SQL_CA2_SENSITIVITY_ADDITIONS = Added rows are visible to a dynamic cursor; the cursor can scroll to those rows. (Where these rows are added to the cursor is driver-dependent.)

SQL_CA2_SENSITIVITY_DELETIONS = Deleted rows are no longer available to a dynamic cursor, and do not leave a “hole” in the result set; after the dynamic cursor scrolls from a deleted row, it cannot return to that row.

SQL_CA2_SENSITIVITY_UPDATES = Updates to rows are visible to a dynamic cursor; if the dynamic cursor scrolls from and returns to an updated row, the data returned by the cursor is the updated data, not the original data.

SQL_CA2_MAX_ROWS_SELECT = The SQL_ATTR_MAX_ROWS statement attribute affects SELECT statements when the cursor is a dynamic cursor.

SQL_CA2_MAX_ROWS_INSERT = The SQL_ATTR_MAX_ROWS statement attribute affects INSERT statements when the cursor is a dynamic cursor.

SQL_CA2_MAX_ROWS_DELETE = The SQL_ATTR_MAX_ROWS statement attribute affects DELETE statements when the cursor is a dynamic cursor.

SQL_CA2_MAX_ROWS_UPDATE = The SQL_ATTR_MAX_ROWS statement attribute affects UPDATE statements when the cursor is a dynamic cursor.

SQL_CA2_MAX_ROWS_CATALOG = The SQL_ATTR_MAX_ROWS statement attribute affects CATALOG result sets when the cursor is a dynamic cursor.

SQL_CA2_MAX_ROWS_AFFECTS_ALL = The SQL_ATTR_MAX_ROWS statement attribute affects SELECT, INSERT, DELETE, and UPDATE statements, and CATALOG result sets, when the cursor is a dynamic cursor.

SQL_CA2_CRC_EXACT = The exact row count is available in the SQL_DIAG_CURSOR_ROW_COUNT diagnostic field when the cursor is a dynamic cursor.

SQL_CA2_CRC_APPROXIMATE = An approximate row count is available in the SQL_DIAG_CURSOR_ROW_COUNT diagnostic field when the cursor is a dynamic cursor.

SQL_CA2_SIMULATE_NON_UNIQUE = The driver does not guarantee that simulated positioned update or delete statements will affect only one row when the cursor is a dynamic cursor; it is the application’s responsibility to guarantee this. (If a statement affects more than one row, SQLExecute or SQLExecDirect returns SQLSTATE 01001 (Cursor operation conflict).) To set this behavior, the application calls SQLSetStmtAttr with the SQL_ATTR_SIMULATE_CURSOR attribute set to SQL_SC_NON_UNIQUE.

SQL_CA2_SIMULATE_TRY_UNIQUE = The driver attempts to guarantee that simulated positioned update or delete statements will affect only one row when the cursor is a dynamic cursor. The driver always executes such statements, even if they might affect more than one row, such as when there is no unique key. (If a statement affects more than one row, SQLExecute or SQLExecDirect returns SQLSTATE 01001 (Cursor operation conflict).) To set this behavior, the application calls SQLSetStmtAttr with the SQL_ATTR_SIMULATE_CURSOR attribute set to SQL_SC_TRY_UNIQUE.

SQL_CA2_SIMULATE_UNIQUE = The driver guarantees that simulated positioned update or delete statements will affect only one row when the cursor is a dynamic cursor. If the driver cannot guarantee this for a given statement, SQLExecDirect or SQLPrepare return SQLSTATE 01001 (Cursor operation conflict). To set this behavior, the application calls SQLSetStmtAttr with the SQL_ATTR_SIMULATE_CURSOR attribute set to SQL_SC_UNIQUE.

SQL_FILE_NOT_SUPPORTED = The driver is not a single-tier driver. For example, an ORACLE driver is a two-tier driver.

SQL_FILE_TABLE = A single-tier driver treats files in a data source as tables. For example, an Xbase driver treats each Xbase file as a table.

SQL_FILE_CATALOG = A single-tier driver treats files in a data source as a catalog. For example, a Microsoft Access driver treats each Microsoft Access file as a complete database.

An application might use this to determine how users will select data. For example, Xbase users often think of data as stored in files, while ORACLE and Microsoft Access users generally think of data as stored in tables.

When a user selects an Xbase data source, the application could display the Windows File Open common dialog box; when the user selects a Microsoft Access or ORACLE data source, the application could display a custom Select Table dialog box.

The following bitmasks are used to determine which attributes are supported:

SQL_CA1_NEXT
SQL_CA1_LOCK_EXCLUSIVE
SQL_CA1_LOCK_NO_CHANGE
SQL_CA1_LOCK_UNLOCK
SQL_CA1_POS_POSITION
SQL_CA1_POS_UPDATE
SQL_CA1_POS_DELETE
SQL_CA1_POS_REFRESH
SQL_CA1_POSITIONED_UPDATE
SQL_CA1_POSITIONED_DELETE
SQL_CA1_SELECT_FOR_UPDATE
SQL_CA1_BULK_ADD
SQL_CA1_BULK_UPDATE_BY_BOOKMARK
SQL_CA1_BULK_DELETE_BY_BOOKMARK
SQL_CA1_BULK_FETCH_BY_BOOKMARK

For descriptions of these bitmasks, see SQL_DYNAMIC_CURSOR_ATTRIBUTES1 (and substitute “forward-only cursor” for “dynamic cursor” in the descriptions).

The following bitmasks are used to determine which attributes are supported:

SQL_CA2_READ_ONLY_CONCURRENCY
SQL_CA2_LOCK_CONCURRENCY
SQL_CA2_OPT_ROWVER_CONCURRENCY
SQL_CA2_OPT_VALUES_CONCURRENCY
SQL_CA2_SENSITIVITY_ADDITIONS
SQL_CA2_SENSITIVITY_DELETIONS
SQL_CA2_SENSITIVITY_UPDATES
SQL_CA2_MAX_ROWS_SELECT
SQL_CA2_MAX_ROWS_INSERT
SQL_CA2_MAX_ROWS_DELETE
SQL_CA2_MAX_ROWS_UPDATE
SQL_CA2_MAX_ROWS_CATALOG
SQL_CA2_MAX_ROWS_AFFECTS_ALL
SQL_CA2_CRC_EXACT
SQL_CA2_CRC_APPROXIMATE
SQL_CA2_SIMULATE_NON_UNIQUE
SQL_CA2_SIMULATE_TRY_UNIQUE
SQL_CA2_SIMULATE_UNIQUE

For descriptions of these bitmasks, see SQL_DYNAMIC_CURSOR_ATTRIBUTES2 (and substitute “forward-only cursor” for “dynamic cursor” in the descriptions).

The following bitmasks are used in conjunction with the flag to determine what common extensions the driver supports for SQLGetData:

SQL_GD_ANY_COLUMN = SQLGetData can be called for any unbound column, including those before the last bound column. Note that the columns must be called in order of ascending column number unless SQL_GD_ANY_ORDER is also returned.

SQL_GD_ANY_ORDER = SQLGetData can be called for unbound columns in any order. Note that SQLGetData can only be called for columns after the last bound column unless SQL_GD_ANY_COLUMN is also returned.

SQL_GD_BLOCK = SQLGetData can be called for an unbound column in any row in a block (where the rowset size is greater than 1) of data after positioning to that row with SQLSetPos.

SQL_GD_BOUND = SQLGetData can be called for bound columns as well as unbound columns. A driver cannot return this value unless it also returns SQL_GD_ANY_COLUMN.

SQLGetData is only required to return data from unbound columns that occur after the last bound column, are called in order of increasing column number, and are not in a row in a block of rows.

If a driver supports bookmarks (either fixed- or variable-length), it must support calling SQLGetData on column 0. This support is required regardless of what the driver returns for a call to SQLGetInfo with the SQL_GETDATA_EXTENSIONS InfoType.

SQL_GB_COLLATE = A COLLATE clause can be specified at the end of each grouping column. (ODBC 3.0)

SQL_GB_NOT_SUPPORTED = GROUP BY clauses are not supported. (ODBC 2.0)

SQL_GB_GROUP_BY_EQUALS_SELECT = The GROUP BY clause must contain all non-aggregated columns in the select list. It cannot contain any other columns. For example, SELECT DEPT, MAX(SALARY) FROM EMPLOYEE GROUP BY DEPT. (ODBC 2.0)

SQL_GB_GROUP_BY_CONTAINS_SELECT = The GROUP BY clause must contain all non-aggregated columns in the select list. It can contain columns that are not in the select list. For example, SELECT DEPT, MAX(SALARY) FROM EMPLOYEE GROUP BY DEPT, AGE. (ODBC 2.0)

SQL_GB_NO_RELATION = The columns in the GROUP BY clause and the select list are not related. The meaning of non-grouped, non-aggregated columns in the select list is data source – dependent. For example, SELECT DEPT, SALARY FROM EMPLOYEE GROUP BY DEPT, AGE. (ODBC 2.0)

An SQL92 Entry level – conformant driver will always return the SQL_GB_GROUP_BY_EQUALS_SELECT option as supported. An SQL92 Full level – conformant driver will always return the SQL_GB_COLLATE option as supported. If none of the options is supported, the GROUP BY clause is not supported by the data source.

SQL_IC_UPPER = Identifiers in SQL are not case-sensitive and are stored in uppercase in system catalog.

SQL_IC_LOWER = Identifiers in SQL are not case-sensitive and are stored in lowercase in system catalog.

SQL_IC_SENSITIVE = Identifiers in SQL are case-sensitive and are stored in mixed case in system catalog.

SQL_IC_MIXED = Identifiers in SQL are not case-sensitive and are stored in mixed case in system catalog.

Because identifiers in SQL92 are never case-sensitive, a driver that conforms strictly to SQL92 (any level) will never return the SQL_IC_SENSITIVE option as supported.

This character string can also be used for quoting catalog function arguments when the connection attribute SQL_ATTR_METADATA_ID is set to SQL_TRUE.

Because the identifier quote character in SQL92 is the double quotation mark (“), a driver that conforms strictly to SQL92 will always return the double quotation mark character.

SQL_IK_NONE = None of the keywords is supported.

SQL_IK_ASC = ASC keyword is supported.

SQL_IK_DESC = DESC keyword is supported.

SQL_IK_ALL = All keywords are supported.

To see if the CREATE INDEX statement is supported, an application calls SQLGetInfo with the SQL_DLL_INDEX information type.

The SQL92 or FIPS conformance level at which this feature needs to be supported is shown in parentheses next to each bitmask.

The following bitmasks are used to determine which views are supported:

SQL_ISV_ASSERTIONS = Identifies the catalog’s assertions that are owned by a given user. (Full level)

SQL_ISV_CHARACTER_SETS = Identifies the catalog’s character sets that are accessible to a given user. (Intermediate level)

SQL_ISV_CHECK_CONSTRAINTS = Identifies the CHECK constraints that are owned by a given user. (Intermediate level)

SQL_ISV_COLLATIONS = Identifies the character collations for the catalog that are accessible to a given user. (Full level)

SQL_ISV_COLUMN_DOMAIN_USAGE = Identifies columns for the catalog that are dependent on domains defined in the catalog and are owned by a given user. (Intermediate level)

SQL_ISV_COLUMN_PRIVILEGES = Identifies the privileges on columns of persistent tables that are available to or granted by a given user. (FIPS Transitional level)

SQL_ISV_COLUMNS = Identifies the columns of persistent tables that are accessible to a given user. (FIPS Transitional level)

SQL_ISV_CONSTRAINT_COLUMN_USAGE = Similar to CONSTRAINT_TABLE_USAGE view, columns are identified for the various constraints that are owned by a given user. (Intermediate level)

SQL_ISV_CONSTRAINT_TABLE_USAGE = Identifies the tables that are used by constraints (referential, unique, and assertions), and are owned by a given user. (Intermediate level)

SQL_ISV_DOMAIN_CONSTRAINTS = Identifies the domain constraints (of the domains in the catalog) that are accessible to a given user. (Intermediate level)

SQL_ISV_DOMAINS = Identifies the domains defined in a catalog that are accessible to the user. (Intermediate level)

SQL_ISV_KEY_COLUMN_USAGE = Identifies columns defined in the catalog that are constrained as keys by a given user. (Intermediate level)

SQL_ISV_REFERENTIAL_CONSTRAINTS = Identifies the referential constraints that are owned by a given user. (Intermediate level)

SQL_ISV_SCHEMATA = Identifies the schemas that are owned by a given user. (Intermediate level)

SQL_ISV_SQL_LANGUAGES = Identifies the SQL conformance levels, options, and dialects supported by the SQL implementation. (Intermediate level)

SQL_ISV_TABLE_CONSTRAINTS = Identifies the table constraints that are owned by a given user. (Intermediate level)

SQL_ISV_TABLE_PRIVILEGES = Identifies the privileges on persistent tables that are available to or granted by a given user. (FIPS Transitional level)

SQL_ISV_TABLES = Identifies the persistent tables defined in a catalog that are accessible to a given user. (FIPS Transitional level)

SQL_ISV_TRANSLATIONS = Identifies character translations for the catalog that are accessible to a given user. (Full level)

SQL_ISV_USAGE_PRIVILEGES = Identifies the USAGE privileges on catalog objects that are available to or owned by a given user. (FIPS Transitional level)

SQL_ISV_VIEW_TABLE_USAGE = Identifies the tables on which the catalog’s views that are owned by a given user are dependent. (Intermediate level)

SQL_ISV_VIEWS = Identifies the viewed tables defined in this catalog that are accessible to a given user. (FIPS Transitional level)

SQL_IS_INSERT_LITERALS

SQL_IS_INSERT_SEARCHED

SQL_IS_SELECT_INTO

An SQL92 Entry level – conformant driver will always return all of these options as supported.

This InfoType has been renamed for ODBC 3.0 from the ODBC 2.0 InfoType SQL_ODBC_SQL_OPT_IEF.

The following bitmasks are used to determine which attributes are supported:

SQL_CA1_NEXT
SQL_CA1_ABSOLUTE
SQL_CA1_RELATIVE
SQL_CA1_BOOKMARK
SQL_CA1_LOCK_EXCLUSIVE
SQL_CA1_LOCK_NO_CHANGE
SQL_CA1_LOCK_UNLOCK
SQL_CA1_POS_POSITION
SQL_CA1_POS_UPDATE
SQL_CA1_POS_DELETE
SQL_CA1_POS_REFRESH
SQL_CA1_POSITIONED_UPDATE
SQL_CA1_POSITIONED_DELETE
SQL_CA1_SELECT_FOR_UPDATE
SQL_CA1_BULK_ADD
SQL_CA1_BULK_UPDATE_BY_BOOKMARK
SQL_CA1_BULK_DELETE_BY_BOOKMARK
SQL_CA1_BULK_FETCH_BY_BOOKMARK

For descriptions of these bitmasks, see SQL_DYNAMIC_CURSOR_ATTRIBUTES1 (and substitute “keyset-driven cursor” for “dynamic cursor” in the descriptions).

An SQL92 Intermediate level – conformant driver will usually return the SQL_CA1_NEXT, SQL_CA1_ABSOLUTE, and SQL_CA1_RELATIVE options as supported, because it supports scrollable cursors through the embedded SQL FETCH statement. Because this does not directly determine the underlying SQL support, however, scrollable cursors may not be supported, even for an SQL92 Intermediate level – conformant driver.

The following bitmasks are used to determine which attributes are supported:

SQL_CA2_READ_ONLY_CONCURRENCY
SQL_CA2_LOCK_CONCURRENCY
SQL_CA2_OPT_ROWVER_CONCURRENCY
SQL_CA2_OPT_VALUES_CONCURRENCY
SQL_CA2_SENSITIVITY_ADDITIONS
SQL_CA2_SENSITIVITY_DELETIONS
SQL_CA2_SENSITIVITY_UPDATES
SQL_CA2_MAX_ROWS_SELECT
SQL_CA2_MAX_ROWS_INSERT
SQL_CA2_MAX_ROWS_DELETE
SQL_CA2_MAX_ROWS_UPDATE
SQL_CA2_MAX_ROWS_CATALOG
SQL_CA2_MAX_ROWS_AFFECTS_ALL
SQL_CA2_CRC_EXACT
SQL_CA2_CRC_APPROXIMATE
SQL_CA2_SIMULATE_NON_UNIQUE
SQL_CA2_SIMULATE_TRY_UNIQUE
SQL_CA2_SIMULATE_UNIQUE

For descriptions of these bitmasks, see SQL_DYNAMIC_CURSOR_ATTRIBUTES1 (and substitute “keyset-driven cursor” for “dynamic cursor” in the descriptions).

For a list of ODBC keywords, see “List of Reserved Keywords” in Appendix C, “SQL Grammar.” The #define value SQL_ODBC_KEYWORDS contains a comma-separated list of ODBC keywords.

An FIPS Full level – conformant driver will return at least 128.

This InfoType has been renamed for ODBC 3.0 from the ODBC 2.0 InfoType SQL_MAX_QUALIFIER_NAME_LEN.

An FIPS Entry level – conformant driver will return at least 18. An FIPS Intermediate level – conformant driver will return at least 128.

An FIPS Entry level – conformant driver will return at least 6. An FIPS Intermediate level – conformant driver will return at least 15.

An FIPS Entry level – conformant driver will return at least 6. An FIPS Intermediate level – conformant driver will return at least 15.

An FIPS Entry level – conformant driver will return at least 100. An FIPS Intermediate level – conformant driver will return at least 250.

An FIPS Entry level – conformant driver will return at least 100. An FIPS Intermediate level – conformant driver will return at least 250.

This InfoType has been renamed for ODBC 3.0 from the ODBC 2.0 InfoType SQL_ACTIVE_STATEMENTS.

An FIPS Entry level – conformant driver will return at least 18. An FIPS Intermediate level – conformant driver will return at least 128.

This InfoType has been renamed for ODBC 3.0 from the ODBC 2.0 InfoType SQL_ACTIVE_CONNECTIONS.

An FIPS Entry level – conformant driver will return at least 18. An FIPS Intermediate level – conformant driver will return at least 128.

An FIPS Entry level – conformant driver will return at least 2,000. An FIPS Intermediate level – conformant driver will return at least 8,000.

An FIPS Entry level – conformant driver will return at least 18. An FIPS Intermediate level – conformant driver will return at least 128.

This InfoType has been renamed for ODBC 3.0 from the ODBC 2.0 InfoType SQL_MAX_OWNER_NAME_LEN.

An FIPS Entry level – conformant driver will return at least 18. An FIPS Intermediate level – conformant driver will return at least 128.

An FIPS Entry level – conformant driver will return at least 15. An FIPS Intermediate level – conformant driver will return at least 50.

For more information on multiple result sets, see “Multiple Results” in Chapter 11, “Retrieving Results (Advanced).”

The information returned for this information type does not apply in the case of distributed transactions.

SQL_NNC_NULL = All columns must be nullable.

SQL_NNC_NON_NULL = Columns cannot be nullable (the data source supports the NOT NULL column constraint in CREATE TABLE statements).

An SQL92 Entry level – conformant driver will return SQL_NNC_NON_NULL.

SQL_NC_END = NULLs are sorted at the end of the result set, regardless of the ASC or DESC keywords.

SQL_NC_HIGH = NULLs are sorted at the high end of the result set, depending on the ASC or DESC keywords.

SQL_NC_LOW = NULLs are sorted at the low end of the result set, depending on the ASC or DESC keywords.

SQL_NC_START = NULLs are sorted at the start of the result set, regardless of the ASC or DESC keywords.

The information type was introduced in ODBC 1.0; each bitmask is labeled with the version in which it was introduced.

The following bitmasks are used to determine which numeric functions are supported:

SQL_FN_NUM_ABS (ODBC 1.0)
SQL_FN_NUM_ACOS (ODBC 1.0)
SQL_FN_NUM_ASIN (ODBC 1.0)
SQL_FN_NUM_ATAN (ODBC 1.0)
SQL_FN_NUM_ATAN2 (ODBC 1.0)
SQL_FN_NUM_CEILING (ODBC 1.0)
SQL_FN_NUM_COS (ODBC 1.0)
SQL_FN_NUM_COT (ODBC 1.0)
SQL_FN_NUM_DEGREES (ODBC 2.0)
SQL_FN_NUM_EXP (ODBC 1.0)
SQL_FN_NUM_FLOOR (ODBC 1.0)
SQL_FN_NUM_LOG (ODBC 1.0)
SQL_FN_NUM_LOG10 (ODBC 2.0)
SQL_FN_NUM_MOD (ODBC 1.0)
SQL_FN_NUM_PI (ODBC 1.0)
SQL_FN_NUM_POWER (ODBC 2.0)
SQL_FN_NUM_RADIANS (ODBC 2.0)
SQL_FN_NUM_RAND (ODBC 1.0)
SQL_FN_NUM_ROUND (ODBC 2.0)
SQL_FN_NUM_SIGN (ODBC 1.0)
SQL_FN_NUM_SIN (ODBC 1.0)
SQL_FN_NUM_SQRT (ODBC 1.0)
SQL_FN_NUM_TAN (ODBC 1.0)
SQL_FN_NUM_TRUNCATE (ODBC 2.0)

SQL_OIC_CORE: The minimum level that all ODBC drivers are expected to conform to. This level includes basic interface elements such as connection functions; functions for preparing and executing an SQL statement; basic result set metadata functions; basic catalog functions; and so on.

SQL_OIC_LEVEL1: A level including the core standards compliance level functionality, plus scrollable cursors, bookmarks, positioned updates and deletes, and so on.

SQL_OIC_LEVEL2: A level including level 1 standards compliance level functionality, plus advanced features such as sensitive cursors; update, delete, and refresh by bookmarks; stored procedure support; catalog functions for primary and foreign keys; multi-catalog support; and so on.

For more information, see “Interface Conformance Levels” in Chapter 4, “ODBC Fundamentals.”

SQL_OJ_LEFT = Left outer joins are supported.

SQL_OJ_RIGHT = Right outer joins are supported.

SQL_OJ_FULL = Full outer joins are supported.

SQL_OJ_NESTED = Nested outer joins are supported.

SQL_OJ_NOT_ORDERED = The column names in the ON clause of the outer join do not have to be in the same order as their respective table names in the OUTER JOIN clause.

SQL_OJ_INNER = The inner table (the right table in a left outer join or the left table in a right outer join) can also be used in an inner join. This does not apply to full outer joins, which do not have an inner table.

SQL_OJ_ALL_COMPARISON_OPS = The comparison operator in the ON clause can be any of the ODBC comparison operators. If this bit is not set, only the equals (=) comparison operator can be used in outer joins.

If none of these options is returned as supported, no outer join clause is supported.

For information on the support of relational join operators in a SELECT statement, as defined by SQL92, see SQL_SQL92_RELATIONAL_JOIN_OPERATORS.

SQL_PARC_BATCH = Individual row counts are available for each set of parameters. This is conceptually equivalent to the driver generating a batch of SQL statements, one for each parameter set in the array. Extended error information can be retrieved by using the SQL_PARAM_STATUS_PTR descriptor field.

SQL_PARC_NO_BATCH = There is only one row count available, which is the cumulative row count resulting from the execution of the statement for the entire array of parameters. This is conceptually equivalent to treating the statement along with the entire parameter array as one atomic unit. Errors are handled the same as if one statement were executed.

SQL_PAS_BATCH = There is one result set available per set of parameters. This is conceptually equivalent to the driver generating a batch of SQL statements, one for each parameter set in the array.

SQL_PAS_NO_BATCH = There is only one result set available, which represents the cumulative result set resulting from the execution of the statement for the entire array of parameters. This is conceptually equivalent to treating the statement along with the entire parameter array as one atomic unit.

SQL_PAS_NO_SELECT = A driver does not allow a result-set generating statement to be executed with an array of parameters.

SQL_IC_UPPER = Quoted identifiers in SQL are not case-sensitive and are stored in uppercase in the system catalog.

SQL_IC_LOWER = Quoted identifiers in SQL are not case-sensitive and are stored in lowercase in the system catalog.

SQL_IC_SENSITIVE = Quoted identifiers in SQL are case-sensitive and are stored in mixed case in the system catalog. (Note that in an SQL92-compliant database, quoted identifiers are always case-sensitive.)

SQL_IC_MIXED = Quoted identifiers in SQL are not case-sensitive and are stored in mixed case in the system catalog.

An SQL92 Entry level – conformant driver will always return SQL_IC_SENSITIVE.

The character string can be returned in upper, lower, or mixed case.

An SQL92 Entry level – conformant driver will always return “schema”.

This InfoType has been renamed for ODBC 3.0 from the ODBC 2.0 InfoType SQL_OWNER_TERM.

SQL_SU_DML_STATEMENTS = Schemas are supported in all Data Manipulation Language statements: SELECT, INSERT, UPDATE, DELETE, and, if supported, SELECT FOR UPDATE and positioned update and delete statements.

SQL_SU_PROCEDURE_INVOCATION = Schemas are supported in the ODBC procedure invocation statement.

SQL_SU_TABLE_DEFINITION = Schemas are supported in all table definition statements: CREATE TABLE, CREATE VIEW, ALTER TABLE, DROP TABLE, and DROP VIEW.

SQL_SU_INDEX_DEFINITION = Schemas are supported in all index definition statements: CREATE INDEX and DROP INDEX.

SQL_SU_PRIVILEGE_DEFINITION = Schemas are supported in all privilege definition statements: GRANT and REVOKE.

An SQL92 Entry level – conformant driver will always return the SQL_SU_DML_STATEMENTS, SQL_SU_TABLE_DEFINITION, and SQL_SU_PRIVILEGE_DEFINITION options as supported.

This InfoType has been renamed for ODBC 3.0 from the ODBC 2.0 InfoType SQL_OWNER_USAGE.

The information type was introduced in ODBC 1.0; each bitmask is labeled with the version in which it was introduced.

The following bitmasks are used to determine which options are supported:

SQL_SO_FORWARD_ONLY = The cursor only scrolls forward. (ODBC 1.0)

SQL_SO_STATIC = The data in the result set is static. (ODBC 2.0)

SQL_SO_KEYSET_DRIVEN = The driver saves and uses the keys for every row in the result set. (ODBC 1.0)

SQL_SO_DYNAMIC = The driver keeps the keys for every row in the rowset (the keyset size is the same as the rowset size). (ODBC 1.0)

SQL_SO_MIXED = The driver keeps the keys for every row in the keyset, and the keyset size is greater than the rowset size. The cursor is keyset-driven inside the keyset and dynamic outside the keyset. (ODBC 1.0)

For information about scrollable cursors, see “Scrollable Cursors” in Chapter 11, “Retrieving Results (Advanced)”

Because this information type does not indicate general support of the escape character in the LIKE predicate, SQL92 does not include requirements for this character string.

This InfoType is limited to catalog functions. For a description of the use of the escape character in search pattern strings, see “Pattern Value Arguments” in Chapter 7, “Catalog Functions.”

SQL_SC_SQL92_ENTRY = Entry level SQL92 compliant

SQL_SC_FIPS127_2_TRANSITIONAL = FIPS 127-2 transitional level compliant

SQL_SC_SQL92_FULL = Full level SQL92 compliant

SQL_SC_ SQL92_INTERMEDIATE = Intermediate level SQL92 compliant

The following bitmasks are used to determine which datetime functions are supported:

SQL_SDF_CURRENT_DATE
SQL_SDF_CURRENT_TIME
SQL_SDF_CURRENT_TIMESTAMP

The following bitmasks are used to determine which clauses are supported by the data source:

SQL_SFKD_CASCADE
SQL_SFKD_NO_ACTION
SQL_SFKD_SET_DEFAULT
SQL_SFKD_SET_NULL

An FIPS Transitional level – conformant driver will always return all of these options as supported.

The following bitmasks are used to determine which clauses are supported by the data source:

SQL_SFKU_CASCADE
SQL_SFKU_NO_ACTION
SQL_SFKU_SET_DEFAULT
SQL_SFKU_SET_NULL

An SQL92 Full level – conformant driver will always return all of these options as supported.

The SQL92 or FIPS conformance level at which this feature needs to be supported is shown in parentheses next to each bitmask.

The following bitmasks are used to determine which clauses are supported by the data source:

SQL_SG_DELETE_TABLE (Entry level)
SQL_SG_INSERT_COLUMN (Intermediate level)
SQL_SG_INSERT_TABLE (Entry level)
SQL_SG_REFERENCES_TABLE (Entry level)
SQL_SG_REFERENCES_COLUMN (Entry level)
SQL_SG_SELECT_TABLE (Entry level)
SQL_SG_UPDATE_COLUMN (Entry level)
SQL_SG_UPDATE_TABLE (Entry level)
SQL_SG_USAGE_ON_DOMAIN (FIPS Transitional level)
SQL_SG_USAGE_ON_CHARACTER_SET (FIPS Transitional level)
SQL_SG_USAGE_ON_COLLATION (FIPS Transitional level)
SQL_SG_USAGE_ON_TRANSLATION (FIPS Transitional level)
SQL_SG_WITH_GRANT_OPTION (Entry level)

The following bitmasks are used to determine which numeric functions are supported:

SQL_SNVF_BIT_LENGTH
SQL_SNVF_CHAR_LENGTH
SQL_SNVF_CHARACTER_LENGTH
SQL_SNVF_EXTRACT
SQL_SNVF_OCTET_LENGTH
SQL_SNVF_POSITION

The SQL92 or FIPS conformance level at which this feature needs to be supported is shown in parentheses next to each bitmask.

The following bitmasks are used to determine which options are supported by the data source:

SQL_SP_BETWEEN (Entry level)
SQL_SP_COMPARISON (Entry level)
SQL_SP_EXISTS (Entry level)
SQL_SP_IN (Entry level)
SQL_SP_ISNOTNULL (Entry level)
SQL_SP_ISNULL (Entry level)
SQL_SP_LIKE (Entry level)
SQL_SP_MATCH_FULL (Full level)
SQL_SP_MATCH_PARTIAL(Full level)
SQL_SP_MATCH_UNIQUE_FULL (Full level)
SQL_SP_MATCH_UNIQUE_PARTIAL (Full level)
SQL_SP_OVERLAPS (FIPS Transitional level)
SQL_SP_QUANTIFIED_COMPARISON (Entry level)
SQL_SP_UNIQUE (Entry level)

The SQL92 or FIPS conformance level at which this feature needs to be supported is shown in parentheses next to each bitmask.

The following bitmasks are used to determine which options are supported by the data source:

SQL_SRJO_CORRESPONDING_CLAUSE (Intermediate level)
SQL_SRJO_CROSS_JOIN (Full level)
SQL_SRJO_EXCEPT_JOIN (Intermediate level)
SQL_SRJO_FULL_OUTER_JOIN (Intermediate level)
SQL_SRJO_INNER_JOIN (FIPS Transitional level)
SQL_SRJO_INTERSECT_JOIN (Intermediate level)
SQL_SRJO_LEFT_OUTER_JOIN (FIPS Transitional level)
SQL_SRJO_NATURAL_JOIN (FIPS Transitional level)
SQL_SRJO_RIGHT_OUTER_JOIN (FIPS Transitional level)
SQL_SRJO_UNION_JOIN (Full level)

SQL_SRJO_INNER_JOIN indicates support for the INNER JOIN syntax, not for the inner join capability. Support for the INNER JOIN syntax is FIPS TRANSITIONAL, while support for the inner join capability is ENTRY.

The SQL92 or FIPS conformance level at which this feature needs to be supported is shown in parentheses next to each bitmask.

The following bitmasks are used to determine which clauses are supported by the data source:

SQL_SR_CASCADE (FIPS Transitional level)
SQL_SR_DELETE_TABLE (Entry level)
SQL_SR_GRANT_OPTION_FOR (Intermediate level)
SQL_SR_INSERT_COLUMN (Intermediate level)
SQL_SR_INSERT_TABLE (Entry level)
SQL_SR_REFERENCES_COLUMN (Entry level)
SQL_SR_REFERENCES_TABLE (Entry level)
SQL_SR_RESTRICT (FIPS Transitional level)
SQL_SR_SELECT_TABLE (Entry level)
SQL_SR_UPDATE_COLUMN (Entry level)
SQL_SR_UPDATE_TABLE (Entry level)
SQL_SR_USAGE_ON_DOMAIN (FIPS Transitional level)
SQL_SR_USAGE_ON_CHARACTER_SET (FIPS Transitional level)
SQL_SR_USAGE_ON_COLLATION (FIPS Transitional level)
SQL_SR_USAGE_ON_TRANSLATION (FIPS Transitional level)

SQL_SRVC_VALUE_EXPRESSION
SQL_SRVC_NULL
SQL_SRVC_DEFAULT
SQL_SRVC_ROW_SUBQUERY

The following bitmasks are used to determine which string functions are supported:

SQL_SSF_CONVERT
SQL_SSF_LOWER
SQL_SSF_UPPER
SQL_SSF_SUBSTRING
SQL_SSF_TRANSLATE
SQL_SSF_TRIM_BOTH
SQL_SSF_TRIM_LEADING
SQL_SSF_TRIM_TRAILING

The SQL92 or FIPS conformance level at which this feature needs to be supported is shown in parentheses next to each bitmask.

The following bitmasks are used to determine which options are supported by the data source:

SQL_SVE_CASE (Intermediate level)
SQL_SVE_CAST (FIPS Transitional level)
SQL_SVE_COALESCE (Intermediate level)
SQL_SVE_NULLIF (Intermediate level)

SQL_SCC_XOPEN_CLI_VERSION1: The driver conforms to the X/Open CLI version 1.

SQL_SCC_ISO92_CLI: The driver conforms to the ISO 92 CLI.

The following bitmasks are used to determine which attributes are supported:

SQL_CA1_NEXT
SQL_CA1_ABSOLUTE
SQL_CA1_RELATIVE
SQL_CA1_BOOKMARK
SQL_CA1_LOCK_NO_CHANGE
SQL_CA1_LOCK_EXCLUSIVE
SQL_CA1_LOCK_UNLOCK
SQL_CA1_POS_POSITION
SQL_CA1_POS_UPDATE
SQL_CA1_POS_DELETE
SQL_CA1_POS_REFRESH
SQL_CA1_POSITIONED_UPDATE
SQL_CA1_POSITIONED_DELETE
SQL_CA1_SELECT_FOR_UPDATE
SQL_CA1_BULK_ADD
SQL_CA1_BULK_UPDATE_BY_BOOKMARK
SQL_CA1_BULK_DELETE_BY_BOOKMARK
SQL_CA1_BULK_FETCH_BY_BOOKMARK

For descriptions of these bitmasks, see SQL_DYNAMIC_CURSOR_ATTRIBUTES1 (and substitute “static cursor” for “dynamic cursor” in the descriptions).

An SQL92 Intermediate level – conformant driver will usually return the SQL_CA1_NEXT, SQL_CA1_ABSOLUTE, and SQL_CA1_RELATIVE options as supported, because it supports scrollable cursors through the embedded SQL FETCH statement. Because this does not directly determine the underlying SQL support, however, scrollable cursors may not be supported, even for an SQL92 Intermediate level – conformant driver.

The following bitmasks are used to determine which attributes are supported:

SQL_CA2_READ_ONLY_CONCURRENCY
SQL_CA2_LOCK_CONCURRENCY
SQL_CA2_OPT_ROWVER_CONCURRENCY
SQL_CA2_OPT_VALUES_CONCURRENCY
SQL_CA2_SENSITIVITY_ADDITIONS
SQL_CA2_SENSITIVITY_DELETIONS
SQL_CA2_SENSITIVITY_UPDATES
SQL_CA2_MAX_ROWS_SELECT
SQL_CA2_MAX_ROWS_INSERT
SQL_CA2_MAX_ROWS_DELETE
SQL_CA2_MAX_ROWS_UPDATE
SQL_CA2_MAX_ROWS_CATALOG
SQL_CA2_MAX_ROWS_AFFECTS_ALL
SQL_CA2_CRC_EXACT
SQL_CA2_CRC_APPROXIMATE
SQL_CA2_SIMULATE_NON_UNIQUE
SQL_CA2_SIMULATE_TRY_UNIQUE
SQL_CA2_SIMULATE_UNIQUE

For descriptions of these bitmasks, see SQL_DYNAMIC_CURSOR_ATTRIBUTES2 (and substitute “static cursor” for “dynamic cursor” in the descriptions).

The information type was introduced in ODBC 1.0; each bitmask is labeled with the version in which it was introduced.

The following bitmasks are used to determine which string functions are supported:

SQL_FN_STR_ASCII (ODBC 1.0)
SQL_FN_STR_BIT_LENGTH (ODBC 3.0)
SQL_FN_STR_CHAR (ODBC 1.0)
SQL_FN_STR_CHAR_
LENGTH (ODBC 3.0)
SQL_FN_STR_CHARACTER_
LENGTH (ODBC 3.0)
SQL_FN_STR_CONCAT (ODBC 1.0)
SQL_FN_STR_DIFFERENCE (ODBC 2.0)
SQL_FN_STR_INSERT (ODBC 1.0)
SQL_FN_STR_LCASE (ODBC 1.0)
SQL_FN_STR_LEFT (ODBC 1.0)
SQL_FN_STR_LENGTH (ODBC 1.0)
SQL_FN_STR_LOCATE (ODBC 1.0)
SQL_FN_STR_LTRIM (ODBC 1.0)
SQL_FN_STR_OCTET_
LENGTH (ODBC 3.0)
SQL_FN_STR_POSITION (ODBC 3.0)
SQL_FN_STR_REPEAT (ODBC 1.0)
SQL_FN_STR_REPLACE (ODBC 1.0)
SQL_FN_STR_RIGHT (ODBC 1.0)
SQL_FN_STR_RTRIM (ODBC 1.0)
SQL_FN_STR_SOUNDEX (ODBC 2.0)
SQL_FN_STR_SPACE (ODBC 2.0)
SQL_FN_STR_SUBSTRING (ODBC 1.0)
SQL_FN_STR_UCASE (ODBC 1.0)

If an application can call the LOCATE scalar function with the string_exp1, string_exp2, and start arguments, the driver returns the SQL_FN_STR_LOCATE bitmask. If an application can call the LOCATE scalar function with only the string_exp1 and string_exp2 arguments, the driver returns the SQL_FN_STR_LOCATE_2 bitmask. Drivers that fully support the LOCATE scalar function return both bitmasks.

(For more information, see Appendix E, “Scalar Functions.”)

SQL_SQ_CORRELATED_SUBQUERIES
SQL_SQ_COMPARISON
SQL_SQ_EXISTS
SQL_SQ_IN
SQL_SQ_QUANTIFIED

The SQL_SQ_CORRELATED_SUBQUERIES bitmask indicates that all predicates that support subqueries support correlated subqueries.

An SQL92 Entry level – conformant driver will always return a bitmask in which all of these bits are set.

The following bitmasks are used to determine which system functions are supported:

SQL_FN_SYS_DBNAME
SQL_FN_SYS_IFNULL
SQL_FN_SYS_USERNAME

This character string can be in upper, lower, or mixed case.

An SQL92 Entry level – conformant driver will always return “table”.

The following bitmasks are used to determine which intervals are supported:

SQL_FN_TSI_FRAC_SECOND
SQL_FN_TSI_SECOND
SQL_FN_TSI_MINUTE
SQL_FN_TSI_HOUR
SQL_FN_TSI_DAY
SQL_FN_TSI_WEEK
SQL_FN_TSI_MONTH
SQL_FN_TSI_QUARTER
SQL_FN_TSI_YEAR

An FIPS Transitional level – conformant driver will always return a bitmask in which all of these bits are set.

The following bitmasks are used to determine which intervals are supported:

SQL_FN_TSI_FRAC_SECOND
SQL_FN_TSI_SECOND
SQL_FN_TSI_MINUTE
SQL_FN_TSI_HOUR
SQL_FN_TSI_DAY
SQL_FN_TSI_WEEK
SQL_FN_TSI_MONTH
SQL_FN_TSI_QUARTER
SQL_FN_TSI_YEAR

An FIPS Transitional level – conformant driver will always return a bitmask in which all of these bits are set.

The information type was introduced in ODBC 1.0; each bitmask is labeled with the version in which it was introduced.

The following bitmasks are used to determine which date and time functions are supported:

SQL_FN_TD_CURRENT_DATE ODBC 3.0)
SQL_FN_TD_CURRENT_TIME (ODBC 3.0)
SQL_FN_TD_CURRENT_TIMESTAMP (ODBC 3.0)
SQL_FN_TD_CURDATE (ODBC 1.0)
SQL_FN_TD_CURTIME (ODBC 1.0)
SQL_FN_TD_DAYNAME (ODBC 2.0)
SQL_FN_TD_DAYOFMONTH (ODBC 1.0)
SQL_FN_TD_DAYOFWEEK (ODBC 1.0)
SQL_FN_TD_DAYOFYEAR (ODBC 1.0)
SQL_FN_TD_EXTRACT (ODBC 3.0)
SQL_FN_TD_HOUR (ODBC 1.0)
SQL_FN_TD_MINUTE (ODBC 1.0)
SQL_FN_TD_MONTH (ODBC 1.0)
SQL_FN_TD_MONTHNAME (ODBC 2.0)
SQL_FN_TD_NOW (ODBC 1.0)
SQL_FN_TD_QUARTER (ODBC 1.0)
SQL_FN_TD_SECOND (ODBC 1.0)
SQL_FN_TD_TIMESTAMPADD (ODBC 2.0)
SQL_FN_TD_TIMESTAMPDIFF (ODBC 2.0)
SQL_FN_TD_WEEK (ODBC 1.0)
SQL_FN_TD_YEAR (ODBC 1.0)

The information type was introduced in ODBC 1.0; each return value is labeled with the version in which it was introduced.

SQL_TC_NONE = Transactions not supported. (ODBC 1.0)

SQL_TC_DML = Transactions can only contain Data Manipulation Language (DML) statements (SELECT, INSERT, UPDATE, DELETE). Data Definition Language (DDL) statements encountered in a transaction cause an error. (ODBC 1.0)

SQL_TC_DDL_COMMIT = Transactions can only contain DML statements. DDL statements (CREATE TABLE, DROP INDEX, and so on) encountered in a transaction cause the transaction to be committed. (ODBC 2.0)

SQL_TC_DDL_IGNORE = Transactions can only contain DML statements. DDL statements encountered in a transaction are ignored. (ODBC 2.0)

SQL_TC_ALL = Transactions can contain DDL statements and DML statements in any order. (ODBC 1.0)

(Because support of transactions is mandatory in SQL92, a SQL92 conformant driver (any level) will never return SQL_TC_NONE.)

The following bitmasks are used in conjunction with the flag to determine which options are supported:

SQL_TXN_READ_UNCOMMITTED
SQL_TXN_READ_COMMITTED
SQL_TXN_REPEATABLE_READ
SQL_TXN_SERIALIZABLE

For descriptions of these isolation levels, see the description of SQL_DEFAULT_TXN_ISOLATION.

To set the transaction isolation level, an application calls SQLSetConnectAttr to set the SQL_ATTR_TXN_ISOLATION attribute. For more information, see SQLSetConnectAttr.

An SQL92 Entry level – conformant driver will always return SQL_TXN_SERIALIZABLE as supported. A FIPS Transitional level – conformant driver will always return all of these options as supported.

SQL_U_UNION = The data source supports the UNION clause.

SQL_U_UNION_ALL = The data source supports the ALL keyword in the UNION clause. (SQLGetInfo returns both SQL_U_UNION and SQL_U_UNION_ALL in this case.)

An SQL92 Entry level – conformant driver will always return both of these options as supported.