> # ODBC API Functions

> The 32-bit and 64-bit ODBC drivers are ODBC Level 1-compliant, supporting all ODBC Core and Level 1 functions. Most Level 2 functions are also supported. Table 2-4 and Table 2-5 list supported functions for ODBC 2.x and ODBC 3.x applications, respectively.

> - On Linux and UNIX 64-bit platforms, the compiler flag, ODBC64, must be set.
> - On Linux and UNIX, the ODBC header files for the DataDirect Driver Manager are installed in the installdir/include directory.
> - On Windows, the ODBC header files are installed with the MDAC installation.

> Table 2-4. Function Conformance for 2.x ODBC Application
> Core Functions
> SQLAllocConnect SQLAllocEnv SQLAllocStmt SQLBindCol SQLBindParameter SQLCancel SQLColAttributes SQLConnect SQLDescribeCol SQLDisconnect SQLDrivers SQLError | SQLExecDirect SQLExecute SQLFetch SQLFreeConnect SQLFreeEnv SQLFreeStmt SQLGetCursorName SQLNumResultCols SQLPrepare SQLRowCount SQLSetCursorName SQLTransact
> Level 1 Functions
> SQLColumns SQLGetConnectOption SQLGetData SQLDriverConnect SQLGetFunctions SQLGetInfo SQLGetStmtOption SQLGetTypeInfo | SQLParamData SQLPutData SQLSetConnectOption SQLSetStmtOption SQLSpecialColumns SQLStatistics SQLTables
> Level 2 Functions
> SQLDataSources SQLExtendedFetch SQLMoreResults SQLNativeSql | SQLNumParams SQLParamOptions SQLSetScrollOptions

> Table 2-5. Function Conformance for 3.x ODBC Applications
> SQLAllocHandle SQLBindCol SQLBindParam SQLBindParameter SQLBulkOperations SQLCancel SQLCloseCursor SQLColAttribute SQLColAttributes SQLColumnPrivileges SQLColumns SQLConnect SQLCopyDesc SQLDataSources SQLDescribeCol SQLDescribeParam1 SQLDisconnect SQLDriverConnect SQLDrivers SQLEndTran SQLExecDirect | SQLExecute SQLExtendedFetch SQLFetch SQLFetchScroll SQLForeignKeys SQLFreeHandle SQLFreeStmt SQLGetConnectAttr SQLGetCursorName SQLGetData SQLGetDescField SQLGetDescRec SQLGetDiagField SQLGetDiagRec SQLGetEnvAttr SQLGetFunctions SQLGetInfo SQLGetStmtAttr SQLGetTypeInfo SQLMoreResults SQLNativeSql | SQLNumParams SQLNumResultCols SQLParamData SQLPrepare SQLPrimaryKeys SQLProcedureColumns SQLProcedures SQLPutData SQLRowCount SQLSetConnectAttr SQLSetCursorName SQLSetDescField SQLSetDescRec SQLSetEnvAttr SQLSetPos SQLSetStmtAttr SQLSpecialColumns SQLStatistics SQLTablePrivileges SQLTables SQLTransact

> 1SQLDescribeParam is not supported on Oracle databases. Instead, use the DataSourceEnableDescribeParam service attribute, described in the SequeLink Administrator's Guide.

> ### Binding SQL Statements

> An ODBC application can prepare a query that contains dynamic parameters. Each parameter in a SQL statement must be associated, or bound, to a variable in the application before the statement is executed. When the application binds a variable to a parameter, it describes that variable and that parameter to the driver. Therefore, the application must supply the following information:

> - The data type of the variable that the application wishes to map to the dynamic parameter.
> - The SQL data type of the dynamic parameter (the data type that the database system assigned to the parameter marker).

> The two data types are identified separately using the SQLBindParameter API.

> The SequeLink ODBC driver relies on the binding of parameters to know how to send information to the database system in its native format. If an application furnishes incorrect parameter binding information to the ODBC driver, the results will be unpredictable. For example, the statement might not be executed correctly.

> To ensure interoperability, the SequeLink ODBC driver uses only the parameter binding information provided by the application. Some DBMSs cannot publish dynamic parameter information information back to an ODBC driver. For example, both the SQL Server and Oracle query processors can determine that a parameter is an integer. However, the Oracle query processor cannot publish this information back to the SequeLink ODBC driver.

> NOTES:

> - The SQL data type is determined at prepare time by the database and does not change for the life of the statement. The SQL data type is not dependent on the data being used by the application. For example, it is not valid to bind the SQL type to SQL_NUMERIC with a precision of 15 and a scale of 5, and then bind it on a later execution to a SQL type of SQL_NUMERIC with a precision of 13 and a scale of 3.
> - You can implement SQLDescribeParam only when a database system publishes parameter information after prepare time. The ODBC driver returns this information when the application requests it, but depending on the database, performance penalties can be incurred. You can tune this feature through the SequeLink data source service attribute DataSourceDescribeParam. Refer to the SequeLink Administrator's Guide for information about service attributes.

> ### Support for Unicode ODBC W (Wide) Function Calls

> The ODBC driver fully supports the SQL-W functions.

> The ODBC driver automatically determines whether the database is a Unicode database. Table 2-6 summarizes the way that the ODBC driver maps the database data types to the Unicode data types.

> Table 2-6. Support for Unicode ODBC W (Wide) Function Calls
> Unicode Data Type | Database Data Type
> --- | ---
> | DB2 | Oracle | SQL Server | Sybase1
> SQL_WCHAR | Graphic | CHAR | nchar | CHAR, UNICHAR
> SQL_WLONGVARCHAR | Long, Vargraphic | CLOB, LONG | ntext | TEXT
> SQL_WVARCHAR | Vargraphic | VARCHAR2 | nvarchar, sysname | UNIVARCHAR, VARCHAR
> 1. The Unicode data types are supported if the UTF-8 character set is installed on the Sybase database.

> When used with SequeLink Server for ODBC Socket and SequeLink Server for JDBC Socket, the ODBC driver supports the data types of the backend driver used.

> When used with SequeLink Server for Informix and SequeLink Server for JDBC Socket, the ODBC driver does not support Unicode data types.