| Pro*C/C++ Precompiler Programmer's Guide Release 8.1.5 A68022-01 |
|
This appendix contains descriptions of both the SQL92 embedded statements and directives, as well as the Oracle embedded SQL extensions.
Note: Only statements which differ in syntax from non-embedded SQL are described in this appendix. For details of the non-embedded SQL statements, see the Oracle8i SQL Reference.
This appendix has the following sections:
Embedded SQL statements place DDL, DML, and Transaction Control statements within a Pro*C/C++ program. Table F-1 provides a functional summary of the embedded SQL statements and directives.
The Source/Type column in Table F-1 is displayed in the format:
|
Source |
Is either SQL92 standard SQL (S) or an Oracle extension (O). |
|
Type |
Is either an executable (E) statement or a directive (D). |
The directives and statements appear alphabetically. The description of each contains the following sections:
Syntax diagrams are used to illustrate embedded SQL syntax. They are drawings that depict valid syntax paths.
Trace each diagram from left to right, in the direction shown by the arrows.
Statements and other keywords appear in UPPER CASE inside rectangles. Type them exactly as shown in the rectangles. Parameters appear in lower case inside ovals. Substitute variables for the parameters in statements you write. Operators, delimiters, and terminators appear in circles. Following the conventions defined in the Preface, a semicolon terminates statements.
If the syntax diagram has more than one path, you can choose any path to travel.
If you have the choice of more than one keyword, operator, or parameter, your options appear in a vertical list. In the following example, you can travel down the vertical line as far as you like, then continue along any horizontal line:
According to the diagram, all of the following statements are valid:
EXEC SQL WHENEVER NOT FOUND ... EXEC SQL WHENEVER SQLERROR ... EXEC SQL WHENEVER SQLWARNING ...
Required keywords and parameters can appear singly or in a vertical list of alternatives. Single required keywords and parameters appear on the main path, that is, on the horizontal line you are currently traveling. In the following example, cursor is a required parameter:
If there is a cursor named emp_cursor, then, according to the diagram, the following statement is valid:
EXEC SQL CLOSE emp_cursor;
If any of the keywords or parameters in a vertical list appears on the main path, one of them is required. That is, you must choose one of the keywords or parameters, but not necessarily the one that appears on the main path. In the following example, you must choose one of the four actions:
If keywords and parameters appear in a vertical list above the main path, they are optional. In the following example, AT :db_name and WORK are optional:
If there is a database named oracle2, then, according to the diagram, all of the following statements are valid:
EXEC SQL ROLLBACK; EXEC SQL ROLLBACK WORK; EXEC SQL AT oracle2 ROLLBACK;
Loops let you repeat the syntax within them as many times as you like. In the following example, column_name is inside a loop. So, after choosing one column name, you can go back repeatedly to choose another, separating the column names by a comma.
If DEBIT, CREDIT, and BALANCE are column names, then, according to the diagram, all of the following statements are valid:
EXEC SQL SELECT DEBIT INTO ... EXEC SQL SELECT CREDIT, BALANCE INTO ... EXEC SQL SELECT DEBIT, CREDIT, BALANCE INTO ...
Read a multi-part diagram as if all the main paths were joined end-to-end. The following example is a two-part diagram:
According to the diagram, the following statement is valid:
EXEC SQL PREPARE statement_name FROM string_literal;
The names of Oracle objects, such as tables and columns, must not exceed 30 characters in length. The first character must be a letter, but the rest can be any combination of letters, numerals, dollar signs ($), pound signs (#), and underscores (_).
However, if an Oracle identifier is enclosed by quotation marks ("), it can contain any combination of legal characters, including spaces but excluding quotation marks.
Oracle identifiers are not case-sensitive except when enclosed by quotation marks.
In all embedded SQL diagrams, each statement is understood to end with the statement terminator ";".
To allocate a cursor variable to be referenced in a PL/SQL block, or to allocate space in the object cache.
A cursor variable (see Chapter 4, "Datatypes and Host Variables") of type sql_cursor must be declared before allocating memory for the cursor variable.
Pointers to a host struct and, optionally, an indicator struct must be declared before allocating memory in the object cache.
An active connection to a database is required.
While a cursor is static, a cursor variable is dynamic because it is not tied to a specific query. You can open a cursor variable for any type-compatible query.
For more information on this statement, see PL/SQL User's Guide and Reference and Oracle8i SQL Reference.
This partial example illustrates the use of the ALLOCATE statement in a Pro*C/C++ program:
EXEC SQL BEGIN DECLARE SECTION; SQL_CURSOR emp_cv; struct{ ... } emp_rec; EXEC SQL END DECLARE SECTION; EXEC SQL ALLOCATE :emp_cv; EXEC SQL EXECUTE BEGIN OPEN :emp_cv FOR SELECT * FROM emp; END; END-EXEC; for (;;) { EXEC SQL FETCH :emp_cv INTO :emp_rec; ... }
CACHE FREE ALL (Executable Embedded SQL Extension).
CLOSE (Executable Embedded SQL).
EXECUTE (Executable Embedded SQL) .
FETCH (Executable Embedded SQL) .
FETCH DESCRIPTOR (Executable Embedded SQL).
FREE (Executable Embedded SQL Extension).
An ANSI dynamic SQL statement that allocates a descriptor.
None.
Use DYNAMIC=ANSI precompiler option. For information on using this statement, see "ALLOCATE DESCRIPTOR".
EXEC SQL FOR :batch ALLOCATE DESCRIPTOR GLOBAL :binddes WITH MAX 25 ;
DESCRIBE DESCRIPTOR (Executable Embedded SQL).
DEALLOCATE DESCRIPTOR (Embedded SQL Statement)
GET DESCRIPTOR (Executable Embedded SQL).
SET DESCRIPTOR (Executable Embedded SQL).
To free all memory in the object cache.
An active database connection must exist.
When the connection count drops to zero, SQLLIB automatically frees all object cache memory. For more information, see "CACHE FREE ALL".
EXEC SQL AT mydb CACHE FREE ALL ;
ALLOCATE (Executable Embedded SQL Extension).
FREE (Executable Embedded SQL Extension).
To call a stored procedure.
An active database connection must exist.
|
schema |
Is the schema containing the procedure. If you omit schema, Oracle8i assumes the procedure is in your own schema. |
|
pkg |
The package where the procedure is stored. |
|
st_proc |
The stored procedure to be called. |
|
db_link |
The complete or partial name of a database link to a remote database where the procedure is located. For information on referring to database links, see the Oracle8i SQL Reference. |
|
expr |
The list of expressions that are the parameters of the procedure. |
|
ret_var |
The host variable that receives the returned value of a function. |
|
ret_ind |
The indicator variable for ret_var. |
For more about this statement, see "Calling a Stored PL/SQL or Java Subprogram".
For a complete discussion of stored procedures, see Oracle8i Application Developer's Guide - Fundamentals, "External Routines" chapter.
int emp_no; char emp_name[10]; float salary; char dept_name[20]; ... emp_no = 1325; EXEC SQL CALL get_sal(:emp_no, :emp_name, :salary) INTO :dept_name ; /* Print emp_name, salary, dept_name */ ...
None
To disable a cursor, freeing the resources acquired by opening the cursor, and releasing parse locks.
The cursor or cursor variable be open if MODE=ANSI.
|
cursor |
A cursor to be closed. |
|
cursor_variable |
A cursor variable to be closed. |
Rows cannot be fetched from a closed cursor. A cursor need not be closed to be reopened. The HOLD_CURSOR and RELEASE_CURSOR precompiler options alter the effect of the CLOSE statement. For information on these options, see Chapter 10, "Precompiler Options".
This example illustrates the use of the CLOSE statement:
EXEC SQL CLOSE emp_cursor;
PREPARE (Executable Embedded SQL).
DECLARE CURSOR (Embedded SQL Directive).
OPEN (Executable Embedded SQL).
To append elements of one collection to the end of another collection.
You cannot append to a NULL collection, or append beyond the upper bound of a collection.
For usage notes as well as keywords, parameters, and examples, see "COLLECTION APPEND".
See the other COLLECTION statements.
To obtain information about a collection.
Use the ALLOCATE and OBJECT GET statements to allocate a descriptor and to store collection attributes in the descriptor.
where attrib is:
For usage notes as well as keywords, parameters, and examples, see "COLLECTION DESCRIBE".
See the other COLLECTION statements.
To retrieve the elements of a collection.
For usage notes as well as keywords, parameters, and examples, see "COLLECTION GET".
See the other COLLECTION statements.
To reset the collection slice endpoints back to the beginning of the collection.
For usage notes as well as keywords, parameters, and examples, see "COLLECTION RESET".
See the other COLLECTION statements.
To update element values in the current slice of a collection.
For usage notes as well as keywords, parameters, and examples, see "COLLECTION SET".
See the other COLLECTION statements.
To remove elements from the end of collection.
For usage notes as well as keywords, parameters, and examples, see "COLLECTION TRIM".
See the other COLLECTION statements.
To end your current transaction, making permanent all its changes to the database and optionally freeing all resources and disconnecting.
To commit your current transaction, no privileges are necessary.
To manually commit a distributed in-doubt transaction that you originally committed, you must have FORCE TRANSACTION system privilege. To manually commit a distributed in-doubt transaction that was originally committed by another user, you must have FORCE ANY TRANSACTION system privilege.
Always explicitly commit or rollback the last transaction in your program by using the COMMIT or ROLLBACK statement and the RELEASE option. Oracle8i automatically rolls back changes if the program terminates abnormally.
The COMMIT statement has no effect on host variables or on the flow of control in the program. For more information on this statement, see Chapter 3, "Database Concepts".
This example illustrates the use of the embedded SQL COMMIT statement:
EXEC SQL AT sales_db COMMIT RELEASE;
ROLLBACK (Executable Embedded SQL).
SAVEPOINT (Executable Embedded SQL).
To log on to a database.
You must have CREATE SESSION system privilege in the specified database.
A program can have multiple connections, but can only connect once to your default database. For more information on this statement, see "Embedding (OCI Release 7) Calls".
The following example illustrate the use of CONNECT:
EXEC SQL CONNECT :username IDENTIFIED BY :password ;
You can also use this statement in which the value of :userid is the value of :username and :password separated by a "/" such as 'SCOTT/TIGER':
EXEC SQL CONNECT :userid ;
COMMIT (Executable Embedded SQL).
DECLARE DATABASE (Oracle Embedded SQL Directive).
ROLLBACK (Executable Embedded SQL).
To initialize a SQLLIB runtime context that is referenced in an EXEC SQL CONTEXT USE statement.
The runtime context must be declared of type sql_context.
|
context |
Is the SQLLIB runtime context for which memory is to be allocated. |
In a multi-threaded application, execute this function once for each runtime context.
For more information on this statement, see "SQLLIB Extensions for OCI Release 8 Interoperability".
This example illustrates the use of a CONTEXT ALLOCATE statement in a Pro*C/C++ program:
EXEC SQL CONTEXT ALLOCATE :ctx1;
CONTEXT FREE (Executable Embedded SQL Extension).
CONTEXT USE (Oracle Embedded SQL Directive).
EENABLE THREADS (Executable Embedded SQL Extension).
To free all memory associated with a runtime context and place a null pointer in the host program variable.
The CONTEXT ALLOCATE statement must be used to allocate memory for the specified runtime context before the CONTEXT FREE statement can free the memory allocated for it.
|
:context |
The allocated runtime context for which the memory is to be deallocated. |
For more information on this statement, see "SQLLIB Extensions for OCI Release 8 Interoperability".
This example illustrates the use of a CONTEXT FREE statement in a Pro*C/C++ program:
EXEC SQL CONTEXT FREE :ctx1;
CONTEXT ALLOCATE (Executable Embedded SQL Extension).
CONTEXT USE (Oracle Embedded SQL Directive).
ENABLE THREADS (Executable Embedded SQL Extension).
To determine the values of options set by CONTEXT OBJECT OPTION SET for the context in use.
Precompiler option OBJECTS must be set to YES.
| option | DATEFORMAT (format for Date conversion) or DATELANG (language for conversion) |
| host_variable | Output of type STRING, VARCHAR, or CHARZ, in the same order as the option list. |
See "CONTEXT OBJECT OPTION SET".
char EuroFormat[50]; ... EXEC SQL CONTEXT OBJECT OPTION GET DATEFORMAT INTO :EuroFormat ; printf("Date format is %s\n", EuroFormat);
CONTEXT ALLOCATE (Executable Embedded SQL Extension).
CONTEXT FREE (Executable Embedded SQL Extension).
CONTEXT OBJECT OPTION SET (Executable Embedded SQL Ext) .
CONTEXT USE (Oracle Embedded SQL Directive).
To set options to specified values of Date attributes: DATEFORMAT, DATELANG for the context in use.
Precompiler option OBJECTS must be set to YES.
|
option |
DATEFORMAT (format for Date conversion) or DATELANG (language for Date conversion) |
|
expr |
Input of type STRING, VARCHAR, or CHARZ. In the same order as the option list. |
See "CONTEXT OBJECT OPTION GET".
char *new_format = "DD-MM-YYY"; char *new_lang = "French"; ... EXEC SQL CONTEXT OBJECT OPTION SET DATEFORMAT, DATELANG to :new_format, :new_lang;
CONTEXT ALLOCATE (Executable Embedded SQL Extension) .
CONTEXT FREE (Executable Embedded SQL Extension) .
CONTEXT USE (Oracle Embedded SQL Directive).
CONTEXT OBJECT OPTION SET (Executable Embedded SQL Ext)
To instruct the precompiler to use the specified SQLLIB runtime context on subsequent executable SQL statements.
The runtime context specified by the CONTEXT USE directive must be previously declared.
This statement has no effect on declarative statements such as EXEC SQL INCLUDE or EXEC ORACLE OPTION. It works similarly to the EXEC SQL WHENEVER directive in that it affects all executable SQL statements which positionally follow it in a given source file without regard to standard C scope rules.
For more information on this statement, see "SQLLIB Extensions for OCI Release 8 Interoperability".
This example illustrates the use of a CONTEXT USE directive in a Pro*C/C++ embedded SQL program:
EXEC SQL CONTEXT USE :ctx1;
CONTEXT ALLOCATE (Executable Embedded SQL Extension).
CONTEXT FREE (Executable Embedded SQL Extension).
ENABLE THREADS (Executable Embedded SQL Extension).
An ANSI dynamic SQL statement that deallocates a descriptor area to free memory.
The descriptor specified by the DEALLOCATE DESCRIPTOR statement must be previously allocated using the ALLOCATE DESCRIPTOR statement.
Use DYNAMIC=ANSI precompiler option.
For more information on this statement, see "DEALLOCATE DESCRIPTOR".
EXEC SQL DEALLOCATE DESCRIPTOR GLOBAL 'SELDES' ;
ALLOCATE DESCRIPTOR (Executable Embedded SQL).
DESCRIBE (Executable Embedded SQL Extension).
GET DESCRIPTOR (Executable Embedded SQL).
PREPARE (Executable Embedded SQL).
SET DESCRIPTOR (Executable Embedded SQL).
To declare a cursor, giving it a name and associating it with a SQL statement or a PL/SQL block.
If you associate the cursor with an identifier for a SQL statement or PL/SQL block, you must have declared this identifier in a previous DECLARE STATEMENT statement.
You must declare a cursor before referencing it in other embedded SQL statements. The scope of a cursor declaration is global within its precompilation unit and the name of each cursor must be unique in its scope. You cannot declare two cursors with the same name in a single precompilation unit.
You can reference the cursor in the WHERE clause of an UPDATE or DELETE statement using the CURRENT OF syntax, provided that the cursor has been opened with an OPEN statement and positioned on a row with a FETCH statement. For more information on this statement, see "Cursor Usage in Embedded PL/SQL".
This example illustrates the use of a DECLARE CURSOR statement:
EXEC SQL DECLARE emp_cursor CURSOR FOR SELECT ename, empno, job, sal FROM emp WHERE deptno = :deptno FOR UPDATE OF sal;
CLOSE (Executable Embedded SQL).
DECLARE DATABASE (Oracle Embedded SQL Directive).
DECLARE STATEMENT (Embedded SQL Directive).
DELETE (Executable Embedded SQL).
FETCH (Executable Embedded SQL).
OPEN DESCRIPTOR (Executable Embedded SQL).
PREPARE (Executable Embedded SQL).
SELECT (Executable Embedded SQL).
UPDATE (Executable Embedded SQL).
To declare an identifier for a non-default database to be accessed in subsequent embedded SQL statements.
You must have access to a username on the non-default database.
|
db_name |
Is the identifier established for the non-default database. |
You declare a db_name for a non-default database so that other embedded SQL statements can refer to that database using the AT clause. Before issuing a CONNECT statement with an AT clause, you must declare a db_name for the non-default database with a DECLARE DATABASE statement.
For more information on this statement, see "Single Explicit Connections".
This example illustrates the use of a DECLARE DATABASE directive:
EXEC SQL DECLARE oracle3 DATABASE ;
COMMIT (Executable Embedded SQL).
CONNECT (Executable Embedded SQL Extension).
DECLARE CURSOR (Embedded SQL Directive).
DECLARE STATEMENT (Embedded SQL Directive).
DELETE (Executable Embedded SQL).
EXECUTE ... END-EXEC (Executable Embedded SQL Extension).
EXECUTE IMMEDIATE (Executable Embedded SQL).
INSERT (Executable Embedded SQL).
SELECT (Executable Embedded SQL).
UPDATE (Executable Embedded SQL).
To declare an identifier for a SQL statement or PL/SQL block to be used in other embedded SQL statements.
None.
|
AT |
Identifies the database on which the SQL statement or PL/SQL block is declared. The database can be identified by either: &n | |