Differences between DB2 UDB CLI and embedded SQL

Differences between DB2 UDB CLI and embedded SQL

DB2^® UDB call level interface (CLI) and embedded SQL differ in many ways.
An application that uses an embedded SQL interface requires a precompiler to convert the SQL statements into code. Code is compiled, bound to the database, and processed. In contrast, a DB2 UDB CLI application does not require precompilation or binding, but instead uses a standard set of functions to run SQL statements and related services at run time.
This difference is important because, traditionally, precompilers have been specific to a database product, which effectively ties your applications to that product. DB2 UDB CLI enables you to write portable applications that are independent of any particular database product. This independence means that a DB2 UDB CLI application does not need to be recompiled or rebound to access-different database products. An application selects the appropriate database products at run time. DB2 UDB CLI and embedded SQL also differ in the following ways:

DB2 UDB CLI does not require the explicit declaration of cursors. DB2 UDB CLI generates them as needed. The application can then use the generated cursor in the normal cursor fetch model for multiple row SELECT statements and positioned UPDATE and DELETE statements.

The OPEN statement is not necessary in DB2 UDB CLI. Instead, the processing of a SELECT automatically causes a cursor to be opened.

Unlike embedded SQL, DB2 UDB CLI allows the use of parameter markers on the equivalent of the EXECUTE IMMEDIATE statement (the SQLExecDirect() function).

A COMMIT or ROLLBACK in DB2 UDB CLI is issued through the SQLTransact() or SQLEndTran() function call rather than by passing it as an SQL statement.

DB2 UDB CLI manages statement-related information on behalf of the application, and provides a statement handle to refer to it as an abstract object. This handle avoids the need for the application to use product-specific data structures.

Similar to the statement handle, the environment handle and connection handle provide a means to refer to all global variables and connection specific information.

DB2 UDB CLI uses the SQLSTATE values defined by the X/Open SQL CAE specification. Although the format and many of the values are consistent with values that are used by the IBM^® relational database products, there are differences.
Despite these differences, there is an important common concept between embedded SQL and DB2 UDB CLI:

DB2 UDB CLI can process any SQL statement that can be prepared dynamically in embedded SQL. This is guaranteed because DB2 UDB CLI does not actually process the SQL statement itself, but passes it to the Database Management System (DBMS) for dynamic processing.

Table 1 lists each SQL statement, and whether it can be processed using DB2 UDB CLI.
Table 1. SQL statements
SQL statement Dyn ¹ CLI ³

ALTER TABLE X X
BEGIN DECLARE SECTION ²
CALL X X
CLOSE SQLFreeStmt()
COMMENT ON X X
COMMIT X SQLTransact(), SQLEndTran()
CONNECT (Type 1) SQLConnect()
CONNECT (Type 2) SQLConnect()
CREATE INDEX X X
CREATE TABLE X X
CREATE VIEW X X
DECLARE CURSOR ^b SQLAllocStmt()
DELETE X X
DESCRIBE SQLDescribeCol(), SQLColAttributes()
DISCONNECT SQLDisconnect()
DROP X X
END DECLARE SECTION ^b
EXECUTE SQLExecute()
EXECUTE IMMEDIATE SQLExecDirect()
FETCH SQLFetch()
GRANT X X
INCLUDE ^b
INSERT X X
LOCK TABLE X X
OPEN SQLExecute(), SQLExecDirect()
PREPARE SQLPrepare()
RELEASE SQLDisconnect()
REVOKE X X
ROLLBACK X SQLTransact(), SQLEndTran()
SELECT X X
SET CONNECTION
UPDATE X X
WHENEVER ²
Notes:

¹

Dyn stands for dynamic. All statements in this list can be coded as static SQL, but only those marked with X can be coded as dynamic SQL.

²

This is a nonprocessable statement.

³

An X indicates that this statement can be processed using either SQLExecDirect() or SQLPrepare() and SQLExecute(). If there is an equivalent DB2 UDB CLI function, the function name is listed.

Each DBMS might have additional statements that can be dynamically prepared, in which case DB2 UDB CLI passes them to the DBMS. There is one exception, COMMIT and ROLLBACK can be dynamically prepared by some DBMSs but are not passed. Instead, the SQLTransact() or SQLEndTran() should be used to specify either COMMIT or ROLLBACK.

Parent topic:
Getting started with DB2 UDB CLI

SQL statement	Dyn ¹	CLI ³
ALTER TABLE	X	X
BEGIN DECLARE SECTION ²
CALL	X	X
CLOSE		`SQLFreeStmt()`
COMMENT ON	X	X
COMMIT	X	`SQLTransact()`, `SQLEndTran()`
CONNECT (Type 1)		`SQLConnect()`
CONNECT (Type 2)		`SQLConnect()`
CREATE INDEX	X	X
CREATE TABLE	X	X
CREATE VIEW	X	X
DECLARE CURSOR ^b		`SQLAllocStmt()`
DELETE	X	X
DESCRIBE		`SQLDescribeCol()`, `SQLColAttributes()`
DISCONNECT		`SQLDisconnect()`
DROP	X	X
END DECLARE SECTION ^b
EXECUTE		`SQLExecute()`
EXECUTE IMMEDIATE		`SQLExecDirect()`
FETCH		`SQLFetch()`
GRANT	X	X
INCLUDE ^b
INSERT	X	X
LOCK TABLE	X	X
OPEN		`SQLExecute()`, `SQLExecDirect()`
PREPARE		`SQLPrepare()`
RELEASE		`SQLDisconnect()`
REVOKE	X	X
ROLLBACK	X	`SQLTransact()`, `SQLEndTran()`
SELECT	X	X
SET CONNECTION
UPDATE	X	X
WHENEVER ²
Notes: ¹ Dyn stands for dynamic. All statements in this list can be coded as static SQL, but only those marked with X can be coded as dynamic SQL. ² This is a nonprocessable statement. ³ An X indicates that this statement can be processed using either `SQLExecDirect()` or `SQLPrepare()` and `SQLExecute()`. If there is an equivalent DB2 UDB CLI function, the function name is listed.