| Pro*COBOL Precompiler Programmer's Guide Release 8.1.5 A68023-01 |
|
This appendix contains descriptions of both SQL92 embedded SQL statements and directives as well as the Oracle8i embedded SQL extensions. These statements and directives are prefaced in your source code with the keywords, EXEC SQL.
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 contains the following sections:
Embedded SQL statements place DDL, DML, and Transaction Control statements within a procedural language program. Embedded SQL is supported by the Oracle Precompilers. Table F-1 provides a functional summary of the embedded SQL statements and directives.
The type column in Table F-1 is displayed in the format, source/type, where:
| 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.
Trace each diagram from left to right, in the direction shown by the arrows.
Statements keywords appear in UPPER CASE inside rectangles. Type them exactly as shown in the rectangles. Parameters appear in lower case inside ovals. Variables are used for the parameters. Operators, delimiters, and terminators appear inside circles.
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 ...
In all Pro*COBOL EXEC SQL diagrams, each statement is understood to end with the token END-EXEC.
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 EMPCURSOR, then, according to the diagram, the following statement is valid:
EXEC SQL CLOSE EMPCURSOR END-EXEC.
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, instead of traveling down a vertical line, you can continue along the main path:
If there is a database named oracle2, then, according to the diagram, all of the following statements are valid:
EXEC SQL ROLLBACK END-EXEC. EXEC SQL ROLLBACK WORK END-EXEC. EXEC SQL AT ORACLE2 ROLLBACK END-EXEC.
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.
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 :host_string END-EXEC.
The names of Oracle identifiers, 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.
To allocate a cursor variable to be referenced in a PL/SQL block.
A cursor variable (see Chapter 6, "Embedded PL/SQL") of type SQL-CURSOR must be declared before allocating memory for the cursor variable.
Whereas 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:
... 01 EMP-CUR SQL-CURSOR. 01 EMP-REC. ... EXEC SQL ALLOCATE :EMP-CUR END-EXEC. ...
CLOSE (Executable Embedded SQL).
EXECUTE (Executable Embedded SQL).
FETCH (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 END-EXEC.
DESCRIBE DESCRIPTOR (Executable Embedded SQL).
GET DESCRIPTOR (Executable Embedded SQL).
SET DESCRIPTOR (Executable Embedded SQL).
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 Oracle8 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.
... 05 EMP-NAME PIC X(10) VARYING. 05 EMP-NUMBER PIC S9(4) COMP VALUE ZERO. 05 SALARY PIC S9(5)V99 COMP-3 VALUE ZERO. ... 05 D-EMP-NUMBER PIC 9(4). ... ACCEPT D-EMP-NUMBER. EXEC SQL CALL mypkge.getsal(:EMP-NUMBER, :D-EMP-NUMBER, :EMP-NAME) INTO :SALARY END-EXEC. ...
None
To disable a cursor, freeing the resources acquired by opening the cursor, and releasing parse locks.
The cursor or cursor variable must be open and MODE=ANSI.
|
cursor |
The cursor to be closed. |
|
cusor_variable |
The 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 14, "Precompiler Options".
This example illustrates the use of the CLOSE statement:
EXEC SQL CLOSE EMP-CUR END-EXEC.
DECLARE CURSOR (Embedded SQL Directive).
OPEN (Executable Embedded SQL).
PREPARE (Executable Embedded SQL).
To end your current transaction, making permanent all its changes to the database and optionally freeing all resources and disconnecting from the database server.
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 "Using the COMMIT Statement".
This example illustrates the use of the embedded SQL COMMIT statement:
EXEC SQL AT SALESDB COMMIT RELEASE END-EXEC.
ROLLBACK (Executable Embedded SQL).
SAVEPOINT (Executable Embedded SQL).
To logon to an Oracle8i 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 "Advanced Connection Options".
The following example illustrate the use of CONNECT:
EXEC SQL CONNECT :USERNAME IDENTIFIED BY :PASSWORD END-EXEC.
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 END-EXEC.
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 |
The SQLLIB runtime context for which memory is to be allocated. |
For more information on this statement, see "User-Specified Runtime Contexts".
This example illustrates the use of a CONTEXT ALLOCATE statement in a Pro*C/C++ embedded SQL program:
EXEC SQL CONTEXT ALLOCATE :ctx1 END-EXEC.
CONTEXT FREE (Executable Embedded SQL Extension).
CONTEXT USE (Oracle Embedded SQL Directive).
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 "User-Specified Runtime Contexts".
This example illustrates the use of a CONTEXT FREE statement in a Pro*C/C++ embedded SQL program:
EXEC SQL CONTEXT FREE :ctx1 END-EXEC.
CONTEXT ALLOCATE (Executable Embedded SQL Extension).
CONTEXT USE (Oracle Embedded SQL Directive).
To instruct the precompiler to use the specified SQLLIB runtime context on subsequent executable SQL statementsPrerequisites
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 "User-Specified Runtime Contexts".
This example illustrates the use of a CONTEXT USE directive in a Pro*C/C++ program:
EXEC SQL CONTEXT USE :ctx1 END-EXEC.
CONTEXT ALLOCATE (Executable Embedded SQL Extension).
CONTEXT FREE (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' END-EXEC.
ALLOCATE DESCRIPTOR (Executable Embedded SQL).
DESCRIBE DESCRIPTOR (Executable Embedded SQL).
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 "WITH HOLD Clause in DECLARE CURSOR Statements".
This example illustrates the use of a DECLARE CURSOR statement:
EXEC SQL DECLARE EMPCURSOR CURSOR FOR SELECT ENAME, EMPNO, JOB, SAL FROM EMP WHERE DEPTNO = :DEPTNO FOR UPDATE OF SAL END-EXEC.
CLOSE (Executable Embedded SQL).
DECLARE DATABASE (Oracle Embedded SQL Directive).
DECLARE STATEMENT (Embedded SQL Directive).
DELETE (Executable Embedded SQL).
FETCH (Executable Embedded SQL).
OPEN (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 |
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 "Using Username/Password".
This example illustrates the use of a DECLARE DATABASE directive:
EXEC SQL DECLARE ORACLE3 DATABASE END-EXEC.
COMMIT (Executable Embedded SQL)
CONNECT (Executable Embedded SQL Extension).
DECLARE CURSOR (Embedded SQL Directive).
DECLARE STATEMENT (Embedded SQL Directive).
DELETE (Executable Embedded SQL).
EXECUTE (Executable Embedded SQL).
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.
You must declare an identifier for a SQL statement or PL/SQL block with a DECLARE STATEMENT statement only if a DECLARE CURSOR statement referencing the identifier appears physically (not logically) in the embedded SQL program before the PREPARE statement that parses the statement or block and associates it with its identifier.
The scope of a statement declaration is global within its precompilation unit, like a cursor declaration. For more information on this statement, see "DECLARE".
This example illustrates the use of the DECLARE STATEMENT statement:
EXEC SQL AT REMOTEDB DECLARE MYSTATEMENT STATEMENT END-EXEC. EXEC SQL PREPARE MYSTATEMENT FROM :MY-STRING END-EXEC. EXEC SQL EXECUTE MYSTATEMENT END-EXEC.
In this example from a Pro*COBOL embedded SQL program, the DECLARE STATEMENT statement is required because the DECLARE CURSOR statement precedes the PREPARE statement:
EXEC SQL DECLARE MYSTATEMENT STATEMENT END-EXEC. EXEC SQL DECLARE EMPCURSOR CURSOR FOR MYSTATEMENT END-EXEC. EXEC SQL PREPARE MYSTATEMENT FROM :MY-STRING END-EXEC. ...
CLOSE (Executable Embedded SQL).
DECLARE DATABASE (Oracle Embedded SQL Directive).
FETCH (Executable Embedded SQL).
OPEN (Executable Embedded SQL).
PREPARE (Executable Embedded SQL).
To define the structure of a table or view, including each column's datatype, default value, and NULL or NOT NULL specification for semantic checking by the precompiler when option SQLCHECK=SEMANTICS (or FULL).
None.
|
table |
The name of the declared table. |
|
column |
A column of the table. |
|
datatype |
The datatype of a column. For information on Oracle8i datatypes, see "The Oracle8i Datatypes". |
|
NOT NULL |
Specifies that a column cannot contain nulls. |
Datatypes can only use integers (not expressions) for length, precision, scale. For more information on using this statement, see "Specifying SQLCHECK=SEMANTICS" on page E-3.
The following statement declares the PARTS table with the PARTNO, BIN, and QTY columns:
EXEC SQL DECLARE PARTS TABLE (PARTNO NUMBER NOT NULL, BIN NUMBER, QTY NUMBER) END-EXEC.
None.
To remove rows from a table or from a view's base table.
For you to delete rows from a table, the table must be in your own schema or you must have DELETE privilege on the table.
For you to delete rows from the base table of a view, the owner of the schema containing the view must have DELETE privilege on the base table. Also, if the view is in a schema other than your own, you must be granted DELETE privilege on the view.
The DELETE ANY TABLE system privilege also allows you to delete rows from any table or any view's base table.
where the DML Returning clause is:
Keywords and Parameters
|
AT |
Identifies the database to which the DELETE statement is issued. The database can be identified by either: |
|
|
|
db_name |
A database identifier declared in a previous DECLARE DATABASE statement. |
|
|
host_variable |
A host variable whose value is a previously declared db_name. |
|
|
If you omit this clause, the DELETE statement is issued to your default database. |
|
|
integer |
Limits the number of times the statement is executed if the WHERE clause contains array host variables. If you omit this clause, Oracle8i executes the statement once for each component of the smallest array. |
|
|
schema |
The schema containing the table or view. If you omit schema, Oracle8i assumes the table or view is in your own schema. |
|
|
table view |
The name of a table from which the rows are to be deleted. If you specify view, Oracle8i deletes rows from the view's base table. |
|
|
dblink |
The complete or partial name of a database link to a remote database where the table or view is located. For information on referring to database links, see Chapter 2 of the Oracle8i SQL Reference. You can only delete rows from a remote table or view if you are using Oracle8i with the distributed option. If you omit dblink, Oracle8 assumes that the table or view is located on the local database. |
|
|
part_name |
Name of partition in the table |
|
|
alias |
The alias assigned to the table. Aliases are generally used in DELETE statements with correlated queries. |
|
|
WHERE |
Specifies which rows are deleted: |
|
|
|
condition |
Deletes only rows that satisfy the condition. This condition can contain host variables and optional indicator variables. See the syntax description of condition in the Oracle8i SQL Reference. |
|
|
|
Deletes only the row most recently fetched by the cursor. The cursor cannot be associated with a SELECT statement that performs a join, unless its FOR UPDATE clause specifically locks only one table. |
|
|
If you omit this clause entirely, Oracle8i deletes all rows from the table or view. |
|
|
DML returning clause |
See "DML Returning Clause" for a discussion. |
|
The host variables in the WHERE clause must be either all scalars or all arrays. If they are scalars, Oracle8i executes the DELETE statement only once. If they are arrays, Oracle8i executes the statement once for each set of array components. Each execution may delete zero, one, or multiple rows.
Array host variables in the WHERE clause can have different sizes. In this case, the number of times Oracle8i executes the statement is determined by the smaller of the following values:
If no rows satisfy the condition, no rows are deleted and the SQLCODE returns a NOT_FOUND condition.
The cumulative number of rows deleted is returned through the SQLCA. If the WHERE clause contains array host variables, this value reflects the total number of rows deleted for all components of the array processed by the DELETE statement.
If no rows satisfy the condition, Oracle8i returns an error through the SQLCODE of the SQLCA. If you omit the WHERE clause, Oracle8i raises a warning flag in the fifth component of SQLWARN in the SQLCA. For more information on this statement and the SQLCA, see "Using the SQL Communications Area".
You can use comments in a DELETE statement to pass instructions, or hints, to the Oracle8i optimizer. The optimizer uses hints to choose an execution plan for the statement. For more information on hints, see Oracle8i Tuning.
This example illustrates the use of the DELETE statement within a Pro*COBOL program:
EXEC SQL DELETE FROM EMP WHERE DEPTNO = :DEPTNO AND JOB = :JOB END-EXEC. EXEC SQL DECLARE EMPCURSOR CURSOR FOR SELECT EMPNO, COMM FROM EMP END-EXEC. EXEC SQL OPEN EMPCURSOR END-EXEC. EXEC SQL FETCH EMPCURSOR INTO :EMP-NUMBER, :COMMISSION END-EXEC. EXEC SQL DELETE FROM EMP WHERE CURRENT OF EMPCURSOR END-EXEC.
DECLARE DATABASE (Oracle Embedded SQL Directive).
DECLARE STATEMENT (Embedded SQL Directive).
To initialize a descriptor to hold descriptions of host variables for an Oracle dynamic SQL statement or PL/SQL block.
You must have prepared the SQL statement or PL/SQL block in a previous embedded SQL PREPARE statement.
You must issue a DESCRIBE statement before manipulating the bind or select descriptor within an embedded SQL program.
You cannot describe both input variables and output variables into the same descriptor.
The number of variables found by a DESCRIBE statement is the total number of placeholders in the prepare SQL statement or PL/SQL block, rather than the total number of uniquely named placeholders. For more information on this statement, see "The DESCRIBE Statement".
This example illustrates the use of the DESCRIBE statement in a Pro*COBOL embedded SQL program:
EXEC SQL PREPARE MYSTATEMENT FROM :MY-STRING END-EXEC. EXEC SQL DECLARE EMPCURSOR FOR SELECT EMPNO, ENAME, SAL, COMM FROM EMP WHERE DEPTNO = :DEPT-NUMBER END-EXEC. EXEC SQL DESCRIBE BIND VARIABLES FOR MYSTATEMENT INTO BINDDESCRIPTOR END-EXEC. EXEC SQL OPEN EMPCURSOR USING BINDDESCRIPTOR END-EXEC. EXEC SQL DESCRIBE SELECT LIST FOR MY-STATEMENT INTO SELECTDESCRIPTOR END-EXEC. EXEC SQL FETCH EMPCURSOR INTO SELECTDESCRIPTOR END-EXEC.
PREPARE (Executable Embedded SQL).
Used to obtain information about an ANSI SQL statement, and to store it in a descriptor.
You must have prepared the SQL statement in a previous embedded SQL PREPARE statement.
Use DYNAMIC=ANSI precompiler option. Only COUNT and NAME are implemented for the INPUT descriptor.
The number of variables found by a DESCRIBE statement is the total number of place-holders in the prepare SQL statement or PL/SQL block, rather than the total number of uniquely named place-holders. For more information on this statement, see Chapter 13, "Oracle Dynamic SQL".
EXEC SQL PREPARE s FROM :my_stament END-EXEC. EXEC SQL DESCRIBE INPUT s USING DESCRIPTOR 'in' END-EXEC.
ALLOCATE DESCRIPTOR (Executable Embedded SQL).
DEALLOCATE DESCRIPTOR (Embedded SQL Statement).
GET DESCRIPTOR (Executable Embedded SQL).
PREPARE (Executable Embedded SQL).
SET DESCRIPTOR (Executable Embedded SQL).
To embed an anonymous PL/SQL block into an Oracle Pro*COBOL program.
None.
|
AT |
||