This chapter describes the general characteristics of ODBC functions, determining driver conformance levels, the role of the Driver Manager, ODBC function arguments, and the values ODBC functions return.
Each SOLID SQL API and ODBC function name starts with the prefix "SQL." Each function accepts one or more arguments. Arguments are defined as input (to the driver) or output (from the the driver).
C programs that call ODBC functions must include the SQL.H, SQLEXT.H, and WINDOWS.H header files. These files define Windows and ODBC constants and types and provide function prototypes for all ODBC functions.
C programs that call SOLID SQL API functions must include the CLI0CORE.H, CLI0DEFS.H, CLI0ENV.H and CLI01EXT1.H header files. These files define constants and types and provide function prototypes for all SOLID SQL API functions.
ODBC defines conformance levels for drivers in two areas: the ODBC API and the ODBC SQL grammar (which includes the ODBC SQL data types). These levels establish standard sets of functionality. By inquiring the conformance levels supported by a driver, an application can easily determine if the driver provides the necessary functionality. For a complete discussion of ODBC conformance levels, see "ODBC Conformance Levels" in Chapter 1, "ODBC Theory of Operation."
Note The following sections refer to SQLGetInfo and SQLGetTypeInfo, which are part of the Level 1 API conformance level. Although it is strongly recommended that drivers support this conformance level, drivers are not required to do so. If these functions are not supported, an application developer must consult the driver documentation to determine its conformance levels.
Determining API Conformance Levels
ODBC functions are divided into core functions, which are defined in the X/Open and SQL Access Group Call Level Interface specification, and two levels of extension functions, with which ODBC extends this specification. To determine the function conformance level of a driver, an application calls SQLGetInfo with the SQL_ODBC_SAG_CLI_CONFORMANCE and SQL_ODBC_API_CONFORMANCE flags. Note that a driver can support one or more extension functions but not conform to ODBC extension Level 1 or 2. To determine if a driver supports a particular function, an application calls SQLGetFunctions. Note that SQLGetFunctions is implemented by the Driver Manager and can be called for any driver, regardless of its level.
Determining SQL Conformance Levels
The ODBC SQL grammar, which includes SQL data types, is divided into a minimum grammar, a core grammar, which corresponds to the X/Open and SQL Access Group SQL CAE specification (1992), and an extended grammar, which provides common extensions to SQL. To determine the SQL conformance level of a driver, an application calls SQLGetInfo with the SQL_ODBC_SQL_CONFORMANCE flag. To determine whether a driver supports a specific SQL extension, an application calls SQLGetInfo with a flag for that extension. For more information, see Appendix C, "SQL Grammar." To determine whether a driver supports a specific SQL data type, an application calls SQLGetTypeInfo.
The Driver Manager is a DLL that provides access to ODBC drivers. An application typically links with the Driver Manager import library (ODBC.LIB) to gain access to the Driver Manager.
Application accessing SOLID SQL API directly bypass the Driver Manager and cannot therefore use ODBC functions that are implemented in the Driver Manager.
Whenever an application calls an ODBC function, the Driver Manager performs one of the following actions:
- For SQLDataSources and SQLDrivers, the Driver Manager processes the call. It does not pass the call to the driver.
- For SQLGetFunctions, the Driver Manager passes the call to the driver associated with the connection. If the driver does not support SQLGetFunctions, the Driver Manager processes the call.
- For SQLAllocEnv, SQLAllocConnect, SQLSetConnectOption, SQLFreeConnect, and SQLFreeEnv, the Driver Manager processes the call. The Driver Manager calls SQLAllocEnv, SQLAllocConnect, and SQLSetConnectOption in the driver when the NAME="I12">
- Scrollable cursors for access to result sets (full level).
- Outer joins (intermediate and full levels).
Dynamic SQL, which is included in the most recent ANSI specification, allows an application to generate and execute SQL statements at run time.
Dynamic SQL statements can be prepared. When a statement is prepared, the database environment generates an access plan and a description of the result set. The statement can be executed multiple times with the previously generated access plan, which minimizes processing overhead.
Parameters can be included in dynamic SQL statements. Parameters function in much the same way as host variables in embedded SQL. Prior to execution, assign values to the place held by each parameter. Unlike static SQL, parameters do not require length or data type definition prior to program compilation.
Dynamic SQL is not as efficient as static SQL, but is very useful if an application requires:
- Flexibility to construct SQL statements at run time.
- Flexibility to defer an association with a database until run time.
A Call Level Interface (CLI) for SQL consists of a library of function calls that support SQL statements. The ODBC interface is a CLI.
A CLI is typically used for dynamic access. The CLI defined by the X/Open and SQL Access Group — and therefore the ODBC interface — is similar to the dynamic embedded version of SQL described in the X/Open and SQL Access Group SQL CAE specification (1992).
The ODBC interface is designed to be used directly by application programmers, not to be the target of a preprocessor for embedded SQL.
A CLI is very straightforward to programmers who are familiar with function libraries. The function call interface does not require host variables or other embedded SQL concepts.
A CLI does not require a precompiler. To submit an SQL request, place an SQL command into a text buffer and pass the buffer as a parameter in a function call. CLI functions provide declarative capabilities and request management. Obtain error information as for any function call — by return code or error function call, depending on the CLI.
A CLI allows for specification of result storage before or after the results are available. Results can be determined and appropriate action taken without being limited to a specific set of data structures that were defined prior to the request. Deferral of storage specification is called late binding of variables.
For a comparison between embedded SQL statements and the ODBC call level interface, see Appendix E, "Comparison Between Embedded SQL and ODBC."
Interoperability for call level interfaces can be addressed in the following ways:
- All clients and data sources adhere to a standard interface.
- All clients adhere to a standard interface; driver programs interpret the commands for a specific data source.
The second approach allows drivers to shield clients from database functionality differences, database protocol differences, and network differences. ODBC follows the second approach. ODBC can take advantage of standard database protocols and network protocols, but does not require the use of a standard database protocol or network protocol.
Copyright © 1992-1997 Solid Information Technology Ltd All rights reserved.