Core Interface Conformance
1 Allocate and free all types of handles, by calling SQLAllocHandle and SQLFreeHandle.
2 Use all forms of the SQLFreeStmt function.
3 Bind result set columns, by calling SQLBindCol.
4 Handle dynamic parameters, including arrays of parameters, in the input
direction only, by calling SQLBindParameter and SQLNumParams. (Parameters in the output direction are feature 203 in “Level 2 Interface Conformance.”)
5 Specify a bind offset.
6 Use the data-at-execution dialog, involving calls to SQLParamData and SQLPutData.
7 Manage cursors and cursor names, by calling SQLCloseCursor, SQLGetCursorName, and SQLSetCursorName.
8 Gain access to the description (metadata) of result sets, by calling SQLColAttribute, SQLDescribeCol, SQLNumResultCols, and SQLRowCount. (Use of these functions on column number 0 to retrieve bookmark metadata is
feature 204 in “Level 2 Interface Conformance.”)
9 Query the data dictionary, by calling the catalog functions SQLColumns, SQLGetTypeInfo, SQLStatistics, and SQLTables. (The driver is not required to support multi-part names of database tables
and views. For more information, see feature 101 in “Level 1 Interface Conformance”) and feature 201 in “Level 2 Interface Conformance”. However, certain features of the SQL-92 specification, such as column
qualification and names of indexes, are syntactically comparable to multi-part
naming. The present list of ODBC features is not intended to introduce new
optionality into these aspects of SQL-92.)
10 Manage data sources and connections, by calling SQLConnect, SQLDataSources, SQLDisconnect, and SQLDriverConnect. Obtain information on drivers, no matter which ODBC level they support, by
calling SQLDrivers.
11 Prepare and execute SQL statements, by calling SQLExecDirect, SQLExecute, and SQLPrepare.
12 Fetch one row of a result set or multiple rows, in the forward direction only,
by calling SQLFetch, or by calling SQLFetchScroll with the FetchOrientation argument set to SQL_FETCH_NEXT.
13 Obtain an unbound column in parts, by calling SQLGetData.
14 Obtain current values of all attributes, by calling SQLGetConnectAttr, SQLGetEnvAttr, and SQLGetStmtAttr; and set all attributes to their default values and set certain attributes to
non-default values by calling SQLSetConnectAttr, SQLSetEnvAttr, and SQLSetStmtAttr.
15 Manipulate certain fields of descriptors, by calling SQLCopyDesc, SQLGetDescField, SQLGetDescRec, SQLSetDescField, and SQLSetDescRec.
16 Obtain diagnostic information, by calling SQLGetDiagField and SQLGetDiagRec.
17 Detect driver capabilities, by calling SQLGetFunctions and SQLGetInfo. Also, detect the result of any text substitutions made to an SQL statement
before it is sent to the data source, by calling SQLNativeSql.
18 Use the syntax of SQLEndTran to commit a transaction. A Core-level driver need not support true
transactions; therefore, the application cannot specify SQL_ROLLBACK, nor specify
SQL_AUTOCOMMIT_OFF for the SQL_ATTR_AUTOCOMMIT connection attribute. (For more
information, see feature 109 in “Level 2 Interface Conformance.”)
19 Call SQLCancel to cancel the data-at-execution dialog and, in multithread environments, to
cancel an ODBC function executing in another thread. Core-level interface
conformance does not mandate support for asynchronous execution of functions nor the
use of SQLCancel to cancel an ODBC function executing asynchronously. Neither the platform nor
the ODBC driver need be multithread for the driver to conduct independent
activities at the same time. However, in multithread environments, the ODBC driver
must be thread-safe. Serialization of requests from the application is a
conformant way to implement this specification, even though it may create serious
performance problems.
20 Obtain the SQL_BEST_ROWID row-identifying column of tables, by calling SQLSpecialColumns. (Support for SQL_ROWVER is feature 208 in “Level 2 Interface Conformance.”)
Important ODBC Drivers must implement the functions in the Core interface conformance
level.