Iso-Iec 9075-5

ANSI/ISO/IEC International Standard (IS)
Database Language SQL — Part 5: Host Language Bindings (SQL/Bindings)

«Part 5»
September 1999
ISO/IEC 9075-5:1999 (E)
Contents Page
Foreword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2 Normative references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3 Definitions, notations, and conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3 Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3.1 Use of terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3.1.1 Other terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3.2 Relationships to other parts of ISO/IEC 9075 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3.2.1 Clause, Subclause, and Table relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.4 Object identifier for Database Language SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1 Catalogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2 SQL-client modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3 SQL-invoked routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.4 Locators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.5 Cursors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.6 SQL-statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.6.1 Classes of SQL-statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.6.2 SQL-statements classified by function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.6.3 SQL-statements and transaction states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.6.4 Embeddable SQL-statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.6.5 Preparable and immediately executable SQL-statements . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.6.6 Directly executable SQL-statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.7 Standard programming languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.8 Embedded syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.9 SQL dynamic statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.10 Direct invocation of SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.11 Privileges and roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.12 SQL-transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
ii Host Language Bindings (SQL/Bindings)

©ISO/IEC ISO/IEC 9075-5:1999 (E)
4.13 SQL-connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.14 SQL-sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.15 Client-server operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5 Lexical elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.1 <token> and <separator> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2 <literal> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.3 Names and identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6 Scalar expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.1 <value specification> and <target specification> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.2 <column reference> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.3 <interval value expression> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
7 Query expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
7.1 <table reference> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
7.2 <query specification> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
8 Additional common elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

8.1 <routine invocation> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
9 Data assignment rules and routine determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

9.1 Retrieval assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
9.2 Store assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
9.3 Data types of results of aggregations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
10 Schema definition and manipulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

10.1 <check constraint definition> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
10.2 <view definition> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
10.3 <assertion definition> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
10.4 <trigger definition> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
10.5 <SQL-invoked routine> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
11 SQL-client modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
11.1 <SQL-client module definition> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
11.2 Calls to an <externally-invoked procedure> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
11.3 <SQL procedure statement> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
12 Data manipulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
12.1 <select statement: single row> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
12.2 <free locator statement> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
13 Transaction management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
13.1 <commit statement> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Contents iii
ISO/IEC 9075-5:1999 (E) ©ISO/IEC
14 Session management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
14.1 <set catalog statement> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
14.2 <set schema statement> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
14.3 <set names statement> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
14.4 <set path statement> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
14.5 <set transform group statement> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
15 Dynamic SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
15.1 Description of SQL descriptor areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
15.2 <allocate descriptor statement> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
15.3 <deallocate descriptor statement> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
15.4 <get descriptor statement> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
15.5 <set descriptor statement> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
15.6 <prepare statement> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
15.7 <deallocate prepared statement> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
15.8 <describe statement> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
15.9 <input using clause> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
15.10 <output using clause> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
15.11 <execute statement> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
15.12 <execute immediate statement> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
15.13 <dynamic declare cursor> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
15.14 <allocate cursor statement> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
15.15 <dynamic open statement> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
15.16 <dynamic fetch statement> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
15.17 <dynamic single row select statement> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
15.18 <dynamic close statement> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
15.19 <dynamic delete statement: positioned> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
15.20 <dynamic update statement: positioned> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
15.21 <preparable dynamic delete statement: positioned> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
15.22 <preparable dynamic update statement: positioned> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
16 Embedded SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

16.1 <embedded SQL host program> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
16.2 <embedded exception declaration> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
16.3 <embedded SQL Ada program> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
16.4 <embedded SQL C program> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
16.5 <embedded SQL COBOL program> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
16.6 <embedded SQL Fortran program> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
16.7 <embedded SQL MUMPS program> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
16.8 <embedded SQL Pascal program> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
16.9 <embedded SQL PL/I program> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
17 Direct invocation of SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

17.1 <direct SQL statement> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
17.2 <direct select statement: multiple rows> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
iv Host Language Bindings (SQL/Bindings)

18 Diagnostics management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

18.1 <get diagnostics statement> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
19 Definition Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

19.1 SQL_LANGUAGES base table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
20 Status codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

20.1 SQLSTATE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
21 Conformance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
21.1 General conformance requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
21.2 Claims of conformance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Annex A SQL Conformance Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Annex B Implementation-defined elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Annex C Implementation-dependent elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Annex D Deprecated features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Annex E Incompatibilities with ISO/IEC 9075:1992 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Annex F SQL feature and package taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Contents v
TABLES
Tables Page
1 Clause, Subclause, and Table relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Data types of <key word>s used in the header of SQL descriptor areas . . . . . . . . . . . . . . 75
3 Data types of <key word>s used in SQL item descriptor areas . . . . . . . . . . . . . . . . . . . . . 75
4 Codes used for SQL data types in Dynamic SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5 Codes associated with datetime data types in Dynamic SQL . . . . . . . . . . . . . . . . . . . . . . . 78
6 Codes used for <interval qualifier>s in Dynamic SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
7 Codes used for input/output SQL parameter modes in Dynamic SQL . . . . . . . . . . . . . . . . 79
8 <identifier>s for use with <get diagnostics statement> . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
9 SQL-statement codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
10 SQLSTATE class and subclass values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
11 Implied feature relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
12 SQL/Bindings feature taxonomy and definition for Core SQL . . . . . . . . . . . . . . . . . . . . . . 228
13 SQL/Bindings feature taxonomy for features outside Core SQL . . . . . . . . . . . . . . . . . . . . . 228
vi Host Language Bindings (SQL/Bindings)

Foreword
(This foreword is not a part of American National Standard ANSI/ISO/IEC 9075-5:1999.)

This Standard (American National Standard ANSI/ISO/IEC 9075-5:1999, Information Systems —
Database Language — SQL — Part 5: Host Language Bindings (SQL/Bindings)), replaces in part
American National Standard X3.135-1992.
This American National Standard specifies the host language bindings for Database Language SQL
and facilities for dynamically processing SQL language and for direct invocation of SQL language.
ANSI/ISO/IEC 9075 consists of the following parts, under the general title Information Systems —
Database Language — SQL:
— Part 1: Framework (SQL/Framework)
— Part 2: Foundation (SQL/Foundation)
— Part 3: Call-Level Interface (SQL/CLI)
— Part 4: Persistent Stored Modules (SQL/PSM)
— Part 5: Host Language Bindings (SQL/Bindings)
This American National Standard contains six Informative Annexes that are not considered part of
the Standard:
— Annex A (informative): SQL Conformance Summary.
— Annex B (informative): Implementation-defined elements.
— Annex C (informative): Implementation-dependent elements.
— Annex D (informative): Deprecated features.
— Annex E (informative): Incompatibilities with ISO/IEC 9075:1992.
— Annex F (informative): SQL feature and package taxonomy.
Requests for interpretation, suggestions for improvement or addenda, or defect reports are welcome.
They should be sent to the National Committee for Information Technology Standards (NCITS),
1250 Eye Street, NW, Suite 200, Washington, DC 20005.
This Standard was processed and approved for submittal to ANSI by NCITS. Committee approval
of this Standard does not necessarily imply that all committee members voted for approval. At the
time that it approved this Standard, NCITS had the following members:
NCITS Chairman NCITS Vice Chair NCITS Secretary

Ms. Karen Higgenbottom Mr. Dave Michael Ms. Monica Vago
*Non-Response **Abstain
Foreword vii
PRODUCERS=13
Apple Computer Inc.
Mr. David Michael [P]
M/S 301-4F
1 INFINITE LOOP
CUPERTINO CA 95014
+1.408.862.5451
Fax: +1.408.974.2691
deek@apple.com
Mr. Jerry Kellenbenz [A]
M/S 301-4F
1 INFINITE LOOP
CUPERTINO CA 95014
+1.408.974.7341
Fax: +1.408.974.2691
jerryk@taurus.apple.com
Bull HN Information Systems Inc.
Mr. Randall Kilmartin [P]
M/S B58
13430 N. BLACK CANYON HIGHWAY
PHOENIX AZ 85029
+1.602.862.4905
Fax: +1.602.862.3285
randy.kilmartin@bull.com
Compaq Computer Corporation
Mr. Scott Jameson [P]
M/S AKO2-3/D10
50 NAGOG PARK
ACTON MA 01720
+1.508.264.7468
Fax: +1.508.264.7656
scott.jameson@digital.com
Mr. Stephen Heil [A]
M/S 110605
20555 SH249
HOUSTON TX 77269-2000
+1.281.518.0781
Fax: +1.281.518.3519
stephen.heil@compaq.com
Hewlett-Packard Company
Ms. Karen Higginbottom [P]
M/S 43UC
19420 HOMESTEAD ROAD
CUPERTINO CA 95014
+1.408.447.3274
Fax: +1.408.447.2247
higginbottom@cup.hp.com
viii Host Language Bindings (SQL/Bindings)

Ms. Wendy Fong [A]

M/S 47U-10
19447 PRUNERIDGE AVENUE
CUPERTINO CA 95014
+1.408.447.4463
Fax: +1.408.447.3995
Wendy_Fong@HP-Cupertino-notes2.om.com
Hitachi American Ltd.
Mr. John Neumann [P]
43533 GOLDEN MEADOW CIRCLE
ASHBURN VA 22011
+1.703.729.4858
Fax: +1.703.729.0304
openstrat@aol.com
Mr. Hal Miyamoto [A]
MS 730
2000 SIERRA POINT PKWY
BRISBANE CA 94005-1835
+1.650.244.7218
Fax: +1.650.244.7250
miyamoth@halsp.hitachi.com
IBM Corporation
Ronald F. Silletti [P]
Program Director of Standards
Intellectual Property & Licensing
IBM Corporation
NORTH CASTLE DRIVE
ARMONK, NY 10504
+1.914.765.4373
Fax: +1.914.765.4420
silletti@us.ibm.com
Mr. Joel Urman [A]
IBM Corporation
M/S NC113, Room 1B111
NORTH CASTLE DRIVE
ARMONK, NY 10504-1785
+1.914.765.4392
Fax: +1.914.765.4420
joelu@us.ibm.com
Lucent Technologies Inc.
Mr. Herbert Bertine [P]
ROOM 4K-316
101 CRAWFORDS CORNER RD
HOLMDEL NJ 07733-3030
+1.908.949.4022
Fax: +1.908.949.1196
hbertine@lucent.com
Foreword ix
Mr. Tom Rutt [A]

ROOM 4L-308
101 CRAWFORD CORNER ROAD
+1.908.949.7862
Fax: +1.908.949.1196
ter@holta.ho.lucent.com
Microsoft Corp.
Mr. Mark Ryland [P]
ONE MICROSOFT WAY
REDMOND WA 98052
+1.703.757.7430
Fax: +1.425.936.7329
markry@microsoft.com
Mr. John Montgomery [A]
ONE MICROSOFT WAY
REDMOND WA 98072
+1.425.705.2921
Fax: +1.425.936.7329
johnmont@microsoft.com
Panasonic Technologies Inc.
Mr. Judson Hofmann [P]
3RD FLOOR
2 RESEARCH WAY
PRINCETON NJ 08540-6628
+1.609.734.7589
Fax: +1.609.987.0483
hofmann@research.panasonic.com
Mr. Terry J. Nelson [A]
3RD FLOOR
2 RESEARCH WAY
PRINCETON NJ 08540
+1.609.734.7324
Fax: +1.609.987.8827
tnelson@@research.panasonic.com
Sony Electronics Inc.
Mr. Masataka Ogawa [P]
MD: SJ-3B2
3300 ZANKER ROAD
SAN JOSE CA 95134-1940
+1.408.955.5091
Fax: +1.408.955.5066
Masataka_Ogawa@asd.sel.sony.com
Mr. Michael Deese [A]
MASS STORAGE DIV
4845 PEARL EAST CIRCLE
BOULDER CO 80301
+1.303.415.5821
Fax: +1.303.447.8198
mike_deese@ccmail.sgo.sony.com
x Host Language Bindings (SQL/Bindings)

Sun Microsystems Inc.

Mr. Carl Cargill [P]
901 SAN ANTONIO ROAD
MS UMPK 15-214
PALO ALTO CA 94303-6445
+1.650.786.8527
Fax: +1.650.786.6445
carl.cargill@eng.sun.com
Mr. Ken Urquhart [A]
901 SAN ANTONIO ROAD
MS UCUP 02-204
PALO ALTO CA 94303-4900
+1.408.343.1889
ken.urquhart@sun.com
Unisys Corporation
Mr. Arnold F. Winkler [P]
M/S B-254
2450 SWEDESFORD ROAD
+1.610.993.7305
+1.610.695.5473
arnold.winkler@unisys.com
Mr. Stephen Oksala [A ]
M/S 203H
2476 SWEDESFORD ROAD
PAOLI PA 19301
+1.610.993.7304
Fax: +1.610.695.4700
oksala@unisys.com
Xerox Corporation
Ms. Jean Baroness [P]
1401 H STREET NW
SUITE 200
WASHINGTON DC 20005
+1.202.414.1205
Fax: +1.202.414.1217
jean_m_baronas@co.xerox.com
Ms. Kathleen O’Reilly [A]
1401 H STREET NW
SUITE 200
WASHINGTON DC 20005
+1.202.414.1295
Fax: +1.202.414.1217
kathleen_m_o’reilly@co.xerox.com
CONSUMERS=9
Aonix
Mr. Alexander Nawrocki[P]
5040 SHOREHAM PLACE
SAN DIEGO CA 92122
+1.619.824.0271
Foreword xi
Fax:
Rocky@sd.aonix.com
AT&T
Mr. Thomas Frost [P]
ROOM 1A29
20 INDEPENDENCE BLVD
WARREN NJ 07059
+1.908.580.6238
Fax: +1.908.580.6881
tfrost@att.com
Mr. Paul Bartoli [A]
ROOM IL-334
101 CRAWFORDS CORNER ROAD
+1.908.949.5965
Fax: +1.908.949.8569
Bartoli@att.com
Omron Corporation
Mr. Tak Natsume [P]
#800
160 W SANTA CLARA STREET
SAN JOSE CA 95113
+1.408.271.5211
Fax: +1.408.271.1721
Natsume@omron.org
Perennial
Mr. Barry Hedquist [P]
SUITE 210
4699 OLD IRONSIDES DRIVE
SANTA CLARA, CA 95054
+1.408.748.2900
Fax: +1.408.748.2909
beh@peren.com
Plum Hall, Inc.
Mr. Thomas Plum [P]
3 WAIHONA
Box 44610
KAMUELA HI 96743
+1.808.882.1255
Fax: +1.808.882.1556
Lana@plumhall.com
Share Inc.
Mr. Dave Thewlis [P]
2301 C STREET
EUREKA, CA 95501-4108
+1.707.442.0547
Fax: +1.707.442.9342
dthewlis@dcta.com
xii Host Language Bindings (SQL/Bindings)

Sybase, Inc.
Mr. Billy Ho [P]
1650 65th STREET
EMERYVILLE CA 94608
+1.510.922.4416
billy.ho@sybase.com
US Department of Defense/DISA
Mr. Russ Richards [P]
10701 PARKRIDGE BLVD
RESTON VA 20191-4357
+1.703.735.3552
Fax: +1.703.735.3257
richarlr@ncr.disa.mil
Dr. Doris Bernardini [A]
PO BOX 2309
RESTON VA 20195-0309
+1.703.735.3566
Fax: +1.703.735.3257
bernardd@ncr.disa.mi
US Department of Energy
Mr. Bruce White [P]
MA-43 GERMANTOWN BUILDING
19901 GERMANTOWN ROAD
GERMANTOWN MD 20874-1290
+1.301.903.6977
Fax: +1.301.903.4101
bruce.white@hq.doe.gov
Ms. Carol Blackston [A]
MA-43 GERMANTOWN BUILDING
19901 GERMANTOWN ROAD
GERMANTOWN MD 20874-1290
+1.301.903.4294
Fax: +1.301.903.4101
carol.blackston@hq.doe.gov
GENERAL INTEREST=2
Institute for Certification of Computer Professionals
Mr. Kenneth M. Zemrowski [P]
C/O ISN/TRW SUITE C-65
1280 MARYLAND AVENUE SW
WASHINGTON DC 20024
+1.202.479.0085 X225
Fax: +1.202.479.4187
kenneth.zemrowski@trw.com
Mr. Tom Kurihara [A]
TKSTDS & ASSOCIATES, INC.
5713 6TH STREET, NORTH
ARLINGTON, VA 22205-1013
+1.703.516.9650
Fax: +1.703.516.4688
Foreword xiii
tkstds@mindspring.com
National Institute of Standards & Technology
Mr. Michael Hogan [P]
BUILDING 820
ROOM 634
GAITHERSBURG MD 20899-0999
+1.301.975.2926
Fax: +1.301.948.1784
m.hogan@nist.gov
Mr. Bruce K. Rosen [A]
BLDG 820
ROOM 562
GAITHERSBURG MD 20899
+1.301.975.3345
Fax: +1.301.926.3696
bruce.rosen@nist.gov
Mr. William LaPlant Jr. [A]
4312 BIRCHLAKE COURT
ALEXANDRIA VA 22309
+1.301.457.4887
Fax: +1.301.457.2299
bill.laplant@census.gov
American National Standard ANSI/ISO/IEC 9075-1:1999 was prepared by Technical Committee
Group NCITS H2, Database, working under the auspices of Accredited National Standards
Committee NCITS (National Committee for Information Technology Standards). Technical
Committee H2 on Database, which developed this Standard, had the following members:
Donald R. Deutsch, Chair
Bruce M. Horowitz, Vice-Chair
Krishna Kulkarni, International Representative
Barry D. Vickers, Treasurer
Michael M. Gorman, Secretary
Jim Melton, Editor
Chuck Campbell Andrew Eisenberg Chris Farrar

Keith Hare Doug Inkster Tom Julien
R. Michael Lefler Michael Pantaleo Frank Pellow
Janet Prichard William E. Raab Bruce K. Rosen
Paul Scarponcini Herb Sutter Bie Tie
Fred Zemke
xiv Host Language Bindings (SQL/Bindings)

Others holding Technical Committee H2 membership while the committee wa developing this
standard were the following:
Dean A. Anderson Mark Ashworth James Barnette
John Barney Daniel Barton Aime Bayle
David Beech Richard Boyne Andras Budinszky
Amelia Carlson Joe Celko Arthur Culbertson
Judy Dillman T. N. Doraiswamy Shel Finkelstein
Donna Fisher Jeffrey Fried Barry Fritchman
Leonard J. Gallagher Kyle W. Geiger Jim Graham
Tom Harwood Wei Hong Ken Jacobs
Phil Jones Bill Kelley William Kent
William J. Koster Vince Kowalski Melissa LoBiando
Fran Lynch Nelson Mattos Jeff Mischkinsky
M. Reza Monajjemi Santanu Mukhopadhyay Phil Nelson
Kee Ong Emmanuel Onuegbe Dipak Patel
Richard Pedigo Ed Peeler Paul Perkovic
Tom Perry Sherry Petersen William Phillips
Michael Pizzo Mahesh Rao George Raudabaugh
Ed Reynolds Jeff Richey John Sadd
Chander Sarna Robert Saunders David Schnepper
Scott Schnier Christine Semeniuk Larry Settle
Phil Shaw Maurice L. Smith Madhukar Thakur
Yang Tsouya Michael Ubell Murali Venkatrao
Andrew Wade Ken Wilner David Yach
Robert Zeek Hans Zeller
Foreword xv
Introduction
The organization of this part of ISO/IEC 9075 is as follows:
1) Clause 1, ‘‘Scope’’, specifies the scope of this part of ISO/IEC 9075.
2) Clause 2, ‘‘Normative references’’, identifies additional standards that, through reference in this
part of ISO/IEC 9075, constitute provisions of this part of ISO/IEC 9075.
3) Clause 3, ‘‘Definitions, notations, and conventions’’, defines the notations and conventions used
in this part of ISO/IEC 9075.
4) Clause 4, ‘‘Concepts’’, presents concepts used in the definition of Persistent SQL modules.
5) Clause 5, ‘‘Lexical elements’’, defines the lexical elements of the language.
6) Clause 6, ‘‘Scalar expressions’’, defines the elements of the language that produce scalar values.
7) Clause 7, ‘‘Query expressions’’, defines the elements of the language that produce rows and
tables of data.
8) Clause 8, ‘‘Additional common elements’’, defines additional language elements that are used in
various parts of the language.
9) Clause 9, ‘‘Data assignment rules and routine determination’’, specifies the rules for assignments
that retrieve data from or store data into SQL-data, and formation rules for set operations.
10) Clause 10, ‘‘Schema definition and manipulation’’, defines facilities for creating and managing a
schema.
11) Clause 11, ‘‘SQL-client modules’’, defines modules and procedures.
12) Clause 12, ‘‘Data manipulation’’, defines the data manipulation statements.
13) Clause 13, ‘‘Transaction management’’, defines the SQL-transaction management statements.
14) Clause 14, ‘‘Session management’’, defines the SQL-session management statements.
15) Clause 15, ‘‘Dynamic SQL’’, defines the SQL dynamic statements.
16) Clause 16, ‘‘Embedded SQL’’, defines the host language embeddings.
17) Clause 17, ‘‘Direct invocation of SQL’’, defines direct invocation of SQL language.
18) Clause 18, ‘‘Diagnostics management’’, defines the diagnostics management facilities.
19) Clause 19, ‘‘Definition Schema’’, defines base tables on which the viewed tables containing
schema information depend.
20) Clause 20, ‘‘Status codes’’, defines values that identify the status of the execution of SQL-
statements and the mechanisms by which those values are returned.
21) Clause 21, ‘‘Conformance’’, defines the criteria for conformance to this part of ISO/IEC 9075.
Introduction xvii
22) Annex A, ‘‘SQL Conformance Summary’’, is an informative Annex. It summarizes the confor-
mance requirements of the SQL language.
23) Annex B, ‘‘Implementation-defined elements’’, is an informative Annex. It lists those features

for which the body of this part of ISO/IEC 9075 states that the syntax, the meaning, the
returned results, the effect on SQL-data and/or schemas, or any other behavior is partly or
wholly implementation-defined.
24) Annex C, ‘‘Implementation-dependent elements’’, is an informative Annex. It lists those features

for which the body of this part of ISO/IEC 9075 states that the syntax, the meaning, the
returned results, the effect on SQL-data and/or schemas, or any other behavior is partly or
wholly implementation-dependent.
25) Annex D, ‘‘Deprecated features’’, is an informative Annex. It lists features that the responsible
Technical Committee intends will not appear in a future revised version of ISO/IEC 9075.
26) Annex E, ‘‘Incompatibilities with ISO/IEC 9075:1992’’, is an informative Annex. It lists the
incompatibilities between this version of ISO/IEC 9075 and ISO/IEC 9075:1992.
27) Annex F, ‘‘SQL feature and package taxonomy’’, is an informative Annex. It identifies features
of the SQL language specified in this part of ISO/IEC 9075 by a numeric identifier and a short
descriptive name. This taxonomy is used to specify conformance to Core SQL and may be used
to develop other profiles involving the SQL language.
In the text of this part of ISO/IEC 9075, Clauses begin a new odd-numbered page, and in Clause 5,
‘‘Lexical elements’’, through Clause 21, ‘‘Conformance’’, Subclauses begin a new page. Any resulting
blank space is not significant.
xviii Host Language Bindings (SQL/Bindings)

INTERNATIONAL STANDARD ©ISO/IEC ISO/IEC 9075-5:1999 (E)
Information technology — Database languages — SQL —

Part 5:
Host Language Bindings (SQL/Bindings)
1 Scope
This part of ISO/IEC 9075 specifies:
— Syntax for embedding SQL-statements in a compilation unit that otherwise conforms to the
standard for a particular programming language (host language).
— How an equivalent compilation unit may be derived that conforms to the particular program-
ming language standard. In that equivalent compilation unit, each embedded SQL-statement
has been replaced by one or more statements in the host language, some of which invoke an
SQL externally-invoked procedure that, when executed, has an effect equivalent to executing
the SQL-statement.
— Syntax for direct invocation of SQL-statements.
— SQL language to support dynamic preparation and execution of SQL-statements.
Scope 1
2 Host Language Bindings (SQL/Bindings)

2 Normative references
Insert this paragraph The following standards contain provisions that, through reference in this text,
constitute provisions of this part of ISO/IEC 9075. At the time of publication, the editions indicated
were valid. All standards are subject to revision, and parties to agreements based on this part of
ISO/IEC 9075 are encouraged to investigate the possibility of applying the most recent editions
of the standards indicated below. Members of IEC and ISO maintain registers of currently valid
International Standards.
ISO/IEC 1539-1:1997, Information technology — Programming languages — Fortran — Part 1:
Base language.
ISO 1989:1985, Programming languages — COBOL.

(Endorsement of ANSI X3.23-1985).
ISO 6160:1979, Programming languages — PL/I

(Endorsement of ANSI X3.53-1976).
ISO/IEC 7185:1990, Information technology — Programming languages—Pascal.
ISO 8652:1995, Information technology — Programming languages — Ada.
ISO/IEC 9075-1, Information technology — Database languages — SQL — Part 1: Framework

(SQL/Framework).
ISO/IEC 9075-2, Information technology — Database languages — SQL — Part 2: Foundation

(SQL/Foundation).
ISO/IEC 9075-3:1995, Information technology — Database languages — SQL — Part 3: Call-

Level Interface (SQL/CLI).
ISO/IEC 9075-4, Information technology — Database languages — SQL — Part 4: Persistent

Stored Modules (SQL/PSM).
ISO/IEC 9899:1990, Programming languages — C.
ISO/IEC 9899:1990/Amendment 1:1995, Amendment to ISO/IEC 9899:1990 — C Integrity.
ISO/IEC 10206:1991, Information technology — Programming languages—Extended Pascal.
ISO/IEC 11756:1992, Information technology—Programming languages — MUMPS.
Normative references 3

3 Definitions, notations, and conventions
3.1 Definitions
Insert this paragraph For the purposes of this part of ISO/IEC 9075, the definitions given in ISO/IEC
9075-1 and ISO/IEC 9075-2 apply.
3.2 Notation
Insert this paragraph The notation used in this part of ISO/IEC 9075 is defined in ISO/IEC 9075-1.
3.3 Conventions
Insert this paragraph The conventions used in this part of ISO/IEC 9075 is defined in ISO/IEC
9075-1.
3.3.1 Use of terms
3.3.1.1 Other terms

Insert this paragraph An SQL-statement S1 is said to be executed as a direct result of executing
an SQL-statement if S1 is the value of an <SQL statement variable> referenced by an <execute
immediate statement> contained in an <externally-invoked procedure> that has been executed, or
if S1 was the value of the <SQL statement variable> that was associated with an <SQL statement
name> by a <prepare statement> and that same <SQL statement name> is referenced by an
<execute statement> contained in an <externally-invoked procedure> that has been executed.
3.3.2 Relationships to other parts of ISO/IEC 9075
3.3.2.1 Clause, Subclause, and Table relationships
Table 1—Clause, Subclause, and Table relationships

Corresponding Clause,
Clause, Subclause, or Table in Subclause, or Table from an- Part containing corre-
this part of ISO/IEC 9075 other part spondence
Clause 1, ‘‘Scope’’ Clause 1, "Scope" ISO/IEC 9075-2

Clause 2, ‘‘Normative references’’ Clause 2, "Normative references" ISO/IEC 9075-2
Clause 3, ‘‘Definitions, notations, Clause 3, "Definitions, notations, ISO/IEC 9075-2
and conventions’’ and conventions"
Definitions, notations, and conventions 5

3.3 Conventions
Table 1—Clause, Subclause, and Table relationships (Cont.)

Subclause 3.1, ‘‘Definitions’’ Subclause 3.1, "Definitions" ISO/IEC 9075-1
Subclause 3.2, ‘‘Notation’’ Subclause 6.1, "Notation" ISO/IEC 9075-1
Subclause 3.3, ‘‘Conventions’’ Subclause 6.2, "Conventions" ISO/IEC 9075-1
Subclause 3.3.1, ‘‘Use of terms’’ Subclause 6.2.3, "Use of terms" ISO/IEC 9075-1
Subclause 3.3.1.1, ‘‘Other terms’’ Subclause 6.2.3.7, "Other terms" ISO/IEC 9075-1
Subclause 3.3.2, ‘‘Relationships to (none) (none)
other parts of ISO/IEC 9075’’
Subclause 3.3.2.1, ‘‘Clause, (none) (none)
Subclause, and Table relationships’’
Subclause 3.4, ‘‘Object identifier for Subclause 6.3, "Object identifier for ISO/IEC 9075-1
Database Language SQL’’ Database Language SQL"
Clause 4, ‘‘Concepts’’ Clause 4, "Concepts" ISO/IEC 9075-2
Subclause 4.1, ‘‘Catalogs’’ Subclause 4.2.6.1, "Catalogs" ISO/IEC 9075-1
Subclause 4.2, ‘‘SQL-client modules’’ Subclause 4.21, "SQL-client mod- ISO/IEC 9075-2
ules"
Subclause 4.3, ‘‘SQL-invoked rou- Subclause 4.23, "SQL-invoked ISO/IEC 9075-2
tines’’ routines"
Subclause 4.4, ‘‘Locators’’ Subclause 4.26.4, "Locators" ISO/IEC 9075-2
Subclause 4.5, ‘‘Cursors’’ Subclause 4.29, "Cursors" ISO/IEC 9075-2
Subclause 4.6, ‘‘SQL-statements’’ Subclause 4.30, "SQL-statements" ISO/IEC 9075-2
Subclause 4.6.1, ‘‘Classes of SQL- Subclause 4.30.1, "Classes of SQL- ISO/IEC 9075-2
statements’’ statements"
Subclause 4.6.2, ‘‘SQL-statements Subclause 4.30.2, "SQL-statements ISO/IEC 9075-2
classified by function’’ classified by function"
Subclause 4.6.3, ‘‘SQL-statements Subclause 4.30.3, "SQL-statements ISO/IEC 9075-2
and transaction states’’ and transaction states"
Subclause 4.6.4, ‘‘Embeddable SQL- none none
statements’’
Subclause 4.6.5, ‘‘Preparable and none none
immediately executable SQL-
statements’’
Subclause 4.6.6, ‘‘Directly exe- none none
cutable SQL-statements’’
Subclause 4.7, ‘‘Standard program- Subclause 4.28, "Standard program- ISO/IEC 9075-2
ming languages’’ ming languages"
Subclause 4.8, ‘‘Embedded syntax’’ none none

3.3 Conventions

Subclause 4.9, ‘‘SQL dynamic state- none none
ments’’
Subclause 4.10, ‘‘Direct invocation of none none
SQL’’
Subclause 4.11, ‘‘Privileges and Subclause 4.31, "Basic security ISO/IEC 9075-2
roles’’ model"
Subclause 4.12, ‘‘SQL-transactions’’ Subclause 4.32, "SQL-transactions" ISO/IEC 9075-2
Subclause 4.13, ‘‘SQL-connections’’ Subclause 4.33, "SQL-connections" ISO/IEC 9075-2
Subclause 4.14, ‘‘SQL-sessions’’ Subclause 4.34, "SQL-sessions" ISO/IEC 9075-2
Subclause 4.15, ‘‘Client-server Subclause 4.36, "Client-server ISO/IEC 9075-2
operation’’ operation"
Clause 5, ‘‘Lexical elements’’ Clause 5, "Lexical elements" ISO/IEC 9075-2
Subclause 5.1, ‘‘<token> and <sepa- Subclause 5.2, "<token> and <sepa- ISO/IEC 9075-2
rator>’’ rator>"
Subclause 5.2, ‘‘<literal>’’ Subclause 5.3, "<literal>" ISO/IEC 9075-2
Subclause 5.3, ‘‘Names and identi- Subclause 5.4, "Names and identi- ISO/IEC 9075-2
fiers’’ fiers"
Clause 6, ‘‘Scalar expressions’’ Clause 6, "Scalar expressions" ISO/IEC 9075-2
Subclause 6.1, ‘‘<value specifica- Subclause 6.3, "<value specifica- ISO/IEC 9075-2
tion> and <target specification>’’ tion> and <target specification>"
Subclause 7.1, ‘‘<table reference>’’ Subclause 7.6, "<table reference>" ISO/IEC 9075-2
Subclause 6.2, ‘‘<column reference>’’ Subclause 6.6, "<column reference>" ISO/IEC 9075-2
Subclause 6.3, ‘‘<interval value Subclause 6.29, "<interval value ISO/IEC 9075-2
expression>’’ expression>"
Clause 7, ‘‘Query expressions’’ Clause 7, "Query expressions" ISO/IEC 9075-2
Subclause 7.2, ‘‘<query specifica- Subclause 7.11, "<query specifica- ISO/IEC 9075-2
tion>’’ tion>"
Clause 8, ‘‘Additional common Clause 10, "Additional common ISO/IEC 9075-2
elements’’ elements"
Subclause 8.1, ‘‘<routine invoca- Subclause 10.4, "<routine invoca- ISO/IEC 9075-2
tion>’’ tion>"
Clause 9, ‘‘Data assignment rules Clause 9, "Data assignment rules ISO/IEC 9075-2
and routine determination’’ and routine determination"
Subclause 9.1, ‘‘Retrieval assign- Subclause 9.1, "Retrieval assign- ISO/IEC 9075-2
ment’’ ment"
Subclause 9.2, ‘‘Store assignment’’ Subclause 9.2, "Store assignment" ISO/IEC 9075-2

3.3 Conventions

Clause 10, ‘‘Schema definition and Clause 11, "Schema definition and ISO/IEC 9075-2
manipulation’’ manipulation"
Subclause 10.1, ‘‘<check constraint Subclause 11.9, "<check constraint ISO/IEC 9075-2
definition>’’ definition>"
Subclause 10.2, ‘‘<view definition>’’ Subclause 11.21, "<view definition>" ISO/IEC 9075-2
Subclause 10.3, ‘‘<assertion defini- Subclause 11.36, "<assertion defini- ISO/IEC 9075-2
tion>’’ tion>"
Subclause 10.4, ‘‘<trigger defini- Subclause 11.38, "<trigger defini- ISO/IEC 9075-2
tion>’’ tion>"
Subclause 10.5, ‘‘<SQL-invoked Subclause 11.49, "<SQL-invoked ISO/IEC 9075-2
routine>’’ routine>"
Clause 11, ‘‘SQL-client modules’’ Clause 13, "SQL-client modules" ISO/IEC 9075-2
Subclause 11.1, ‘‘<SQL-client mod- Subclause 13.1, "<SQL-client mod- ISO/IEC 9075-2
ule definition>’’ ule definition>"
Subclause 11.2, ‘‘Calls to an Subclause 13.4, "Calls to an ISO/IEC 9075-2
<externally-invoked procedure>’’ <externally-invoked procedure>"
Subclause 11.3, ‘‘<SQL procedure Subclause 13.5, "<SQL procedure ISO/IEC 9075-2
statement>’’ statement>"
Clause 12, ‘‘Data manipulation’’ Clause 14, "Data manipulation" ISO/IEC 9075-2
Subclause 12.1, ‘‘<select statement: Subclause 14.5, "<select statement: ISO/IEC 9075-2
single row>’’ single row>"
Subclause 12.2, ‘‘<free locator state- Subclause 14.12, "<free locator ISO/IEC 9075-2
ment>’’ statement>"
Clause 13, ‘‘Transaction manage- Clause 16, "Transaction manage- ISO/IEC 9075-2
ment’’ ment"
Subclause 13.1, ‘‘<commit state- Subclause 16.6, "<commit state- ISO/IEC 9075-2
ment>’’ ment>"
Clause 14, ‘‘Session management’’ Clause 18, "Session management" ISO/IEC 9075-2
Subclause 14.1, ‘‘<set catalog state- none none
ment>’’
Subclause 14.2, ‘‘<set schema state- none none
ment>’’
Subclause 14.3, ‘‘<set names state- none none
ment>’’
Subclause 14.4, ‘‘<set path state- none none
ment>’’
Subclause 14.5, ‘‘<set transform none none
group statement>’’

3.3 Conventions

Clause 15, ‘‘Dynamic SQL’’ none none
Subclause 15.1, ‘‘Description of SQL none none
descriptor areas’’
Subclause 15.2, ‘‘<allocate descriptor none none
statement>’’
Subclause 15.3, ‘‘<deallocate de- none none
scriptor statement>’’
Subclause 15.4, ‘‘<get descriptor none none
statement>’’
Subclause 15.5, ‘‘<set descriptor none none
statement>’’
Subclause 15.6, ‘‘<prepare state- none none
ment>’’
Subclause 15.7, ‘‘<deallocate pre- none none
pared statement>’’
Subclause 15.8, ‘‘<describe state- none none
ment>’’
Subclause 15.9, ‘‘<input using none none
clause>’’
Subclause 15.10, ‘‘<output using none none
clause>’’
Subclause 15.11, ‘‘<execute state- none none
ment>’’
Subclause 15.12, ‘‘<execute immedi- none none
ate statement>’’
Subclause 15.13, ‘‘<dynamic declare none none
cursor>’’
Subclause 15.14, ‘‘<allocate cursor none none
statement>’’
Subclause 15.15, ‘‘<dynamic open none none
statement>’’
Subclause 15.16, ‘‘<dynamic fetch none none
statement>’’
Subclause 15.17, ‘‘<dynamic single none none
row select statement>’’
Subclause 15.18, ‘‘<dynamic close none none
statement>’’
Subclause 15.19, ‘‘<dynamic delete none none
statement: positioned>’’

3.3 Conventions

Subclause 15.20, ‘‘<dynamic update none none
statement: positioned>’’
Subclause 15.21, ‘‘<preparable none none
dynamic delete statement: posi-
tioned>’’
Subclause 15.22, ‘‘<preparable none none
dynamic update statement: posi-
tioned>’’
Clause 16, ‘‘Embedded SQL’’ none none
Subclause 16.1, ‘‘<embedded SQL none none
host program>’’
Subclause 16.2, ‘‘<embedded excep- none none
tion declaration>’’
Ada program>’’
Subclause 16.4, ‘‘<embedded SQL C none none
program>’’
COBOL program>’’
Fortran program>’’
MUMPS program>’’
Pascal program>’’
PL/I program>’’
Clause 17, ‘‘Direct invocation of none none
SQL’’
Subclause 17.1, ‘‘<direct SQL state- none none
ment>’’
Subclause 17.2, ‘‘<direct select none none
statement: multiple rows>’’
Clause 18, ‘‘Diagnostics manage- Clause 19, "Diagnostics manage- ISO/IEC 9075-2
ment’’ ment"
Subclause 18.1, ‘‘<get diagnostics Subclause 19.1, "<get diagnostics ISO/IEC 9075-2
statement>’’ statement>"
Clause 19, ‘‘Definition Schema’’ Clause 21, "Definition Schema" ISO/IEC 9075-2
Subclause 19.1, ‘‘SQL_LANGUAGES Subclause 21.37, "SQL_LANGUAGES ISO/IEC 9075-2
base table’’ base table"

3.3 Conventions

Clause 20, ‘‘Status codes’’ Clause 22, "Status codes" ISO/IEC 9075-2
Subclause 20.1, ‘‘SQLSTATE’’ Subclause 22.1, "SQLSTATE" ISO/IEC 9075-2
Clause 21, ‘‘Conformance’’ Clause 23, "Conformance" ISO/IEC 9075-2
Subclause 21.2, ‘‘Claims of confor- Subclause 8.1.5, "Claims of confor- ISO/IEC 9075-1
mance’’ mance"
Annex A, ‘‘SQL Conformance Appendix A, "SQL Conformance ISO/IEC 9075-2
Summary’’ Summary"
Annex B, ‘‘Implementation-defined Appendix B, "Implementation- ISO/IEC 9075-2
elements’’ defined elements"
Annex C, ‘‘Implementation- Appendix C, "Implementation- ISO/IEC 9075-2
dependent elements’’ dependent elements"
Annex D, ‘‘Deprecated features’’ Appendix D, "Deprecated features" ISO/IEC 9075-2
Annex E, ‘‘Incompatibilities with Appendix E, "Incompatibilities with ISO/IEC 9075-2
ISO/IEC 9075:1992’’ ISO/IEC 9075:1992 and ISO/IEC
9075-4:1996"
Annex F, ‘‘SQL feature and package Appendix F, "SQL feature and ISO/IEC 9075-2
taxonomy’’ package taxonomy"
Table 1, ‘‘Clause, Subclause, and none none
Table relationships’’
Table 2, ‘‘Data types of <key word>s none none
used in the header of SQL descrip-
tor areas’’
Table 3, ‘‘Data types of <key word>s none none
used in SQL item descriptor areas’’
Table 4, ‘‘Codes used for SQL data none none
types in Dynamic SQL’’
Table 5, ‘‘Codes associated with none none
datetime data types in Dynamic
SQL’’
Table 6, ‘‘Codes used for <interval none none
qualifier>s in Dynamic SQL’’
Table 7, ‘‘Codes used for in- none none
put/output SQL parameter modes in
Dynamic SQL’’
Table 8, ‘‘<identifier>s for use with Table 25, "<identifier>s for use with ISO/IEC 9075-2
<get diagnostics statement>’’ <get diagnostics statement>"
Table 9, ‘‘SQL-statement codes’’ Table 26, "SQL-statement codes" ISO/IEC 9075-2
Table 10, ‘‘SQLSTATE class and Table 27, "SQLSTATE class and ISO/IEC 9075-2
subclass values’’ subclass values"

3.3 Conventions

Table 12, ‘‘SQL/Bindings feature Table 31, "SQL/Foundation feature ISO/IEC 9075-2
taxonomy and definition for Core taxonomy and definition for Core
SQL’’ SQL"
Table 13, ‘‘SQL/Bindings feature Table 32, "SQL/Foundation feature ISO/IEC 9075-2
taxonomy for features outside Core taxonomy for features outside Core
SQL’’ SQL"
3.4 Object identifier for Database Language SQL
The object identifier for Database Language SQL is defined in ISO/IEC 9075-1 in Subclause 6.3,
"Object identifier for Database Language SQL", with the following additions:
Format
<Part 5 yes> ::=

<Part 5 conformance>
<Part 5 direct> <Part 5 embedded>
<Part 5 conformance> ::=

5 | sqlbindings199x <left paren> 5 <right paren>
<Part 5 direct> ::=

<Part 5 direct yes>
| <Part 5 direct no>
<Part 5 direct yes> ::=

1 | directyes <left paren> 1 <right paren>
<Part 5 direct no> ::=

0 | directno <left paren> 0 <right paren>
<Part 5 embedded> ::=

<Part 5 embedded no>
| <Part 5 embedded languages>...
<Part 5 embedded no> ::=

0 | embeddedno <left paren> 0 <right paren>
<Part 5 embedded languages> ::=

<Part 5 embedded Ada>
| <Part 5 embedded C>
| <Part 5 embedded COBOL>
| <Part 5 embedded Fortran>
| <Part 5 embedded MUMPS>
| <Part 5 embedded Pascal>
| <Part 5 embedded PL/I>
<Part 5 embedded Ada> ::=

1 | embeddedAda <left paren> 1 <right paren>
<Part 5 embedded C> ::=

3.4 Object identifier for Database Language SQL
2 | embeddedC <left paren> 2 <right paren>
<Part 5 embedded COBOL> ::=

3 | embeddedCOBOL <left paren> 3 <right paren>
<Part 5 embedded Fortran> ::=

4 | embeddedFortran <left paren> 4 <right paren>
<Part 5 embedded MUMPS> ::=

5 | embeddedMUMPS <left paren> 5 <right paren>
<Part 5 embedded Pascal> ::=

6 | embeddedPascal <left paren> 6 <right paren>
<Part 5 embedded PL/I> ::=

7 | embeddedPLI <left paren> 7 <right paren>
Syntax Rules
1) Specification of <Part 5 Yes> implies that conformance to this part of ISO/IEC 9075 is claimed.
2) Specification of <Part 5 direct yes> implies that conformance to <direct SQL statement> is
claimed.
3) Specification of <Part 5 direct no> implies that conformance to <direct SQL statement> is not
claimed.
4) Specification of <Part 5 embedded language> implies that conformance to <embedded SQL host
program> for the specified language is claimed.
5) Specification of <Part 5 embedded no> implies that conformance to <embedded SQL host pro-
gram> is not claimed.


4 Concepts
4.1 Catalogs
Insert this paragraph The default catalog name for <preparable statement>s that are dynamically
prepared in the current SQL-session through the execution of <prepare statement>s and <execute
immediate statement>s is initially implementation-defined but may be changed by the use of <set
catalog statement>s.
4.2 SQL-client modules
Insert this paragraph SQL-session modules are implicitly-created modules for prepared SQL-
statements (see Subclause 4.34, "SQL-sessions", in ISO/IEC 9075-2).
Insert this paragraph Each <SQL-client module definition> M that is associated with an SQL-session,
other than an SQL-session module, may have associated with it a shadow module M1 that has an
implementation-dependent name not equivalent to the <module name> of any other <SQL-client
module definition> in the same SQL-session and whose <module authorization clause> specifies
‘‘SCHEMA SN’’, where SN is the explicit or implicit <schema name> of the <module authoriza-
tion clause> of M. The <language clause>, the SQL-path, if specified, and the <module character
set specification> of M1 are identical to the corresponding characteristic of M. When M contains
a <module authorization clause> that specifies ‘‘FOR STATIC ONLY’’, this shadow module effec-
tively contains one <externally-invoked procedure> for each SQL-statement prepared by <prepared
statement>s or <execute immediate statement>s contained in M.
4.3 SQL-invoked routines
Augment the 6th paragraph The <SQL procedure statement> forming the <routine body> must ex-
clude <SQL dynamic statement>.
4.4 Locators
Augment the 1st paragraph A host variable may be specified to be a locator by specifying AS
LOCATOR.
Augment the 1st paragraph A host variable specified as a locator may be further specified to be a
holdable locator.
4.5 Cursors
Insert this paragraph A cursor is also specified by a <dynamic declare cursor> or an <allocate cursor
statement>. A cursor specified by a <dynamic declare cursor> is a declared dynamic cursor. A
cursor specified by an <allocate cursor statement> is an extended dynamic cursor. A dynamic cursor
is either a declared dynamic cursor or an extended dynamic cursor.
Concepts 15
4.5 Cursors
Insert this paragraph For every <dynamic declare cursor> in an <SQL-client module definition>, a
cursor is effectively created when an SQL-transaction (see Subclause 4.32, "SQL-transactions", in
ISO/IEC 9075-2) referencing the <SQL-client module definition> is initiated. An extended dynamic
cursor is also effectively created when an <allocate cursor statement> is executed within an SQL-
session and destroyed when that SQL-session is terminated.
Insert this paragraph In addition, a dynamic cursor is destroyed when a <deallocate prepared state-
ment> is executed that deallocates the prepared statement on which the dynamic cursor is based.
Insert this paragraph A cursor is also placed in the open state by a <dynamic open statement> and
returned to the closed state by a <dynamic close statement>.
Insert this paragraph A <dynamic fetch statement> positions an open cursor on a specified row of the
cursor’s ordering and retrieves the values of the columns of that row. A <dynamic update statement:
positioned> updates the current row of the cursor. A <dynamic delete statement: positioned>
deletes the current row of the cursor.
4.6 SQL-statements
4.6.1 Classes of SQL-statements

Insert this paragraph Most SQL-statements can be prepared for execution and executed in additional
ways. These are:
— In an embedded SQL host program, in which case they are prepared when the embedded SQL
host program is preprocessed (see Subclause 4.8, ‘‘Embedded syntax’’).
— Being prepared and executed by the use of SQL-dynamic statements (which are themselves
executed in an SQL-client module or an embedded SQL host program—see Subclause 4.9, ‘‘SQL
dynamic statements’’).
— Direct invocation, in which case they are effectively prepared immediately prior to execution
(see Subclause 4.10, ‘‘Direct invocation of SQL’’).
Insert this paragraph There are at least three additional ways of classifying SQL-statements:
— According to whether or not they may be embedded.
— According to whether they may be dynamically prepared and executed.
— According to whether or not they may be directly executed.
4.6.2 SQL-statements classified by function

Insert this paragraph The following are other main classes of SQL-statements:
— SQL-dynamic statements
— SQL embedded exception declaration
Insert this paragraph The following are additional SQL-data statements:
— <dynamic declare cursor>

4.6 SQL-statements
— <allocate cursor statement>
— <dynamic select statement>
— <dynamic open statement>
— <dynamic close statement>
— <dynamic fetch statement>
— <direct select statement: multiple rows>
— <dynamic single row select statement>
Insert this paragraph The following are additional SQL-data change statements:
— <dynamic delete statement: positioned>
— <preparable dynamic delete statement: positioned>
— <dynamic update statement: positioned>
— <preparable dynamic update statement: positioned>
Insert this paragraph The following are additional SQL-session statements:
— <set catalog statement>
— <set schema statement>
— <set names statement>
— <set path statement>
— <set transform group statement>
Insert this paragraph The following are the SQL-dynamic statements:
— <execute immediate statement>
— <allocate descriptor statement>
— <deallocate descriptor statement>
— <get descriptor statement>
— <set descriptor statement>
— <prepare statement>
— <deallocate prepared statement>
— <describe input statement>
— <describe output statement>
— <execute statement>
Concepts 17
4.6 SQL-statements
Insert this paragraph The following is the SQL embedded exception declaration:
— <embedded exception declaration>
4.6.3 SQL-statements and transaction states

Whether or not an <execute immediate statement> starts a transaction depends
Insert this paragraph
on the content of the <SQL statement variable> referenced by the <execute immediate statement>
at the time it is executed. Whether or not an <execute statement> starts a transaction depends
on the content of the <SQL statement variable> referenced by the <prepare statement> at the
time the prepared statement referenced by the <execute statement> was prepared. In both cases,
if the content of the <SQL statement variable> was a transaction-initiating SQL-statement, then
the <execute immediate statement> or <execute statement> is treated as a transaction-initiating
statement; otherwise it is not treated as a transaction-initiating statement.
Insert this paragraph The following additional SQL-statements are transaction-initiating SQL-
statements, i.e., if there is no current transaction, and a statement of this class is executed, a
transaction is initiated:
— <allocate cursor statement>
— <dynamic open statement>
— <dynamic close statement>
— <dynamic fetch statement>
— <dynamic delete statement: positioned>
— <dynamic update statement: positioned>
— The following SQL-dynamic statements:
• <describe input statement>
• <describe output statement>
• <allocate descriptor statement>
• <deallocate descriptor statement>
• <get descriptor statement>
• <set descriptor statement>
• <prepare statement>
• <deallocate prepared statement>

4.6 SQL-statements
Insert this paragraph The following additional SQL-statements are not transaction-initiating SQL-
statements, i.e., if there is no current transaction, and a statement of this class is executed, no
transaction is initiated.
— SQL embedded exception declarations
— The following SQL-data statements:
• <dynamic declare cursor>
• <dynamic select statement>
4.6.4 Embeddable SQL-statements

The following SQL-statements are embeddable in an embedded SQL host program, and may be
the <SQL procedure statement> in an <externally-invoked procedure> in an <SQL-client module
definition>:
— All SQL-schema statements
— All SQL-transaction statements
— All SQL-connection statements
— All SQL-session statements
— All SQL-dynamic statements
— All SQL-diagnostics statements
• <allocate cursor statement>
• <open statement>
• <dynamic open statement>
• <close statement>
• <dynamic close statement>
• <fetch statement>
• <dynamic fetch statement>
• <select statement: single row>
• <insert statement>
• <delete statement: searched>
• <delete statement: positioned>
• <dynamic delete statement: positioned>
• <update statement: searched>
Concepts 19
4.6 SQL-statements
• <update statement: positioned>
• <dynamic update statement: positioned>
• <free locator statement>
— The following SQL-control statements:
• <call statement>
The following SQL-statements are embeddable in an embedded SQL host program, and may occur
in an <SQL-client module definition>, though not in an <externally-invoked procedure>:
— <temporary table declaration>
— <declare cursor>
— <dynamic declare cursor>
The following SQL-statements are embeddable in an embedded SQL host program, but may not
occur in an <SQL-client module definition>:
Consequently, the following SQL-data statements are not embeddable in an embedded SQL host
program, nor may they occur in an <SQL-client module definition>, nor be the <SQL procedure
statement> in an <externally-invoked procedure> in an <SQL-client module definition>:
4.6.5 Preparable and immediately executable SQL-statements

The following SQL-statements are preparable:
• <dynamic single row select statement>

4.6 SQL-statements
• <preparable dynamic delete statement: positioned>
• <preparable dynamic update statement: positioned>
• <preparable implementation-defined statement>
• <free locator statement>
— The following SQL-control statements:
• <call statement>
Consequently, the following SQL-statements are not preparable:
• <direct select statement: multiple rows>
• <temporary table declaration>
• <declare cursor>
Concepts 21
4.6 SQL-statements
Any preparable SQL-statement can be executed immediately, with the exception of:
4.6.6 Directly executable SQL-statements

The following SQL-statements may be executed directly:
• <temporary table declaration>
• <direct select statement: multiple rows>
Consequently, the following SQL-statements may not be executed directly:
• <declare cursor>

4.6 SQL-statements
• <dynamic single row select statement>
• <preparable dynamic delete statement: positioned>
• <preparable dynamic update statement: positioned>
— <free locator statement>
— <hold locator statement>
4.7 Standard programming languages
Insert this paragraph This part of ISO/IEC 9075 specifies a mechanism whereby SQL language may
be embedded in programs that otherwise conform to any of the same specified programming lan-
guage standards.
NOTE 1 – In this part of ISO/IEC 9075, for the purposes of interfacing with programming languages, the
data types DATE, TIME, TIMESTAMP, and INTERVAL must be converted to or from character strings in
those programming languages by means of a <cast specification>. It is anticipated that future evolution of
programming language standards will support data types corresponding to these four SQL data types; this
standard will then be amended to reflect the availability of those corresponding data types.
The data types CHARACTER, CHARACTER VARYING, and CHARACTER LARGE OBJECT are also
mapped to character strings in the programming languages. However, because the facilities available in the
programming languages do not provide the same capabilities as those available in SQL, there must be agree-
ment between the host program and SQL regarding the specific format of the character data being exchanged.
Specific syntax for this agreement is provided in this part of ISO/IEC 9075. For standard programming lan-
guages C, COBOL, Fortran, and Pascal, bit strings are mapped to character variables in the host language
in a manner described in Subclause 16.1, ‘‘<embedded SQL host program>’’. For standard programming
languages Ada and PL/I, bit string variables are directly supported.
For standard programming languages C and COBOL, BOOLEAN values are mapped to integer variables
in the host language. For standard programming languages Ada, Fortran, Pascal, and PL/I, BOOLEAN
variables are directly supported.
For the purposes of interfacing with programming languages, the data type ARRAY must be converted to a
locator (see Subclause 4.26.4, "Locators", in ISO/IEC 9075-2).
For the purposes of interfacing with programming languages, user-defined types must be handled with a
locator (see Subclause 4.26.4, "Locators", in ISO/IEC 9075-2) or transformed to another SQL data type that
has a defined mapping to the host language (see Subclause 4.8.5, "Transforms for user-defined types", in
ISO/IEC 9075-2).
Concepts 23
4.8 Embedded syntax
4.8 Embedded syntax
An <embedded SQL host program> (<embedded SQL Ada program>, <embedded SQL C program>,
<embedded SQL COBOL program>, <embedded SQL Fortran program>, <embedded SQL MUMPS
program>, <embedded SQL Pascal program>, or <embedded SQL PL/I program>) is a compilation
unit that consists of programming language text and SQL text. The programming language text
shall conform to the requirements of a specific standard programming language. The SQL text shall
consist of one or more <embedded SQL statement>s and, optionally, one or more <embedded SQL
declare section>s, as defined in this International Standard. This allows database applications to be
expressed in a hybrid form in which SQL-statements are embedded directly in a compilation unit.
Such a hybrid compilation unit is defined to be equivalent to a standard compilation unit in which
the SQL-statements have been replaced by standard procedure or subroutine calls of <externally-
invoked procedure>s in a separate SQL-client module, and in which each has been removed and the
declarations contained therein have been suitably transformed into standard host-language syntax.
If an <embedded SQL host program> contains an <embedded authorization declaration>, then it
shall be the first statement or declaration in the <embedded SQL host program>. The <embedded
authorization declaration> is not replaced by a procedure or subroutine call of an <externally-
invoked procedure>, but is removed and replaced by syntax associated with the <SQL-client module
definition>’s <module authorization clause>.
An implementation may reserve a portion of the name space in the <embedded SQL host program>
for the names of procedures or subroutines that are generated to replace SQL-statements and for
program variables and branch labels that may be generated as required to support the calling of
these procedures or subroutines; whether this reservation is made is implementation-defined. They
may similarly reserve name space for the <module name> and <procedure name>s of the generated
<SQL-client module definition> that may be associated with the resulting standard compilation
unit. The portion of the name space to be so reserved, if any, is implementation-defined.
4.9 SQL dynamic statements
In many cases, the SQL-statement to be executed can be coded into an <SQL-client module defi-
nition> or into a compilation unit using the embedded syntax. In other cases, the SQL-statement
is not known when the program is written and will be generated during program execution. An
<execute immediate statement> can be used for a one-time preparation and execution of an SQL-
statement. A <prepare statement> is used to prepare the generated SQL-statement for subsequent
execution. A <deallocate prepared statement> is used to deallocate SQL-statements that have been
prepared with a <prepare statement>. A description of the input dynamic parameters for a pre-
pared statement can be obtained by execution of a <describe input statement>. A description of the
resultant columns of a <dynamic select statement> or <dynamic single row select statement> can
be obtained by execution of a <describe output statement>. A description of the output dynamic
parameters of a statement that is neither a <dynamic select statement> nor a <dynamic single row
select statement> can be obtained by execution of a <describe output statement>. For a statement
other than a <dynamic select statement>, an <execute statement> is used to associate parameters
with the prepared statement and execute it as though it had been coded when the program was
written. For a <dynamic select statement>, the prepared <cursor specification> is associated with
a cursor via a <dynamic declare cursor> or <allocate cursor statement>. The cursor can be opened
and dynamic parameters can be associated with the cursor with a <dynamic open statement>. A
<dynamic fetch statement> positions an open cursor on a specified row and retrieves the values of
the columns of that row. A <dynamic close statement> closes a cursor that was opened with a <dy-
namic open statement>. A <dynamic delete statement: positioned> is used to delete rows through

a dynamic cursor. A <dynamic update statement: positioned> is used to update rows through a dy-
namic cursor. A <preparable dynamic delete statement: positioned> is used to delete rows through
a dynamic cursor when the precise format of the statement isn’t known until runtime. A <prepara-
ble dynamic update statement: positioned> is used to update rows through a dynamic cursor when
the precise format of the statement isn’t known until runtime.
The interface for input dynamic parameters and output dynamic parameters for a prepared state-
ment and for the resulting values from a <dynamic fetch statement> or the execution of a prepared
<dynamic single row select statement> can be either a list of dynamic parameters or embedded
variables or an SQL descriptor area. An SQL descriptor area consists of one or more item descrip-
tor areas, together with a header that includes a count of the number of those item descriptor
areas. The header of an SQL descriptor area consists of the fields in Table 2, ‘‘Data types of <key
word>s used in the header of SQL descriptor areas’’, in Subclause 15.1, ‘‘Description of SQL de-
scriptor areas’’. Each item descriptor area consists of the fields specified in Table 3, ‘‘Data types of
<key word>s used in SQL item descriptor areas’’, in Subclause 15.1, ‘‘Description of SQL descrip-
tor areas’’. The SQL descriptor area is allocated and maintained by the system with the following
statements: <allocate descriptor statement>, <deallocate descriptor statement>, <set descriptor
statement>, and <get descriptor statement>.
An SQL descriptor area is identified by a <descriptor name>, which is a <simple value specification>
whose value is an <identifier>. Two <descriptor name>s identify the same SQL descriptor area if
their values, with leading and trailing <space>s removed, are equivalent according to the rules for
<identifier> comparisons in Subclause 5.2, "<token> and <separator>", in ISO/IEC 9075-2.
Dynamic statements can be identified by <statement name>s or by <extended statement name>s.
Similarly, dynamic cursors can be identified by <cursor name>s and by <extended cursor name>s.
The non-extended names are <identifier>s. The extended names are <target specification>s whose
values are <identifier>s used to identify the statement or cursor. Two extended names are equiv-
alent if their values, with leading and trailing <space>s removed, are equivalent according to the
rules for <identifier> comparison in Subclause 5.2, "<token> and <separator>", in ISO/IEC 9075-2.
An SQL descriptor area name may be defined as global or local. Similarly, an extended statement
name or extended cursor name may be global or local. The scope of a global name is the SQL-
session. The scope of a local name is the <SQL-client module definition> in which it appears. A
reference to an entity in which one specifies a global scope is valid only if the entity was defined as
global and if the reference is from the same SQL-session in which it was defined. A reference to an
entity in which one specifies a local scope is valid only if the entity was defined as local and if the
reference is from the same <SQL-client module definition> in which it was defined. (The scope of
non-extended statement names and non-extended cursor names is always local.)
NOTE 2 – The namespace of non-extended statement names and non-extended cursor names is different
from the namespace of extended statement names that are specified to be LOCAL and extended cursor names
that are specified to be LOCAL, respectively.
The relationships between prepared statements and <SQL-client module definition>s are:
— Within an SQL-session, all global prepared statements (prepared statements with global state-
ment names) belong to the SQL-session module.
— Within an SQL-session, each local prepared statement (a prepared statement with a local state-
ment name) prepared in an <SQL-client module definition> containing a <module authorization
clause> that does not specify ‘‘AUTHORIZATION <module authorization identifier>’’ belongs
to the <SQL-client module definition> that contains the <prepare statement> or <execute
immediate statement> with which it is prepared.
Concepts 25
— Within an SQL-session, each local prepared statement (a prepared statement with a local state-
ment names) prepared in an <SQL-client module definition> containing a <module authorization
clause> that contains ‘‘AUTHORIZATION <module authorization identifier>’’ and does not con-
tain ‘‘FOR STATIC ONLY’’ belongs to the <SQL-client module definition> that contains the
<prepare statement> or <execute immediate statement> with which it is prepared.
— Within an SQL-session, each local prepared statement (a prepared statement with a local
statement names) prepared in an <SQL-client module definition> M containing a <module
authorization clause> that contains ‘‘AUTHORIZATION <module authorization identifier> FOR
STATIC ONLY’’ belongs to a shadow module that has an implementation-dependent name not
equivalent to the <module name> of any other <SQL-client module definition> in the same
SQL-session and whose <module authorization clause> specifies ‘‘SCHEMA SN’’, where SN is
the explicit or implicit <schema name> of the <module authorization clause> of M.
NOTE 3 – The SQL-session module is defined in Subclause 4.34, "SQL-sessions", in ISO/IEC 9075-2.
Dynamic execution of SQL-statements can generally be accomplished in two different ways.
Statements can be prepared for execution and then later executed one or more times; when the
statement is no longer needed for execution, it can be released by the use of a <deallocate prepared
statement>. Alternatively, a statement that is needed only once can be executed without the prepa-
ration step—it can be executed immediately (not all SQL-statements can be executed immediately).
Many SQL-statements can be written to use ‘‘parameters’’ (which are manifested in static execution
of SQL-statements as host parameters in <SQL procedure statement>s contained in <externally-
invoked procedure>s in <SQL-client module definition>s or as host variables in <embedded SQL
statement>s contained in <embedded SQL host program>s). In SQL-statements that are executed
dynamically, the parameters are called dynamic parameters (<dynamic parameter specification>s)
and are represented in SQL language by a <question mark> (?).
In many situations, an application that generates an SQL-statement for dynamic execution knows
in detail the required characteristics (e.g., <data type>, <length>, <precision>, <scale>, etc.) of each
of the dynamic parameters used in the statement; similarly, the application may also know in detail
the characteristics of the values that will be returned by execution of the statement. However,
in other cases, the application may not know this information to the required level of detail; it is
possible in some cases for the application to ascertain the information from the Information Schema,
but in other cases (e.g., when a returned value is derived from a computation instead of simply from
a column in a table, or when dynamic parameters are supplied) this information is not generally
available except in the context of preparing the statement for execution.
To provide the necessary information to applications, SQL permits an application to request the
SQL-server to describe a prepared statement. The description of a statement identifies the number
of input dynamic parameters (describe input) and their data type information or it identifies the
number of output dynamic parameters or values to be returned (describe output) and their data
type information. The description of a statement is placed into the SQL descriptor areas already
mentioned.
Many, but not all, SQL-statements can be prepared and executed dynamically.
NOTE 4 – The complete list of statements that may be dynamically prepared and executed is defined in
Subclause 4.6.5, ‘‘Preparable and immediately executable SQL-statements’’.
Certain ‘‘set statements’’ (<set catalog statement>, <set schema statement>, <set names statement>,
and <set path statement>) have no effect other than to set up default information (catalog name,
schema name, character set, and SQL path, respectively) to be applied to other SQL-statements
that are prepared or executed immediately or that are invoked directly.

Syntax errors and Access Rule violations caused by the preparation or immediate execution of
<preparable statement>s are identified when the statement is prepared (by <prepare statement>)
or when it is executed (by <execute statement> or <execute immediate statement>); executed (by
<execute statement> or <execute immediate statement>); such violations are indicated by the
raising of an exception condition.
4.10 Direct invocation of SQL
Direct invocation of SQL is a mechanism for executing direct SQL-statements, known as <direct
SQL statement>s. In direct invocation of SQL, the method of invoking <direct SQL statement>s,
the method of raising conditions that result from the execution of <direct SQL statement>s, the
method of accessing the diagnostics information that results from the execution of <direct SQL
statement>s, and the method of returning the results are implementation-defined.
4.11 Privileges and roles
Insert this paragraph For direct SQL, the SQL-session user identifier is always the current authoriza-
tion identifier.
4.12 SQL-transactions
Insert this paragraph The operations comprising an SQL-transaction may also be performed by the
direct invocation of SQL.
It is implementation-defined whether or not the dynamic execution of an <SQL
dynamic data statement> is permitted to occur within the same SQL-transaction as the dynamic ex-
ecution of an SQL-schema statement. If it does occur, then the effect on any open cursor, prepared
dynamic statement, or deferred constraint is implementation-defined. There may be additional
implementation-defined restrictions, requirements, and conditions. If any such restrictions, re-
quirements, or conditions are violated, then an implementation-defined exception condition or a
completion condition warning with an implementation-defined subclass code is raised.
Insert this paragraph Each direct invocation of SQL that executes an SQL-statement of an SQL-
transaction is associated with that SQL-transaction. An SQL-transaction is initiated when no
SQL-transaction is currently active by direct invocation of SQL that results in the execution of a
transaction-initiating <direct SQL statement>.
4.13 SQL-connections
Insert this paragraph An SQL-connection may also be terminated by the last execution of a <direct
SQL statement> through the direct invocation of SQL. The mechanism and rules by which an SQL-
implementation determines whether a direct invocation of SQL is the last execution of a <direct
SQL statement> are implementation-defined.
Concepts 27
4.14 SQL-sessions
4.14 SQL-sessions
Replace 3rd paragraph Within an SQL-session, module local temporary tables are effectively created
by <temporary table declaration>s. Module local temporary tables are accessible only to invocations
of <externally-invoked procedure>s in the SQL-client module or SQL-session module in which
they are created. The definitions of module local temporary tables persist until the end of the
SQL-session.
Insert this paragraph An SQL-session also spans the execution of a sequence of consecutive SQL-
statements invoked by the direct invocation of SQL.
Insert this paragraph An SQL-session has an SQL-session module that is different from any other
<SQL-client module definition> that exists simultaneously in the SQL-environment. The SQL-
session module contains the global prepared SQL-statements that belong to the SQL-session. The
SQL-session module contains a <module authorization clause> that specifies SCHEMA <schema
name>, where the value of <schema name> is implementation-dependent.
Insert this paragraph An SQL-session has a default catalog name that is used to effectively qualify
unqualified <schema name>s that are contained in <preparable statement>s when those state-
ments are prepared in the current SQL-session by either an <execute immediate statement> or a
<prepare statement> or are contained in <direct SQL statement>s when those statements are in-
voked directly. The default catalog name is initially set to an implementation-defined value but can
subsequently be changed by the successful execution of a <set catalog statement> or <set schema
statement>.
Insert this paragraph An SQL-session has a default unqualified schema name that is used to effec-
tively qualify unqualified <schema qualified name>s that are contained in <preparable statement>s
when those statements are prepared in the current SQL-session by either an <execute imme-
diate statement> or a <prepare statement> or are contained in <direct SQL statement>s when
those statements are invoked directly. The default unqualified schema name is initially set to an
implementation-defined value but can subsequently be changed by the successful execution of a <set
schema statement>.
Insert this paragraph An SQL-session has a SQL-path that is used to effectively qualify unquali-
fied <routine name>s that are immediately contained in <routine invocation>s that are contained
in <preparable statement>s when those statements are prepared in the current SQL-session by
either an <execute immediate statement> or a <prepare statement> or are contained in <direct
SQL statement>s when those statements are invoked directly. The SQL-path is initially set to an
implementation-defined value, but can subsequently be changed by the successful execution of a
<set path statement>.
The text defining the SQL-path can be referenced by using the <general value
specification> CURRENT_PATH.
Insert this paragraph An SQL-session has a default transform group name and one or more user-
defined type name-transform group name pairs that are used to identify the group of transform
functions for every user-defined type that is referenced in <preparable statement>s when those
statements are prepared in the current SQL-session by either an <execute immediate statement>
or a <prepare statement> or are contained in <direct SQL statement>s when those statements are
invoked directly. The transform group name for a given user-defined type name is initially set to an
implementation-defined value but can subsequently be changed by the successful execution of a <set
transform group statement>.

4.14 SQL-sessions
Insert this paragraph The text defining the transform group names associated with the SQL-
session can be referenced using two mechanisms: the <general value specification> ‘‘CURRENT_
TRANSFORM_GROUP_FOR_TYPE <user-defined type>’’, which evaluates to the name of the
transform group associated with the specified data type, and the <general value specification>
‘‘CURRENT_DEFAULT_TRANSFORM_GROUP’’, which evaluates to the name of the transform
group associated with all types that have no type-specific transform group specified for them.
Insert this paragraph An SQL-session has a default character set name that is used to identify the
character set in which <preparable statement>s are represented when those statements are pre-
pared in the current SQL-session by either an <execute immediate statement> or a <prepare
statement>. The default character set name is initially set to an implementation-defined value
but can subsequently be changed by the successful execution of a <set names statement>.
Augment the 4th paragraph Within an SQL-session, locators are effectively created whenever a host
variable that is specified as a binary large object locator, character large object locator, array locator,
or user-defined type locator is assigned a value of binary large object type, character large object
type, array type, or user-defined type, respectively. A host variable that is a locator may be holdable
or nonholdable.
Insert this paragraph The SQL-session context also comprises:
— The SQL-session module.
— The current default catalog name.
— The current default unqualified schema name.
— The current character set name substitution value.
— The text defining the SQL-path.
— The contents of all SQL dynamic descriptor areas.
— The text defining the default transform group name.
— The text defining the user-defined type name-transform group name pair for each user-defined
type explicitly set by the user.
4.15 Client-server operation
Insert this paragraph <direct SQL statement>s containing an <SQL connection statement> or an
<SQL diagnostics statement> are processed by the SQL-client. Other <direct SQL statement>s are
processed by the SQL-server.
Concepts 29

5 Lexical elements
5.1 <token> and <separator>
Function
Specify lexical units (tokens and separators) that participate in SQL language.
Format
<delimiter token> ::=

!! All alternatives from ISO/IEC 9075-2
| <double period>
<double period> ::= ..
<non-reserved word> ::=

| DEGREE | DYNAMIC_FUNCTION | DYNAMIC_FUNCTION_CODE
| RETURNED_CARDINALITY
| STRUCTURE
| TOP_LEVEL_COUNT
<reserved word> ::=

| CURRENT_DEFAULT_TRANSFORM_GROUP
| CURRENT_TRANSFORM_GROUP_FOR_TYPE
| DYNAMIC
| NESTING
Syntax Rules
None.
Access Rules
No additional Access Rules.
General Rules
No additional General Rules.
Lexical elements 31
5.1 <token> and <separator>
Conformance Rules
No additional Conformance Rules.

5.2 <literal>
5.2 <literal>
Function
Specify a non-null value.
Format
No additional Format items.
Syntax Rules
1) Augments SR8) Case:
a) If a <character set specification> is not specified in a <character string literal>, then the
set of characters contained in the <character string literal> shall be wholly contained in the
character set of the SQL-client module or SQL-session module that contains the <character
string literal>.
b) Otherwise, there shall be no <separator> between the <introducer> and the <character set
specification>, and the set of characters contained in the <character string literal> shall be
wholly contained in the character set specified by the <character set specification>.
Access Rules
General Rules
Conformance Rules
Lexical elements 33
5.3 Names and identifiers
Function
Specify names.
Format
<SQL statement name> ::=

<statement name>
| <extended statement name>
<statement name> ::= <identifier>
<extended statement name> ::=

[ <scope option> ] <simple value specification>
<dynamic cursor name> ::=

<cursor name>
| <extended cursor name>
<extended cursor name> ::=

<descriptor name> ::=

<scope option> ::=

GLOBAL
| LOCAL
Syntax Rules
1) If the <local or schema qualified name> is contained, without an intervening
Insert before SR4)a)
<schema definition>, in a <preparable statement> that is prepared in the current SQL-session
by an <execute immediate statement> or a <prepare statement> or in a <direct SQL statement>
that is invoked directly, then the default <unqualified schema name> for the SQL-session is
implicit.
2) Insert before SR11)a) If the <schema qualified name> is contained, without an intervening
<schema definition>, in a <preparable statement> that is prepared in the current SQL-session
by an <execute immediate statement> or a <prepare statement> or in a <direct SQL statement>
that is invoked directly, then the default <unqualified schema name> for the SQL-session is
implicit.
3) Insert before SR12)a) If the <unqualified schema name> is contained in a <preparable state-
ment> that is prepared in the current SQL-session by an <execute immediate statement> or a
<prepare statement> or in a <direct SQL statement> that is invoked directly, then the default
catalog name for the SQL-session is implicit.
4) Insert this SR The <simple value specification> of <extended statement name> or <extended
cursor name> shall not be a <literal>.

5) Insert this SR The declared type of the <simple value specification> of <extended statement
name> shall be character string with an implementation-defined character set and shall have
an octet length of 128 octets or less.
6) Insert this SR The declared type of the <simple value specification> of <extended cursor name>
shall be character string with an implementation-defined character set and shall have an octet
length of 128 octets or less.
7) Insert this SR The declared type of the <simple value specification> of <descriptor name> shall
be character string with an implementation-defined character set and shall have an octet length
of 128 octets or less.
8) Insert this SR In a <descriptor name>, <extended statement name>, or <extended cursor name>,
if a <scope option> is not specified, then a <scope option> of LOCAL is implicit.
Access Rules
General Rules
1) Insert this GR The value of an <extended statement name> identifies a statement prepared by
the execution of a <prepare statement>. If a <scope option> of GLOBAL is specified, then the
scope of the <extended statement name> is the current SQL-session. If a <scope option> of
LOCAL is specified or implicit, then the scope of the <extended statement name> is further
restricted to the <SQL-client module definition> in which the <extended statement name>
appears.
2) Insert this GR A <dynamic cursor name> identifies a cursor in an <SQL dynamic statement>.
3) Insert this GR A <descriptor name> identifies a descriptor area.
4) Insert this GR A <statement name> identifies a statement prepared by the execution of a <pre-
pare statement>. The scope of a <statement name> is the <SQL-client module definition> in
which it appears and the current SQL-session.
5) Insert this GR The value of an <extended cursor name> identifies a cursor created by the exe-
cution of an <allocate cursor statement>. If a <scope option> of GLOBAL is specified, then the
scope of the <extended cursor name> is the current SQL-session. If a <scope option> of LOCAL
is specified or implicit, then the scope of the <extended cursor name> is further restricted to the
<SQL-client module definition> in which the <extended cursor name> appears.
6) Insert this GR A <descriptor name> identifies an SQL descriptor area created by the execution of
an <allocate descriptor statement>. If a <scope option> of GLOBAL is specified, then the scope
of the <descriptor name> is the current SQL-session. If a <scope option> of LOCAL is specified
or implicit, then the scope of the <descriptor name> is further restricted to the <SQL-client
module definition> in which the <descriptor name> appears.
Lexical elements 35
Conformance Rules
1) Insert this CR Without Feature B032, ‘‘Extended dynamic SQL’’, conforming SQL language shall
not contain any <extended statement name> or <extended cursor name>.
2) Insert this CR Without Feature B031, ‘‘Basic dynamic SQL’’, conforming SQL language shall not
contain any <SQL statement name>, <dynamic cursor name>, or <descriptor name>.

6 Scalar expressions
6.1 <value specification> and <target specification>
Function
Specify one or more values, host parameters, SQL parameters, dynamic parameters, or host vari-
ables.
Format
<general value specification> ::=

| <dynamic parameter specification>
| <embedded variable specification>
| CURRENT_DEFAULT_TRANSFORM_GROUP
| CURRENT_TRANSFORM_GROUP_FOR_TYPE <user-defined type>
<simple value specification> ::=

| <embedded variable name>
<target specification> ::=

| <dynamic parameter specification>
| <embedded variable specification>
<simple target specification> ::=

| <embedded variable name>
<dynamic parameter specification> ::= <question mark>
<embedded variable specification> ::=

<embedded variable name> [ <indicator variable> ]
<indicator variable> ::=

[ INDICATOR ] <embedded variable name>
Syntax Rules
1) Insert this SR The declared type of an <indicator variable> shall be exact numeric with a scale of
0 (zero).
2) Insert this SR Each <embedded variable name> shall be contained in an <embedded SQL state-
ment>.
3) Insert this SR Each <dynamic parameter specification> shall be contained in a <preparable

statement> that is dynamically prepared in the current SQL-session through the execution of a
<prepare statement>.
Scalar expressions 37
6.1 <value specification> and <target specification>
4) Insert this SR The data type of CURRENT_DEFAULT_TRANSFORM_GROUP and of CURRENT_

TRANSFORM_GROUP_FOR_TYPE <user-defined type> is a character string. Whether the
character string is fixed length or variable length, and its length if fixed length or maximum
length if variable length, are implementation-defined. The character set of the character string
is SQL_IDENTIFIER.
Access Rules
General Rules
1) Insert this GR A <dynamic parameter specification> identifies a parameter used by a dynamically
prepared statement.
2) Insert this GR An <embedded variable specification> identifies a host variable or a host variable
and an indicator variable.
3) Augments GR3) A <target specification> specifies a parameter used in a dynamically prepared

statement or a host variable that can be assigned a value.
4) Insert this GR If an <embedded variable specification> contains an <indicator variable> and the
value of the indicator variable is negative, then the value specified by the <embedded variable
specification> is null; otherwise, the value specified by a <embedded variable specification> is
the value of the host variable identified by the <embedded variable name>.
5) Insert this GR The value specified by CURRENT_DEFAULT_TRANSFORM_GROUP is the

character string that represents the default transform group name associated with the SQL-
session.
6) Insert this GR The value specified by CURRENT_TRANSFORM_GROUP_FOR_TYPE <user-

defined type> is the character string that represents the transform group name associated with
the data type specified by <user-defined type>.
Conformance Rules
1) Insert this CR Without Feature F611, ‘‘Indicator data types’’, the specific declared types of <in-
dicator parameter>s and <indicator variable>s shall be the same implementation-defined data
type.
2) Insert this CR Without Feature B031, ‘‘Basic dynamic SQL’’, a <general value specification> shall
not be a <dynamic parameter specification>.

6.2 <column reference>
6.2 <column reference>
Function
Reference a column.
Format
Syntax Rules
No additional Syntax Rules.
Access Rules
1) Insert this AR If CR is a <column reference> whose qualifying table is a base table or a viewed
derived table and that is contained in any of:
— A <query expression> simply contained in a <direct select statement: multiple rows>.
— A <sort specification list> contained in a <direct select statement: multiple rows>.
— A <query specification> contained in a <dynamic single row select statement>.

then let C be the column referenced by CR.
Case:
a) If <column reference> is contained in an <SQL schema statement>, then the applicable

privileges of the <authorization identifier> that owns the containing schema shall include
SELECT for C.
b) Otherwise, the current privileges shall include SELECT for C.

NOTE 5 – ‘‘User privileges’’ and ‘‘applicable privileges’’ are defined in Subclause 10.5, "<privileges>", in
ISO/IEC 9075-2.
General Rules
Conformance Rules
Scalar expressions 39
6.3 <interval value expression>
6.3 <interval value expression>
Function
Specify an interval value.
Format
<interval primary> ::=

<value expression primary> [ <interval qualifier> ]
| <interval value function>
Syntax Rules
1) Insert this SR An <interval primary> shall specify <interval qualifier> only if the <interval
primary> specifies a <dynamic parameter specification>.
Access Rules
General Rules
1) Insert before GR3)a) If IP immediately contains a <value expression primary> VEP and an
explicit <interval qualifier> IQ, then the value of IP is computed by:
CAST (VEP AS INTERVAL IQ)
Conformance Rules

7 Query expressions
7.1 <table reference>
Function
Reference a table.
Format
Syntax Rules
Access Rules
1) Insert this AR If the <table reference> is contained in a <direct select statement: multiple rows>
then the current privileges shall include SELECT for at least one column of T.
General Rules
Conformance Rules
Query expressions 41
7.2 <query specification>
>
7.2 <query specification>
Function
Specify a table derived from the result of a <table expression>.
Format
Syntax Rules
1) Insert after SR16)a)ii) An <indicator variable>.
2) Insert after SR16)a)ii) A <dynamic parameter specification>.
Access Rules
General Rules
Conformance Rules

8 Additional common elements
8.1 <routine invocation>
Function
Invoke an SQL-invoked routine.
Format
Syntax Rules
1) Replace SR8)c)i)4)A) If Ai is an <embedded variable name> or a <host parameter specification>,
then Pi shall be assignable to Ai , according to the Syntax Rules of Subclause 9.1, "Retrieval
assignment", with Ai and Pi as TARGET and VALUE, respectively.
Access Rules
General Rules
Conformance Rules
Additional common elements 43


9 Data assignment rules and routine determination
9.1 Retrieval assignment
Function
Specify rules for assignments to targets that do not support null values or that support null values
with indicator parameters (e.g., assigning SQL-data to host variables).
Syntax Rules
1) Replace SR3)a) If T is either a locator parameter of an external routine, a locator variable, or a
host parameter that is a character large object locator parameter, then the declared type of V
shall be character large object type and the character string type of T and the declared type of
V shall be mutually assignable.
Access Rules
General Rules
1) Insert before GR3) If V is the null value and T is a host variable, then
Case:
a) If an indicator variable is specified for T, then that indicator variable is set to 01.
b) If no indicator variable is specified for T, then an exception condition is raised: data excep-
tion — null value, no indicator parameter.
2) Insert after GR3) If V is not the null value, T is a host variable, and T has an indicator variable,
then
Case:
a) If the declared type of T is character string, bit string, or binary string and the length in
characters, bits, or octets, respectively, M of V is greater than the length in characters,
bits, or octets, respectively, of T, then the indicator parameter is set to M. If M exceeds the
maximum value that the indicator parameter can contain, then an exception condition is
raised: data exception — indicator overflow.
b) Otherwise, the indicator variable is set to 0 (zero).
Data assignment rules and routine determination 45

9.2 Store assignment
9.2 Store assignment
Function
Specify rules for assignments where the target permits null without the use of indicator variables,
such as storing SQL-data.
Syntax Rules
Access Rules
General Rules
1) Insert before GR2)a)iii) If V is a host variable and contains an indicator variable, then
Case:
1) If the value of the indicator variable is equal to 01, then T is set to the null value.
2) If the value of the indicator variable is less than 01, then an exception condition is raised:
data exception — invalid indicator parameter value.

9.3 Data types of results of aggregations
9.3 Data types of results of aggregations
Function
Specify the result data type of the result of an aggregation over values of compatible data types,
such as <case expression>s, <collection value expression>s, or a column in the result of a <query
expression>.
Syntax Rules
1) Replace SR1) Let IDTS be a set of data types specified in an application of this Subclause.
let DTS be the set of data types in IDTS excluding any data types that are undefined. If the
cardinality of DTS is 0 (zero), then the result data type is undefined and no further Rules of this
Subclause are evaluated.
NOTE 6 –
The
2) notion of ‘‘undefined data type’’ is defined in Subclause 15.6, ‘‘<prepare statement>’’.
Access Rules
General Rules
Data assignment rules and routine determination 47


10 Schema definition and manipulation
10.1 <check constraint definition>
Function
Specify a condition for the SQL-data.
Format
Syntax Rules
1) Insert this SR The <search condition> shall also not contain an <embedded variable specifica-
tion> or a <dynamic parameter specification>.
Access Rules
1) No additional Access Rules.
General Rules
1) No additional General Rules.
Conformance Rules
Schema definition and manipulation 49

10.2 <view definition>
10.2 <view definition>
Function
Define a viewed table.
Format
Syntax Rules
1) Insert this SR The <view definition> shall not contain an <embedded variable specification> or a
<dynamic parameter specification>.
Access Rules
General Rules
Conformance Rules

10.3 <assertion definition>
10.3 <assertion definition>
Function
Specify an integrity constraint by means of an assertion and specify when the assertion is to be
checked.
Format
Syntax Rules
1) Augments SR4) The <search condition> shall also not contain an <embedded variable specifica-
tion> or a <dynamic parameter specification>.
Access Rules
General Rules
Conformance Rules

10.4 <trigger definition>
10.4 <trigger definition>
Function
Define triggered SQL-statements.
Format
Syntax Rules
1) Insert this SR The <triggered action> shall not contain a <dynamic parameter specification> or
an <embedded variable name>.
2) Insert this SR The <triggered SQL statement> shall not generally contain an <SQL dynamic
statement>.
Access Rules
General Rules
Conformance Rules

10.5 <SQL-invoked routine>
10.5 <SQL-invoked routine>
Function
Define an SQL-invoked routine.
Format
Syntax Rules
1) Insert before SR18)c) The <SQL routine body> shall not contain an <SQL dynamic statement>.
2) An <SQL-invoked routine> shall not contain a <dynamic parameter specification>

Insert this SR
or an <embedded variable name>.
Access Rules
General Rules
Conformance Rules


11 SQL-client modules
11.1 <SQL-client module definition>
Function
Define an SQL-client module.
Format
<module authorization clause> ::=

SCHEMA <schema name>
| AUTHORIZATION <module authorization identifier>
[ FOR STATIC { ONLY | AND DYNAMIC } ]
| SCHEMA <schema name> AUTHORIZATION <module authorization identifier>
<module contents> ::=

| <dynamic declare cursor>
Syntax Rules
1) Insert this SR A <dynamic declare cursor> shall precede in the text of the <SQL-client mod-
ule definition> any <externally-invoked procedure> that references the <cursor name> of the
<dynamic declare cursor>.
2) Insert this SR If neither FOR STATIC ONLY nor FOR STATIC AND DYNAMIC is specified, then
FOR STATIC AND DYNAMIC is implicit.
Access Rules
General Rules
1) Augments GR5) After the last time that an SQL-agent performs a call of an <externally-invoked
procedure>, following the effective execution of a <rollback statement> or a <commit state-
ment>, a <deallocate descriptor statement> that specifies
DEALLOCATE DESCRIPTOR D
is effectively executed, where D is the <descriptor name> of any system descriptor area that is
currently allocated within an SQL-session associated with the SQL-agent.
SQL-client modules 55
11.1 <SQL-client module definition>
2) Insert this GR If FOR STATIC ONLY is specified, then a shadow module is effectively created to
contain <externally-invoked procedure>s corresponding to each SQL-statement that is prepared
or executed dynamically by <prepare statement>s or <execute immediate statement>s contained
in this <SQL-client module definition>.
Conformance Rules
1) Without Feature B051, ‘‘Enhanced execution rights’’, conforming SQL language
Insert this CR
shall not specify FOR STATIC ONLY or FOR STATIC AND DYNAMIC.
2) Insert this CR Without Feature B031, ‘‘Basic dynamic SQL’’, a <module contents> shall not be a

11.2 Calls to an <externally-invoked procedure>
Function
Define a routine.
Format
Syntax Rules
1) Augments SR2)e) The base type of any host parameter shall be an Ada data type declared in
an Ada package named Interfaces.SQL, as specified in ISO/IEC 9075-2, with the following
additional constants:
ATTEMPT_TO_ASSIGN_TO_NON_UPDATABLE_COLUMN_NO_SUBCLASS:
constant SQLSTATE_TYPE := "0U000";
ATTEMPT_TO_ASSIGN_TO_ORDERING_COLUMN_NO_SUBCLASS:
constant SQLSTATE_TYPE := "0V000";
DYNAMIC_SQL_ERROR_NO_SUBCLASS:
constant SQLSTATE_TYPE := "07000";
DYNAMIC_SQL_ERROR_CURSOR_SPECIFICATION_CANNOT_BE_EXECUTED:
DYNAMIC_SQL_ERROR_INVALID_DESCRIPTOR_COUNT:
DYNAMIC_SQL_ERROR_INVALID_DESCRIPTOR_INDEX:
DYNAMIC_SQL_ERROR_PREPARED_STATEMENT_NOT_A_CURSOR_SPECIFICATION:
DYNAMIC_SQL_ERROR_RESTRICTED_DATA_TYPE_ATTRIBUTE_VIOLATION:
DYNAMIC_SQL_ERROR_DATA_TYPE_TRANSFORM_FUNCTION_VIOLATION:
constant SQLSTATE_TYPE := "0700B";
DYNAMIC_SQL_ERROR_UNDEFINED_DATA_VALUE:
constant SQLSTATE_TYPE := "0700C";
DYNAMIC_SQL_ERROR_UNDEFINED_DATA_TARGET:
constant SQLSTATE_TYPE := "0700D";
DYNAMIC_SQL_ERROR_UNDEFINED_LEVEL_VALUE:
constant SQLSTATE_TYPE := "0700E";
DYNAMIC_SQL_ERROR_UNDEFINED_DATETIME_INTERVAL_CODE:
constant SQLSTATE_TYPE := "0700F";
DYNAMIC_SQL_ERROR_USING_CLAUSE_DOES_NOT_MATCH_DYNAMIC_PARAMETER_SPEC:
DYNAMIC_SQL_ERROR_USING_CLAUSE_DOES_NOT_MATCH_TARGET_SPEC:
DYNAMIC_SQL_ERROR_USING_CLAUSE_REQUIRED_FOR_DYNAMIC_PARAMETERS:
DYNAMIC_SQL_ERROR_USING_CLAUSE_REQUIRED_FOR_RESULT_FIELDS:
INVALID_CHARACTER_SET_NAME_NO_SUBCLASS:
constant SQLSTATE_TYPE :="2C000";
INVALID_SCHEMA_NAME_LIST_SPECIFICATION_NO_SUBCLASS:
constant SQLSTATE_TYPE :="0E000";
INVALID_SQL_INVOKED_PROCEDURE_REFERENCE_NO_SUBCLASS:
constant SQLSTATE_TYPE :="0M000";
INVALID_TRANSFORM_GROUP_NAME_SPECIFICATION_NO_SUBCLASS:
constant SQLSTATE_TYPE :="0S000";

TARGET_TABLE_DISAGREES_WITH_CURSOR_SPECIFICATION_NO_SUBCLASS:
constant SQLSTATE_TYPE :="0T000";
WARNING_INSUFFICIENT_ITEM_DESCRIPTOR_AREAS:
Access Rules
General Rules
Conformance Rules

11.3 <SQL procedure statement>
Function
Define all of the SQL-statements that are <SQL procedure statement>s.
Format
<SQL executable statement> ::=

| <SQL dynamic statement>
<SQL session statement> ::=

| <set session characteristics statement>
| <set catalog statement>
| <set schema statement>
| <set names statement>
| <set path statement>
| <set transform group statement>
<SQL dynamic statement> ::=

<system descriptor statement>
| <prepare statement>
| <deallocate prepared statement>
| <describe statement>
| <execute statement>
| <execute immediate statement>
| <SQL dynamic data statement>
<SQL dynamic data statement> ::=

<allocate cursor statement>
| <dynamic open statement>
| <dynamic fetch statement>
| <dynamic close statement>
| <dynamic delete statement: positioned>
| <dynamic update statement: positioned>
<system descriptor statement> ::=

<allocate descriptor statement>
| <deallocate descriptor statement>
| <set descriptor statement>
| <get descriptor statement>
Syntax Rules
Access Rules
General Rules
1) Replace GR2) If the non-dynamic or dynamic execution of an <SQL data statement>, <SQL
dynamic data statement>, <dynamic select statement>, or <dynamic single row select state-
ment> occurs within the same SQL-transaction as the non-dynamic or dynamic execution of
an SQL-schema statement and this is not allowed by the SQL-implementation, then an ex-
ception condition is raised: invalid transaction state — schema and data statement mixing not
supported.
2) Replace GR5)a)i)6) If S successfully initiated or resumed an SQL-session, then subsequent calls

to an <externally-invoked procedure> and subsequent invocations of <direct SQL statement>s
by the SQL-agent are associated with the SQL-session until the SQL-agent terminates the
SQL-session or makes it dormant.
3) Replace GR5)a)iii)1)D) Subsequent calls to an <externally-invoked procedure> and subsequent

invocations of <direct SQL statement>s by the SQL-agent are associated with the SQL-session
until the SQL-agent terminates the SQL-session or makes it dormant.
4) Replace GR5)a)iii)3)A) An SQL-transaction is effectively initiated and associated with this call
and with subsequent calls of any <externally-invoked procedure> by that SQL-agent and with
this and subsequent invocations of <direct SQL statement>s by that SQL-agent until the SQL-
agent terminates that SQL-transaction.
Conformance Rules
1) Insert this CR Without Feature B031, ‘‘Basic dynamic SQL’’, an <SQL procedure statement>
shall not be an <SQL dynamic statement>.

12 Data manipulation
12.1 <select statement: single row>
Function
Retrieve values from a specified row of a table.
Format
Syntax Rules
1) Insert after SR4) For each <target specification> TS that is an <embedded variable name>,
then the Syntax Rules of Subclause 9.1, ‘‘Retrieval assignment’’, shall apply to TS and the
corresponding element of the <select list>, as TARGET and VALUE, respectively.
Access Rules
None.
General Rules
1) Insert before GR6) If the <target specification> TS is an <embedded variable name>, then the
first value in the row of Q is assigned to TS according to the General Rules of Subclause 9.1,
‘‘Retrieval assignment’’, as VALUE and TARGET, respectively.
2) Insert after GR5) For each <target specification> TS that is an <embedded variable name>,
the corresponding value in the row of Q is assigned to TS according to the General Rules of
Subclause 9.1, ‘‘Retrieval assignment’’, as VALUE and TARGET, respectively. The assignment
of values to targets in the <select target list> is in an implementation-dependent order.
Conformance Rules
Data manipulation 61
12.2 <free locator statement>
12.2 <free locator statement>
Function
Remove the association between a locator variable and the value that is represented by that locator.
Format
<locator reference> ::=

| <host variable name>
Syntax Rules
1) Insert after SR1) Each host variable identified by the <host variable name> immediately con-
tained in <locator reference> shall be a binary object locator variable, a character large object
locator variable, an array locator variable, or a user-defined type locator variable.
Access Rules
General Rules
Conformance Rules

13 Transaction management
13.1 <commit statement>
Function
Terminate the current SQL-transaction with commit.
Format
Syntax Rules
Access Rules
General Rules
1) Insert this GR The <statement name> or <extended statement name> of every held cursor re-
mains valid.
Conformance Rules
Transaction management 63

14 Session management
14.1 <set catalog statement>
Function
Set the default catalog name for unqualified <schema name>s in <preparable statement>s that
are prepared in the current SQL-session by an <execute immediate statement> or a <prepare
statement> and in <direct SQL statement>s that are invoked directly.
Format
<set catalog statement> ::=

SET <catalog name characteristic>
<catalog name characteristic> ::=

CATALOG <value specification>
Syntax Rules
1) The declared type of the <value specification> shall be an SQL character data type.
Access Rules
None.
General Rules
1) Let S be <value specification> and let V be the character string that is the value of
TRIM ( BOTH ’ ’ FROM S )
2) If V does not conform to the Format and Syntax Rules of a <catalog name>, then an exception
condition is raised: invalid catalog name.
3) The default catalog name of the current SQL-session is set to V.
Conformance Rules
1) Without Feature F761, ‘‘Session management’’, and Feature F651, ‘‘Catalog name qualifiers’’,
conforming SQL language shall not contain any <set catalog statement>.
Session management 65
14.2 <set schema statement>
14.2 <set schema statement>
Function
Set the default schema name for unqualified <schema qualified name>s in <preparable statement>s
that are prepared in the current SQL-session by an <execute immediate statement> or a <prepare
Format
<set schema statement> ::=

SET <schema name characteristic>
<schema name characteristic> ::=

SCHEMA <value specification>
Syntax Rules
Access Rules
None.
General Rules
2) If V does not conform to the Format and Syntax Rules of a <schema name>, then an exception
condition is raised: invalid schema name.
3) Case:
a) If V conforms to the Format and Syntax Rules for a <schema name> that contains a <catalog
name>, then let X be the <catalog name> part and let Y be the <unqualified schema name>
part of V. The following statement is implicitly executed:
SET CATALOG ’X’
and the <set schema statement> is effectively replaced by:
SET SCHEMA ’Y’
b) Otherwise, the default unqualified schema name of the current SQL-session is set to V.
Conformance Rules
1) Without Feature F761, ‘‘Session management’’, conforming SQL language shall not contain any
<set schema statement>.

14.3 <set names statement>
14.3 <set names statement>
Function
Set the default character set name for <character string literal>s in <preparable statement>s that
are prepared in the current SQL-session by an <execute immediate statement> or a <prepare
Format
<set names statement> ::=

SET <character set name characteristic>
<character set name characteristic> ::=

NAMES <value specification>
Syntax Rules
Access Rules
None.
General Rules
2) If V does not conform to the Format and Syntax Rules of a <character set name>, then an
exception condition is raised: invalid character set name.
3) The default character set name of the current SQL-session is set to V.
Conformance Rules
1) Without Feature F761, ‘‘Session management’’, and either Feature F451, ‘‘Character set defini-
tion’’, or Feature F461, ‘‘Named character sets’’, conforming SQL language shall not contain any
<set names statement>.
14.4 <set path statement>
14.4 <set path statement>
Function
Set the SQL-path used to determine the subject routine of <routine invocation>s with unqualified
<routine name>s in <preparable statement>s that are prepared in the current SQL-session by
an <execute immediate statement> or a <prepare statement> and in <direct SQL statement>s,
respectively, that are invoked directly. The SQL-path remains the current SQL-path of the SQL-
session until another SQL-path is successfully set.
Format
<set path statement> ::=

SET <SQL-path characteristic>
<SQL-path characteristic> ::=

PATH <value specification>
Syntax Rules
Access Rules
None.
General Rules
a) If V does not conform to the Format and Syntax Rules of a <schema name list>, then an
exception condition is raised: invalid schema name list specification.
b) The SQL-path of the current SQL-session is set to V.

NOTE 7 – A <set path statement> that is executed between a <prepare statement> and an <execute
statement> has no effect on the prepared statement.
Conformance Rules
1) Without Feature S071, ‘‘SQL paths in function and type name resolution’’, Conforming SQL
language shall not contain any <set path statement>.

14.5 <set transform group statement>
14.5 <set transform group statement>
Function
Set the group name that identifies the group of transform functions for mapping values of user-
defined data types to predefined data types.
Format
<set transform group statement> ::=

SET <transform group characteristic>
<transform group characteristic> ::=

DEFAULT TRANSFORM GROUP <value specification>
| TRANSFORM GROUP FOR TYPE <user-defined type> <value specification>
Syntax Rules
1) The data type of the <value specification> shall be an SQL character data type.
2) If ‘‘TRANSFORM GROUP FOR TYPE’’ is specified, then let UDT be the user-defined type
identified by <user-defined type>.
Access Rules
None.
General Rules
a) If V does not conform to the Format and Syntax Rules of an <identifier>, then an exception
condition is raised: invalid transform group name specification.
b) Case:
i) If ‘‘TRANSFORM GROUP FOR TYPE’’ is specified, then the transform group name
corresponding to all subtypes of UDT for the current SQL-session is set to V.
ii) Otherwise, the default transform group name for the current SQL-session is set to V.
NOTE 8 – A <set transform group statement> that is executed after a <prepare statement> has no
effect on the prepared statement.
Conformance Rules
1) Without Feature S241, ‘‘Transform functions’’, conforming SQL language shall not contain any
<set transform group statement>.

15 Dynamic SQL
15.1 Description of SQL descriptor areas
Function
Specify the identifiers, data types, and codes used in SQL item descriptor areas.
Syntax Rules
1) An SQL item descriptor area comprises the items specified in Table 3, ‘‘Data types of <key
word>s used in SQL item descriptor areas’’.
2) An SQL descriptor area comprises the items specified in Table 2, ‘‘Data types of <key word>s
used in the header of SQL descriptor areas’’, and one or more occurrences of an SQL item
descriptor area.
3) Given an SQL item descriptor area IDA in which the value of LEVEL is N, the immediately
subordinate descriptor areas of IDA are those SQL item descriptor areas in which the value of
LEVEL is N+1 and whose position in the SQL descriptor area follows that of IDA and precedes
that of any SQL item descriptor area in which the value of LEVEL is less than N+1.
The subordinate descriptor areas of IDA are those SQL item descriptor areas that are immedi-
ately subordinate descriptor areas of IDA or that are subordinate descriptor areas of an SQL
item descriptor area that is immediately subordinate to IDA.
4) Given a data type DT and its descriptor DE, the immediately subordinate descriptors of DE are
defined to be:
Case:
a) If DT is a row type, then the field descriptors of the fields of DT. The i-th immediately
subordinate descriptor is the descriptor of the i-th field of DT.
b) If DT is a collection type, then the descriptor of the associated element type of DT.
The subordinate descriptors of DE are those descriptors that are immediately subordinate
descriptors of DE or that are subordinate descriptors of a descriptor that is immediately subor-
dinate to DE.
5) Given a descriptor DE, let SDEj represent its j-th immediately subordinate descriptor. There is
an implied ordering of the subordinate descriptors of DE, such that:
a) SDE1 is in the first ordinal position.
b) The ordinal position of SDEj+1 is K+NS+1, where K is the ordinal position of SDEj and
NS is the number of subordinate descriptors of SDEj . The implicitly ordered subordinate
descriptors of SDEj occupy contiguous ordinal positions starting at position K+1.
6) An item descriptor area IDA is valid if and only if TYPE indicates a code defined in Table 4,
‘‘Codes used for SQL data types in Dynamic SQL’’, and one of the following is true:
Dynamic SQL 71
Case:
a) TYPE indicates NUMERIC and PRECISION and SCALE are valid precision and scale
values for the NUMERIC data type.
b) TYPE indicates DECIMAL and PRECISION and SCALE are valid precision and scale values
for the DECIMAL data type.
c) TYPE indicates FLOAT and PRECISION is a valid precision value for the FLOAT data type.
d) TYPE indicates INTEGER, SMALLINT, REAL, or DOUBLE PRECISION.
e) TYPE indicates BOOLEAN.
f) TYPE indicates BIT or BIT VARYING and LENGTH is a valid length value for the BIT data
type.
g) TYPE indicates CHARACTER, CHARACTER VARYING, or CHARACTER LARGE

OBJECT, LENGTH is a valid length value for TYPE, and CHARACTER_SET_CATALOG,
CHARACTER_SET_SCHEMA, and CHARACTER_SET_NAME are a valid qualified charac-
ter set name for TYPE.
h) TYPE indicates BINARY LARGE OBJECT and LENGTH is a valid length value for the
BINARY LARGE OBJECT data type.
i) TYPE indicates CHARACTER LARGE OBJECT LOCATOR.
j) TYPE indicates BINARY LARGE OBJECT LOCATOR.
k) TYPE indicates USER-DEFINED TYPE LOCATOR and USER_DEFINED_TYPE_

CATALOG, USER_DEFINED_TYPE_SCHEMA, and USER_DEFINED_TYPE_NAME are a
valid qualified user-defined type name.
l) TYPE indicates a <datetime type>, DATETIME_INTERVAL_CODE is a code specified in

Table 5, ‘‘Codes associated with datetime data types in Dynamic SQL’’, and PRECISION is a
valid value for the <time precision> or <timestamp precision> of the indicated datetime data
type.
m) TYPE indicates an <interval type>, DATETIME_INTERVAL_CODE is a code specified

in Table 6, ‘‘Codes used for <interval qualifier>s in Dynamic SQL’’, and DATETIME_
INTERVAL_PRECISION and PRECISION are valid values for <interval leading field
precision> and <interval fractional seconds precision> for an <interval qualifier>.
n) TYPE indicates REF, LENGTH is the implementation-defined length in octets for the REF
type, and USER_DEFINED_TYPE_CATALOG, USER_DEFINED_TYPE_SCHEMA, and
USER_DEFINED_TYPE_NAME are a valid qualified user-defined type name, and SCOPE_
CATALOG, SCOPE_SCHEMA, and SCOPE_NAME are a valid qualified table name.
o) TYPE indicates ROW, the value N of DEGREE is a valid value for the degree of a row type,
there are exactly N immediately subordinate descriptor areas of IDA and those SQL item
descriptor areas are valid.
p) TYPE indicates ARRAY or ARRAY LOCATOR, the value of CARDINALITY is a valid value
for the cardinality of an array, there is exactly one immediately subordinate descriptor area
of IDA and that SQL item descriptor area is valid.

q) TYPE indicates an implementation-defined data type.
7) The declared type T of a <simple value specification> or a <simple target specification> SVT is
said to match the data type specified by a valid item descriptor area IDA if and only if one of
the following conditions is true.
Case:
a) TYPE indicates NUMERIC and T is specified by NUMERIC(P,S), where P is the value of

PRECISION and S is the value of SCALE.
b) TYPE indicates DECIMAL and T is specified by DECIMAL(P,S), where P is the value of

PRECISION and S is the value of SCALE.
c) TYPE indicates INTEGER and T is specified by INTEGER.
d) TYPE indicates SMALLINT and T is specified by SMALLINT.
e) TYPE indicates FLOAT and T is specified by FLOAT(P), where P is the value of PRECISION.
f) TYPE indicates REAL and T is specified by REAL.
g) TYPE indicates DOUBLE PRECISION and T is specified by DOUBLE PRECISION.
h) TYPE indicates BOOLEAN and T is specified by BOOLEAN.
i) TYPE indicates BIT and T is specified by BIT(L), where L is the value of LENGTH.
j) TYPE indicates BIT VARYING and T is specified by BIT VARYING(L), where

Case:
i) SVT is a <simple value specification> and L is the value of LENGTH.
ii) SVT is a <simple target specification> and L is not less than the value of LENGTH.
k) TYPE indicates CHARACTER and T is specified by CHARACTER(L), where L is the value

of LENGTH and the <character set specification> formed by the values of CHARACTER_
SET_CATALOG, CHARACTER_SET_SCHEMA, and CHARACTER_SET_NAME identifies
the character set of SVT.
l) Either TYPE indicates CHARACTER VARYING and T is specified by CHARACTER

VARYING(L) or type indicates CHARACTER LARGE OBJECT and T is specified by
CHARACTER LARGE OBJECT(L), where the <character set specification> formed
by the values of CHARACTER_SET_CATALOG, CHARACTER_SET_SCHEMA, and
CHARACTER_SET_NAME identifies the character set of SVT and
Case:
i) SVT is a <simple value specification> and L is the value of LENGTH.
ii) SVT is a <simple target specification> and L is not less than the value of LENGTH.
m) TYPE indicates BINARY LARGE OBJECT and T is specified by BINARY LARGE

OBJECT(L) and
Dynamic SQL 73
Case:
i) STV is a <simple value specification> and L is the value of LENGTH.
ii) STV is a <simple target specification> and L is not less than the value of LENGTH.
n) TYPE indicates CHARACTER LARGE OBJECT LOCATOR and T is specified by

CHARACTER LARGE OBJECT LOCATOR.
o) TYPE indicates BINARY LARGE OBJECT LOCATOR and T is specified by BINARY LARGE
OBJECT LOCATOR.
p) TYPE indicates USER-DEFINED TYPE and T is specified by USER-DEFINED TYPE

LOCATOR, where the <user-defined type name> formed by the values of USER_DEFINED_
TYPE_CATALOG, USER_DEFINED_TYPE_SCHEMA, and USER_DEFINED_TYPE_NAME
identifies the associated user-defined type of SVT.
q) TYPE indicates REF and T is specified by REF, where the <user-defined type name> formed
by the values of USER_DEFINED_DATA_TYPE_CATALOG, USER_DEFINED_DATA_
TYPE_SCHEMA, and USER_DEFINED_DATA_TYPE_NAME identifies the row type of
SVT, and SCOPE_CATALOG, SCOPE_SCHEMA, and SCOPE_NAME identify the scope of
the reference type.
r) TYPE indicates ROW, and T is a row type with degree D, where D is the value of DEGREE,
and the data type of the i-th field of SVT matches the data type specified by the i-th imme-
diately subordinate descriptor area of IDA.
s) TYPE indicates ARRAY and T is an array type with cardinality C and the data type of the
element type of T matches the immediately subordinate descriptor area of IDA, and
Case:
i) SVT is a <simple value specification> and C is the value of CARDINALITY.
ii) SVT is a <simple target specification> and C is not less than the value of CARDINALITY.
t) TYPE indicates ARRAY LOCATOR and T is an array locator type whose associated array
type has cardinality C and the data type of the element type of the associated array type of
T matches the immediately subordinate descriptor area of IDA, and
Case:
i) SVT is a <simple value specification> and C is the value of CARDINALITY.
ii) SVT is a <simple target specification> and C is not less than the value of CARDINALITY.
u) TYPE indicates a data type from Table 4, ‘‘Codes used for SQL data types in Dynamic SQL’’,
other than an implementation-defined data type and T satisfies the implementation-defined
rules for matching that data type.
v) TYPE indicates an implementation-defined data type and T satisfies the implementation-

defined rules for matching that data type.
8) A data type DT is said to be represented by an SQL item descriptor area if a <simply value
specification> of type DT matches the SQL item descriptor area.

Table 2—Data types of <key word>s used in the header of SQL descriptor areas
<key word> Data Type
COUNT exact numeric with scale 0 (zero)

DYNAMIC_FUNCTION character string with character set SQL_IDENTIFIER and length
not less than 128 characters
DYNAMIC_FUNCTION_CODE exact numeric with scale 0 (zero)
KEY_TYPE exact numeric with scale 0 (zero)
TOP_LEVEL_COUNT exact numeric with scale 0 (zero)
Table 3—Data types of <key word>s used in SQL item descriptor areas
CARDINALITY exact numeric with scale 0 (zero)

CHARACTER_SET_CATALOG character string with character set SQL_IDENTIFIER and length
CHARACTER_SET_NAME character string with character set SQL_IDENTIFIER and length
CHARACTER_SET_SCHEMA character string with character set SQL_IDENTIFIER and length
COLLATION_CATALOG character string with character set SQL_IDENTIFIER and length
COLLATION_NAME character string with character set SQL_IDENTIFIER and length
COLLATION_SCHEMA character string with character set SQL_IDENTIFIER and length
DATA matches the data type represented by the SQL item descriptor area
DATETIME_INTERVAL_CODE exact numeric with scale 0 (zero)
DATETIME_INTERVAL_ exact numeric with scale 0 (zero)
PRECISION
DEGREE exact numeric with scale 0 (zero)
INDICATOR exact numeric with scale 0 (zero)
KEY_MEMBER exact numeric with scale 0 (zero)
LENGTH exact numeric with scale 0 (zero)
LEVEL exact numeric with scale 0 (zero)
NAME character string with character set SQL_IDENTIFIER and length
NULLABLE exact numeric with scale 0 (zero)
OCTET_LENGTH exact numeric with scale 0 (zero)
PARAMETER_MODE exact numeric with scale 0 (zero)
Dynamic SQL 75
Table 3—Data types of <key word>s used in SQL item descriptor areas (Cont.)
PARAMETER_ORDINAL_ exact numeric with scale 0 (zero)
POSITION
PARAMETER_SPECIFIC_ character string with character set SQL_IDENTIFIER and length
CATALOG not less than 128 characters
NAME not less than 128 characters
SCHEMA not less than 128 characters
PRECISION exact numeric with scale 0 (zero)
RETURNED_CARDINALITY exact numeric with scale 0 (zero)
RETURNED_LENGTH exact numeric with scale 0 (zero)
RETURNED_OCTET_LENGTH exact numeric with scale 0 (zero)
SCALE exact numeric with scale 0 (zero)
SCOPE_CATALOG character string with character set SQL_IDENTIFIER and length
SCOPE_NAME character string with character set SQL_IDENTIFIER and length
SCOPE_SCHEMA character string with character set SQL_IDENTIFIER and length
TYPE exact numeric with scale 0 (zero)
UNNAMED exact numeric with scale 0 (zero)
USER_DEFINED_TYPE_ character string with character set SQL_IDENTIFIER and length
CATALOG not less than 128 characters
USER_DEFINED_TYPE_NAME character string with character set SQL_IDENTIFIER and length
USER_DEFINED_TYPE_ character string with character set SQL_IDENTIFIER and length
SCHEMA not less than 128 characters
NOTE 9 – ‘‘Matches’’ and ‘‘represented by’’, as applied to the relationship between a data type and an
SQL item descriptor area are defined in the Syntax Rules of this Subclause.
Access Rules
None.
General Rules
1) Table 4, ‘‘Codes used for SQL data types in Dynamic SQL’’, specifies the codes associated with
the SQL data types.

Table 4—Codes used for SQL data types in Dynamic SQL

Data Type Code
Implementation-defined data < 0 (zero)

types
ARRAY 50
ARRAY LOCATOR 51
BIT 14
BIT VARYING 15
BLOB 30
BLOB LOCATOR 31
BOOLEAN 16
CHARACTER 1 (one)
CHARACTER VARYING 12
CLOB 40
CLOB LOCATOR 41
DATE, TIME WITHOUT 9
TIME ZONE, TIME WITH
TIME ZONE, TIMESTAMP
WITHOUT TIME ZONE, or
TIMESTAMP WITH TIME
ZONE
DECIMAL 3
DOUBLE PRECISION 8
FLOAT 6
INTEGER 4
INTERVAL 10
NUMERIC 2
REAL 7
SMALLINT 5
USER-DEFINED TYPE 18
LOCATOR
ROW TYPE 19
REF 20
User-defined types 17
2) Table 5, ‘‘Codes associated with datetime data types in Dynamic SQL’’, specifies the codes
associated with the datetime data types.
Dynamic SQL 77
Table 5—Codes associated with datetime data types in Dynamic SQL

Datetime Data Type Code
DATE 1 (one)
TIME WITH TIME ZONE 4
TIME WITHOUT TIME 2
ZONE
TIMESTAMP WITH TIME 5
ZONE
TIMESTAMP WITHOUT 3
TIME ZONE
3) Table 6, ‘‘Codes used for <interval qualifier>s in Dynamic SQL’’, specifies the codes associated
with <interval qualifier>s for interval data types.
Table 6—Codes used for <interval qualifier>s in Dynamic SQL

Datetime Qualifier Code
DAY 3
DAY TO HOUR 8
DAY TO MINUTE 9
DAY TO SECOND 10
HOUR 4
HOUR TO MINUTE 11
HOUR TO SECOND 12
MINUTE 5
MINUTE TO SECOND 13
MONTH 2
SECOND 6
YEAR 1 (one)
YEAR TO MONTH 7
4) The value of DYNAMIC_FUNCTION is a character string that identifies the type of the pre-
pared or executed SQL-statement. Table 9, ‘‘SQL-statement codes’’, specifies the identifier of the
SQL-statements.
5) The value of DYNAMIC_FUNCTION_CODE is a number that identifies the type of the prepared
or executed SQL-statement. Table 9, ‘‘SQL-statement codes’’, specifies the identifier of the
SQL-statements.
6) Table 7, ‘‘Codes used for input/output SQL parameter modes in Dynamic SQL’’, specifies the
codes used for the PARAMETER_MODE item descriptor field when describing a <call state-
ment>.

Table 7—Codes used for input/output SQL parameter modes in Dynamic SQL
Parameter mode Code
PARAMETER_MODE_IN 1 (one)
PARAMETER_MODE_INOUT 2
PARAMETER_MODE_OUT 4
Conformance Rules
None.
Dynamic SQL 79
15.2 <allocate descriptor statement>
Function
Allocate an SQL descriptor area.
Format
<allocate descriptor statement> ::=

ALLOCATE [ SQL ] DESCRIPTOR <descriptor name> [ WITH MAX <occurrences> ]
<occurrences> ::= <simple value specification>
Syntax Rules
1) The declared type of <occurrences> shall be exact numeric with scale 0 (zero).
2) If WITH MAX <occurrences> is not specified, then an implementation-defined default value for
<occurrences> that is greater than 0 (zero) is implicit.
Access Rules
None.
General Rules
1) Let S be the <simple value specification> that is immediately contained in <descriptor name>
and let V be the character string that is the result of
If V does not conform to the Format and Syntax Rules of an <identifier>, then an exception
condition is raised: invalid SQL descriptor name.
2) The <allocate descriptor statement> allocates an SQL descriptor area whose name is V and
whose scope is specified by the <scope option>. The descriptor area will have at least <occur-
rences> number of item descriptor areas. The value of LEVEL in each of the item descriptor
areas is set to 0 (zero). The values of all other fields in the SQL descriptor area are initially
undefined. If an SQL descriptor has already been allocated whose name is V, whose scope
is specified by the <scope option>, and that has not yet been deallocated, then an exception
3) If <occurrences> is less than 1 (one) or is greater than an implementation-defined maximum

value, then an exception condition is raised: dynamic SQL error — invalid descriptor index. The
maximum number of SQL descriptor areas that can be allocated at one time is implementation-
defined.

Conformance Rules
1) Without Feature B032, ‘‘Extended dynamic SQL’’, an <occurrences> and a <descriptor name>
shall be a <literal>.
2) Without Feature B031, ‘‘Basic dynamic SQL’’, conforming SQL language shall not contain any
<allocate descriptor statement>.
Dynamic SQL 81
15.3 <deallocate descriptor statement>
15.3 <deallocate descriptor statement>
Function
Deallocate an SQL descriptor area.
Format
<deallocate descriptor statement> ::=

DEALLOCATE [ SQL ] DESCRIPTOR <descriptor name>
Syntax Rules
None.
Access Rules
None.
General Rules
1) The <deallocate descriptor statement> deallocates an SQL descriptor area whose name is the
value of the <descriptor name>’s <simple value specification> and whose scope is specified by
the <scope option>. If an SQL descriptor is not currently allocated whose name is the value of
the <descriptor name>’s <simple value specification> and whose scope is specified by the <scope
option>, then an exception condition is raised: invalid SQL descriptor name.
Conformance Rules
1) Without Feature B032, ‘‘Extended dynamic SQL’’, a <descriptor name> shall be a <literal>.
<deallocate descriptor statement>.

15.4 <get descriptor statement>
Function
Get information from an SQL descriptor area.
Format
<get descriptor statement> ::=

GET [ SQL ] DESCRIPTOR <descriptor name> <get descriptor information>
<get descriptor information> ::=

<get header information> [ { <comma> <get header information> }... ]
| VALUE <item number>
<get item information> [ { <comma> <get item information> }... ]
<get header information> ::=

<simple target specification 1> <equals operator> <header item name>
<header item name> ::=

COUNT
| KEY_TYPE
| DYNAMIC_FUNCTION
| DYNAMIC_FUNCTION_CODE
| TOP_LEVEL_COUNT
<get item information> ::=

<simple target specification 2> <equals operator> <descriptor item name>
<item number> ::= <simple value specification>
<simple target specification 1> ::= <simple target specification>
<simple target specification 2> ::= <simple target specification>
<descriptor item name> ::=

CARDINALITY
| CHARACTER_SET_CATALOG
| CHARACTER_SET_NAME
| CHARACTER_SET_SCHEMA
| COLLATION_CATALOG
| COLLATION_NAME
| COLLATION_SCHEMA
| DATA
| DATETIME_INTERVAL_CODE
| DATETIME_INTERVAL_PRECISION
| DEGREE
| INDICATOR
| KEY_MEMBER
| LENGTH
| LEVEL
| NAME
| NULLABLE
| OCTET_LENGTH
| PARAMETER_MODE
| PARAMETER_ORDINAL_POSITION
| PARAMETER_SPECIFIC_CATALOG
| PARAMETER_SPECIFIC_NAME
| PARAMETER_SPECIFIC_SCHEMA
| PRECISION
Dynamic SQL 83
| RETURNED_CARDINALITY
| RETURNED_LENGTH
| RETURNED_OCTET_LENGTH
| SCALE
| SCOPE_CATALOG
| SCOPE_NAME
| SCOPE_SCHEMA
| TYPE
| UNNAMED
| USER_DEFINED_TYPE_CATALOG
| USER_DEFINED_TYPE_NAME
| USER_DEFINED_TYPE_SCHEMA
Syntax Rules
1) The declared type of <item number> shall be exact numeric with scale 0 (zero).
2) For each <get header information>, the declared type of <simple target specification 1> shall be
that shown in the Data Type column of the row in Table 2, ‘‘Data types of <key word>s used in
the header of SQL descriptor areas’’, whose <key word> column value is equivalent to <header
item name>.
3) For each <get item information>, the declared type of <simple target specification 2> shall be
that shown in the Data Type column of the row in Table 3, ‘‘Data types of <key word>s used in
SQL item descriptor areas’’, whose <key word> column value is equivalent to <descriptor item
name>.
Access Rules
None.
General Rules
1) If a <descriptor name> specified in a <get descriptor statement> identifies an SQL descrip-
tor area that is not currently allocated, then an exception condition is raised: invalid SQL
descriptor name.
2) If the <item number> specified in a <get descriptor statement> is greater than the value of
<occurrences> specified when the <descriptor name> was allocated or less than 1 (one), then an
exception condition is raised: dynamic SQL error — invalid descriptor index.
3) If the <item number> specified in a <get descriptor statement> is greater than the value of
COUNT, then a completion condition is raised: no data.
4) If the declared type of the <simple target specification> associated with the keyword DATA does
not match the data type represented by the item descriptor area, then an exception condition is
raised: data exception — error in assignment.
NOTE 10 – ‘‘Match’’ and ‘‘represented by’’ are defined in the Syntax Rules of Subclause 15.1,
‘‘Description of SQL descriptor areas’’.

5) Let i be the value of the <item number> contained in <get descriptor information>. Let IDA be
the i-th <item descriptor area>. If a <get item information> specifies DATA, then:
a) If IDA is subordinate to an item descriptor area whose TYPE field indicates ARRAY or
ARRAY LOCATOR, then an exception condition is raised: dynamic SQL error — undefined
DATA value.
b) If the value of TYPE in IDA indicates ROW, then an exception condition is raised: dynamic
SQL error — undefined DATA value.
c) If the value of INDICATOR is negative and no <get item information> specifies INDICATOR,
then an exception condition is raised: data exception — null value, no indicator parameter.
6) If an exception condition is raised in a <get descriptor statement>, then the values of all
targets specified by <simple target specification 1> and <simple target specification 2> are
implementation-dependent.
7) A <get descriptor statement> retrieves values from the SQL descriptor area and item specified
by <descriptor name>. For each item, the value that is retrieved is the one established by the
most recently executed <allocate descriptor statement>, <set descriptor statement>, or <describe
statement> that references the specified SQL descriptor area and item. The value retrieved by a
<get descriptor statement> for any field whose value is undefined is implementation-dependent.
Case:
a) If <get descriptor information> contains one or more <get header information>s, then for
each <get header information> specified, the value of <simple target specification 1> is set
to the value V in the SQL descriptor area of the field identified by the <header item name>
by applying the General Rules of Subclause 9.2, "Store assignment", to <simple target
specification 1> and V as TARGET and VALUE, respectively.
b) If <get descriptor information> contains one or more <get item information>s, then:
i) Let i be the value of the <item number> contained in the <get descriptor information>.
ii) For each <get item information> specified, the value of <simple target specification 2> is
set to the value V in the i-th SQL item descriptor area of the field identified by the <de-
scriptor item name> by applying the General Rules of Subclause 9.2, "Store assignment",
to <simple target specification 2> and V as TARGET and VALUE, respectively.
Conformance Rules
<get descriptor statement>.
3) Without Feature T301, ‘‘Functional dependencies’’, and without Feature B031, ‘‘Basic dynamic
SQL’’, conforming SQL language shall not specify KEY_MEMBER.
Dynamic SQL 85
15.5 <set descriptor statement>
Function
Set information in an SQL descriptor area.
Format
<set descriptor statement> ::=

SET [ SQL ] DESCRIPTOR <descriptor name> <set descriptor information>
<set descriptor information> ::=

<set header information> [ { <comma> <set header information> }... ]
| VALUE <item number>
<set item information> [ { <comma> <set item information> }... ]
<set header information> ::=

<header item name> <equals operator> <simple value specification 1>
<set item information> ::=

<descriptor item name> <equals operator> <simple value specification 2>
<simple value specification 1> ::= <simple value specification>
<simple value specification 2> ::= <simple value specification>
<item number> ::= <simple value specification>
Syntax Rules
1) The declared type of <item number> shall be exact numeric with scale 0 (zero).
2) For each <set header information>, <header item name> shall not be KEY_TYPE, TOP_LEVEL_
COUNT, DYNAMIC_FUNCTION, or DYNAMIC_FUNCTION_CODE, and the declared type of
<simple value specification 1> shall be that in the Data Type column of the row of Table 2, ‘‘Data
types of <key word>s used in the header of SQL descriptor areas’’, whose <key word> column
value is equivalent to <header item name>.
3) For each <set information item>, the value of <descriptor item name> shall not be RETURNED_
LENGTH, RETURNED_OCTET_LENGTH, RETURNED_CARDINALITY, OCTET_LENGTH,
NULLABLE, KEY_MEMBER, COLLATION_CATALOG, COLLATION_SCHEMA, COLLATION_
NAME, NAME, UNNAMED, PARAMETER_MODE, PARAMETER_ORDINAL_POSITION,
PARAMETER_SPECIFIC_CATALOG, PARAMETER_SPECIFIC_SCHEMA, or PARAMETER_
SPECIFIC_NAME. Other alternatives for <descriptor item name> shall not be specified more
than once in a <set descriptor statement>. The declared type of <simple value specification 2>
shall be that shown in the Data Type column of the row in Table 3, ‘‘Data types of <key word>s
used in SQL item descriptor areas’’, whose <key word> column value is equivalent to <descriptor
item name>.
4) If the <descriptor item name> specifies DATA, then <simple value specification 2> shall not be a
<literal>.

Access Rules
None.
General Rules
1) If a <descriptor name> specified in a <set descriptor statement> identifies an SQL descrip-
tor area that is not currently allocated, then an exception condition is raised: invalid SQL
descriptor name.
2) If the <item number> specified in a <set descriptor statement> is greater than the value of
<occurrences> specified when the <descriptor name> was allocated or less than 1 (one), then an
exception condition is raised: dynamic SQL error — invalid descriptor index.
3) When more than one value is set in a single <set descriptor statement>, the values are ef-
fectively assigned in the following order: LEVEL, TYPE, DATETIME_INTERVAL_CODE,
DATETIME_INTERVAL_PRECISION, PRECISION, SCALE, CHARACTER_SET_CATALOG,
CHARACTER_SET_SCHEMA, CHARACTER_SET_NAME, USER_DEFINED_TYPE_CATALOG,
USER_DEFINED_TYPE_SCHEMA, USER_DEFINED_TYPE_NAME, SCOPE_CATALOG,
SCOPE_SCHEMA, SCOPE_NAME, LENGTH, INDICATOR, DEGREE, CARDINALITY, and
DATA.
When any value other than DATA is set, the value of DATA becomes undefined.
4) For every <set item information> specified, let DIN be the <descriptor item name>, let V be the
value of the <simple value specification 2>, let N be the value of <item number>, and let IDA be
the N-th item descriptor area.
a) If DIN is DATA, then:
i) If IDA is subordinate to an item descriptor area whose TYPE field indicates ARRAY or
ARRAY LOCATOR, then an exception condition is raised: dynamic SQL error — invalid
DATA target.
ii) If TYPE in IDA indicates ROW, then an exception condition is raised: dynamic SQL
error — invalid DATA target.
iii) If the most specific type of V does not match the data type specified by the item descrip-
tor area, then an exception condition is raised: data exception — error in assignment.
NOTE 11 – ‘‘Match’’ is defined in the Syntax Rules of Subclause 15.1, ‘‘Description of SQL
descriptor areas’’.
iv) The value of DATA in IDA is set to V.
b) If DIN is LEVEL, then:
i) If N is 1 (one) and V is not 0 (zero), then an exception condition is raised: dynamic SQL
error — invalid LEVEL value.
Dynamic SQL 87
ii) If N is greater than 1 (one), then let PIDA be IDA’s immediately preceding item descrip-
tor area and let K be its LEVEL value.
1) If V = K+1 and TYPE in PIDA does not indicate ROW, ARRAY, or ARRAY
LOCATOR, then an exception condition is raised: dynamic SQL error — invalid
LEVEL value.
2) If V > K+1, then an exception condition is raised: dynamic SQL error — invalid
LEVEL value.
3) If V < K+1, then let OIDAi be the i-th item descriptor area to which PIDA is subor-
dinate and whose TYPE field indicates ROW, let NSi be the number of immediately
subordinate descriptor areas of OIDAi between OIDAi and IDA and let Di be the
value of DEGREE in OIDAi .
A) For each OIDAi whose LEVEL value is greater than V, if Di is not equal to NSi ,
then an exception condition is raised: dynamic SQL error — invalid LEVEL
value.
B) If K is not 0 (zero), then let OIDAj be the OIDAi whose LEVEL value is K. If
there exists no such OIDAj or Dj is not greater than NSj , then an exception
condition is raised: dynamic SQL error — invalid LEVEL value.
iii) The value of LEVEL in IDA is set to V.
c) If DIN is TYPE, then:
i) The value of TYPE in IDA is set to V.
ii) The value of all fields other than TYPE and LEVEL in IDA are set to implementation-
dependent values.
iii) Case:
1) If V indicates CHARACTER, CHARACTER VARYING, or CHARACTER LARGE

OBJECT, then CHARACTER_SET_CATALOG, CHARACTER_SET_SCHEMA and
CHARACTER_SET_NAME in IDA are set to the values for the default character set
name for the SQL-session and LENGTH in IDA is set to 1 (one).
2) If V indicates CHARACTER LARGE OBJECT LOCATOR, then LENGTH in IDA is

set to 1 (one).
3) If V indicates BIT or BIT VARYING, then LENGTH in IDA is set to 1 (one).
4) If V indicates BINARY LARGE OBJECT, then LENGTH in IDA is set to 1 (one).
5) If V indicates BINARY LARGE OBJECT LOCATOR, then LENGTH in IDA is set to

1 (one).
6) If V indicates DATETIME, then PRECISION in IDA is set to 0 (zero).
7) If V indicates INTERVAL, then DATETIME_INTERVAL_PRECISION in IDA is set

to 2.
8) If V indicates NUMERIC or DECIMAL, then SCALE in IDA is set to 0 (zero) and

PRECISION in IDA is set to the implementation-defined default value for the
precision of NUMERIC or DECIMAL data types, respectively.

9) If V indicates FLOAT, then PRECISION in IDA is set to the implementation-defined

default value for the precision of the FLOAT data type.
d) If DIN is DATETIME_INTERVAL_CODE, then

Case:
i) If TYPE in IDA indicates DATETIME, then

Case:
1) If V indicates DATE, TIME, or TIME WITH TIME ZONE, then PRECISION in IDA
is set to 0 (zero) and DATETIME_INTERVAL_CODE in IDA is set to V.
2) If V indicates TIMESTAMP or TIMESTAMP WITH TIME ZONE, then PRECISION

in IDA is set to 6 and DATETIME_INTERVAL_CODE in IDA is set to V.
3) Otherwise, an exception condition is raised: dynamic SQL error — invalid

DATETIME_INTERVAL_CODE.
ii) If TYPE in IDA indicates INTERVAL, then

Case:
1) If V indicates DAY TO SECOND, HOUR TO SECOND, MINUTE TO SECOND,

or SECOND, then PRECISION in IDA is set to 6, DATETIME_INTERVAL_
PRECISION in IDA is set to 2 and DATETIME_INTERVAL_CODE in IDA is set
to V.
2) If V indicates YEAR, MONTH, DAY, HOUR, MINUTE, YEAR TO MONTH, DAY TO

HOUR, DAY TO MINUTE, or HOUR TO MINUTE, then PRECISION in IDA is set
to 0 (zero), DATETIME_INTERVAL_PRECISION in IDA is set to 2 and DATETIME_
INTERVAL_CODE in IDA is set to V.
3) Otherwise, an exception condition is raised: dynamic SQL error — invalid

DATETIME_INTERVAL_CODE.
iii) Otherwise, an exception condition is raised: dynamic SQL error — invalid DATETIME_
INTERVAL_CODE.
e) Otherwise, the value of DIN in IDA is set to V by applying the General Rules of Subclause
9.2, "Store assignment", to the field of IDA identified by DIN and V as TARGET and VALUE,
respectively. .
5) For each <set header information> specified, the value of the field identified by <header item
name> is set to the value V of <simple value specification 1> by applying the General Rules of
Subclause 9.2, "Store assignment", to the field identified by the <header item name> and V as
TARGET and VALUE, respectively.
6) If an exception condition is raised in a <set descriptor statement>, then the values of

all elements of the item descriptor area specified in the <set descriptor statement> are
7) Restrictions on changing TYPE, LENGTH, PRECISION, SCALE, DATETIME_INTERVAL_

CODE, DATETIME_INTERVAL_PRECISION, CHARACTER_SET_CATALOG, CHARACTER_
SET_SCHEMA, CHARACTER_SET_NAME, USER_DEFINED_TYPE_CATALOG, USER_
DEFINED_TYPE_SCHEMA, USER_DEFINED_TYPE_NAME, SCOPE_CATALOG, SCOPE_
Dynamic SQL 89
SCHEMA, and SCOPE_NAME values resulting from the execution of a <describe statement>
before execution of an <execute statement>, <dynamic open statement>, or <dynamic fetch
statement> are implementation-defined.
Conformance Rules
<set descriptor statement>.

15.6 <prepare statement>
Function
Prepare a statement for execution.
Format
<prepare statement> ::=

PREPARE <SQL statement name> FROM <SQL statement variable>
<SQL statement variable> ::= <simple value specification>
<preparable statement> ::=

<preparable SQL data statement>
| <preparable SQL schema statement>
| <preparable SQL transaction statement>
| <preparable SQL control statement>
| <preparable SQL session statement>
| <preparable implementation-defined statement>
<preparable SQL data statement> ::=

<delete statement: searched>
| <dynamic single row select statement>
| <insert statement>
| <dynamic select statement>
| <update statement: searched>
| <preparable dynamic delete statement: positioned>
| <preparable dynamic update statement: positioned>
<preparable SQL schema statement> ::=

<SQL schema statement>
<preparable SQL transaction statement> ::=

<SQL transaction statement>
<preparable SQL control statement> ::=

<SQL control statement>
<preparable SQL session statement> ::=

<SQL session statement>
<dynamic select statement> ::= <cursor specification>
<preparable implementation-defined statement> ::= !! See the Syntax Rules.
Syntax Rules
1) The <simple value specification> of <SQL statement variable> shall not be a <literal>.
2) The declared type of <SQL statement variable> shall be character string.
3) The Format and Syntax Rules for <preparable implementation-defined statement> are
implementation-defined.
Dynamic SQL 91
4) A <preparable SQL control statement> shall not contain an <SQL procedure statement> that is
not a <preparable statement>, nor shall it contain a <dynamic single row select statement> or a
<dynamic select statement>.
Access Rules
None.
General Rules
1) Let P be the contents of the <SQL statement variable>. If P is an <SQL control statement>,
then let PS be an <SQL procedure statement> contained in P.
2) Two subfields SF1 and SF2 of row types RT1 and RT2 are corresponding subfields if either SF1
or SF2 are positionally corresponding fields of RT1 and RT2, respectively, or SF1 and SF2 are
positionally corresponding fields of RT1SF1 and RT2SF2 and RT1SF1 and RT2SF2 are the
declared types of corresponding subfields of RT1 and RT2 respectively.
3) If P does not conform to the Format, Syntax Rules, and Access Rules of a <preparable state-
ment>, or if P contains a <simple comment> then an exception condition is raised: syntax error
or access rule violation.
4) Let DTGN be the default transform group name and let TFL be the list of {user-defined type
name — transform group name} pairs used to identify the group of transform functions for every
user-defined type that is referenced in P. DTGN and TFL are not affected by the execution of a
<set transform group statement> after P is prepared.
5) Let DPV be a <value expression> that is either a <dynamic parameter specification> or a <dy-
namic parameter specification> immediately contained in any number of <left paren> <right
paren> pairs. Initially, the declared type of such a <value expression> is, by definition, unde-
fined. A data type is undefined if it is neither a data type defined in this standard nor a data
type defined by the implementation.
6) Let MP be the implementation-defined maximum value of <precision> for the NUMERIC data
type. Let ML be the implementation-defined maximum value of <length> for the CHARACTER
VARYING data type. For each <value expression> DP in P or PS that meets the criteria for
DPV let DT denote its declared type.
a) Case:
i) If DP is immediately followed by an <interval qualifier> IQ, then DT is INTERVAL IQ.
ii) If DP is the <numeric value expression> simply contained in an <element reference>,

then DT is NUMERIC (MP,0).
iii) If DP is the <string value expression> simply contained in a <char length expression>
or an <octet length expression>, then DT is CHARACTER VARYING(ML) with an
implementation-defined character set.
iv) If DP is the <string value expression> simply contained in a <bit length expression>,
then DT is BIT VARYING(L) where L is the implementation-defined maximum value of
length for BIT VARYING.

v) If DP is either the <numeric value expression dividend> X1 or the <numeric value

expression divisor> X2 simply contained in a <modulus expression>, then if DP is X1
(X2), then DT is the declared type of X2 (X1).
vi) If DP is either X1 or X2 in a <position expression> of the form ‘‘POSITION <left paren>

X1 IN X2 <right paren>’’, and if DP is X1 (X2), then
Case:
1) If the declared type of X2 (X1) is CHARACTER or CHARACTER VARYING with

character set CS, then DT is CHARACTER VARYING (ML) with character set CS.
2) Otherwise, DT is the declared type of X2 (X1).
vii) If DP is either X2 or X3 in a <string value function> of the form ‘‘SUBSTRING <left

paren> X1 FROM X2 FOR X3 <right paren>’’ or ‘‘SUBSTRING <left paren> X1 FROM
X2 <right paren>’’, then DT is NUMERIC (MP, 0).
viii) If DP is any of X1, X2, X3, or X4 in a <string value function> of the form ‘‘OVERLAY
<left paren> X1 PLACING X2 FROM X3 FOR X4 <right paren>’’ or ‘‘OVERLAY <left
paren> X1 PLACING X2 FROM X3 <right paren>’’, then
Case:
1) If DP is X1 (X2), then
Case:
A) If the declared type of X2 (X1) is CHARACTER or CHARACTER VARYING with

character set CS, DT is CHARACTER VARYING (ML) with character set CS.
B) Otherwise, DT is the declared type of X2 (X1).
2) Otherwise, DT is NUMERIC (MP, 0).
ix) If DP is either X1 or X2 in a <value expression> of the form ‘‘X1 <concatenation opera-

tor> X2’’ and DP is X1 (X2), then
Case:
1) If the declared type of X2 (X1) is CHARACTER or CHARACTER VARYING with

character set CS, then DT is CHARACTER VARYING (ML) with character set CS.
2) Otherwise, DT is the declared type of X2 (X1).
x) If DP is either X1 or X2 in a <value expression> of the form ‘‘X1 <asterisk> X2’’ or ‘‘X1

<solidus> X2’’ and DP is X1 (X2), then
Case:
1) If DP is X1, then DT is the declared type of X2.
2) Otherwise,
Case:
A) If the declared type of X1 is an interval type, then DT is NUMERIC (MP, 0).
B) Otherwise, DT is the declared type of X2 (X1).
Dynamic SQL 93
xi) If DP is either X1 or X2 in a <value expression> of the form ‘‘X1 <plus sign> X2’’ or ‘‘X1
<minus sign> X2’’, then
Case:
1) If DP is X1 in an expression of the form "X1 <minus sign> X2", then DT is the

declared type of X2.
2) Otherwise, if DP is X1 (X2), then

Case:
A) If the declared type of X2 (X1) is date, then DT is INTERVAL YEAR (PR) TO

MONTH, where PR is the implementation-defined maximum <interval leading
field precision>.
B) If the declared type of X2 (X1) is time or timestamp, then DT is INTERVAL

DAY (PR) TO SECOND(FR), where PR and FR are the implementation-defined
maximum <interval leading field precision> and maximum <interval fractional
seconds precision>, respectively.
C) Otherwise, DT is the declared type of X2 (X1).
xii) If DP is the <value expression primary> simply contained in a <boolean primary>, then
DT is BOOLEAN.
xiii) If DP is an <array element> simply contained in an <array element list> AEL or DP

represents the value of a subfield SF of the declared type of an <array element> simply
contained in an <array element list> AEL, then let ET be the result of applying the
Syntax Rules of Subclause 9.3, ‘‘Data types of results of aggregations’’, to the declared
types of the <array element>s simply contained in AEL.
Case:
1) If DP is an <array element> of AEL, then DT is ET.
2) Otherwise, DT is the declared type of the subfield of ET that corresponds to SF.
xiv) If DP is the <cast operand> simply contained in a <cast specification> CS or DP rep-

resents the value of a subfield SF of the declared type of the <cast operand> simply
contained in a <cast specification> CS, then let CT be the simply contained <cast target>
of CS.
Case:
1) Let RT be a data type determined as follows:

Case:
A) If CT immediately contains ARRAY, then RT is undefined.
B) If CT immediately contains <data type>, then RT is that data type.
C) If CT simply contains <domain name> D, then RT is the declared type of the

domain identified by D.
2) Case:
A) If DP is the <cast operand> of CS, DT is RT.

B) Otherwise, DT is the declared type of the subfield of RT that corresponds to SF.
xv) If DP is a <value expression> simply contained in a <case abbreviation> CA or DP

represents the value of a subfield, SF, of the declared type of such a <value expression>,
then let RT be the result of applying the Syntax Rules of Subclause 9.3, ‘‘Data types
of results of aggregations’’, to the declared types of the <value expression>s simply
contained in CA.
Case:
1) If DP is a <value expression> simply contained in CA, then DT is RT.
2) Otherwise, DT is the declared type of the subfield of RT that corresponds to SF.
xvi) If DP is a <result expression> simply contained in a <case specification> CE or DP

represents the value of a subfield SF of the declared type of such a <result expression>,
then let RT be the result of applying the Syntax Rules of Subclause 9.3, ‘‘Data types
of results of aggregations’’, to the declared types of the <result expression>s simply
contained in CE.
Case:
1) If DP is a <result expression> simply contained in CE, then DT is RT.
xvii) If DP is a <case operand> or <when operand> simply contained in a <simple case> CE or

DP represents the value of a subfield, SF, of the declared type of such a <case operand>
or <when operand>, then RT is the result of applying the Syntax Rules of Subclause 9.3,
to the declared types of the <case operand> and <when operand>s simply contained in
CE.
Case:
1) If DP is a <case operand> or <when operand> simply contained in CE, then DT is

RT.
xviii) If DP is a <row value expression> or <contextually typed row value expression> simply
contained in a <table value constructor> or <contextually typed table value constructor>
TVC, or if DP represents the value of a subfield SF of the declared type of such a <row
value expression> or <contextually typed row value expression>, then
Case:
1) Let RT be a data type determined as follows.

Case:
A) If TVC is simply contained in a <query expression> that is simply contained

in an <insert statement> IS or if TVC is immediately contained in the <insert
column and source> of an <insert statement> IS, then RT is a row type in which
the declared type of the i-th field is the declared type of the i-th column in the
explicit or implicit <insert column list> of IS and the degree of RT is equal to the
number of columns in the explicit or implicit <insert column list> of IS.
Dynamic SQL 95
B) Otherwise, RT is the result of applying the Syntax Rules of Subclause 9.3,

‘‘Data types of results of aggregations’’, to the declared types of the <row value
expression>s or <contextually typed row value expression>s simply contained in
TVC.
2) Case:
A) If DP is a <row value expression> or <contextually typed row value expression>

simply contained in TVC, then DT is RT.
B) Otherwise, DT is the declared type of the subfield of RT that corresponds to SF.
xix) If DP is a <row value expression> simply contained in a <comparison predicate>, <dis-

tinct predicate> or <between predicate> PR or if DP represents the value of a subfield,
SF, of the declared type of such a <row value expression>, then let RT be the result of
applying the Syntax Rules of Subclause 9.3, ‘‘Data types of results of aggregations’’, to
the declared types of the <row value expression>s simply contained in PR.
Case:
1) If DP is a <row value expression> simply contained in PR, then DT is RT.
xx) If DP is a <row value expression> simply contained in a <quantified comparison pred-

icate> or <match predicate> PR or DP represents the value of a subfield SF of the
declared type of such a <row value expression>, then let RT be the declared type of the
<table subquery> simply contained in PR.
Case:
xxi) If DP is a <row value expression> simply contained in an <in predicate> PR or if DP

represents the value of a subfield SF of the declared type of such a <row value expres-
sion>, then let RT be the result of applying the Syntax Rules of Subclause 9.3, ‘‘Data
types of results of aggregations’’, to the declared types of the <row value expression>s
simply contained in PR and the declared row type of the <table subquery> (if any)
simply contained in PR.
Case:
xxii) If DP is the first <row value constructor element> simply contained in either <row value
expression 1> RV1 or <row value expression 2> RV2 in an <overlaps predicate> PR,
then
Case:
1) If both RV1 and RV2 simply contain a <row value constructor> whose first <row
value constructor element> meets the criteria for DPV, then DT is TIMESTAMP
WITH TIME ZONE.

2) Otherwise, if DP is simply contained in RV1 (RV2), then DT is the declared type of

the first <row value constructor element> of RV2 (RV1).
xxiii) If DP is simply contained in a <like predicate> or a <similar predicate> PR, then let X1
represent the <character match value> or the <octet match value>, let X2 represent the
<character pattern>, the <octet pattern> or the <similar pattern>, and let X3 represent
the <escape character> or the <escape octet>.
Case:
1) If all X1, X2 and X3 meet the criteria for DPV, then DT is CHARACTER VARYING
(ML) with an implementation-defined character set.
2) Otherwise, let RT be the result of applying the Syntax Rules of Subclause 9.3, ‘‘Data
types of results of aggregations’’, to the declared types of X1, X2 and X3.
Case:
A) If RT is CHARACTER or CHARACTER VARYING with character set CS, then

DT is CHARACTER VARYING(ML) with character set CS.
B) Otherwise, DT is RT.
xxiv) If DP is the <value expression> simply contained in an <update source> of a <set

clause> SC or if DP represents the value of a subfield SF of the declared type of such a
<value expression>, then let RT be the declared type of the <update target> or <mutated
set clause> specified in SC.
Case:
1) If DP is the <value expression> simply contained in SC, then DT is RT.
xxv) If DP is the <value specification> immediately contained in a <catalog name character-

istic>, <schema name characteristic>, <character set name characteristic>, <SQL-path
characteristic>, <transform group characteristic>, <role specification> or <set session
authorization identifier statement>, then DT is CHARACTER VARYING (ML) with an
implementation-defined character set.
xxvi) If DP is the <interval value expression> immediately contained in a <set local time zone
statement>, then DT is INTERVAL HOUR TO MINUTE.
xxvii) If DP is an <SQL argument> of a <routine invocation> RI immediately contained in a

<call statement> or if DP is the value of a subfield SF of the declared type of a <value
expression> immediately contained in such an <SQL argument>, and if DP is the i-
th <SQL argument> of RI or is contained in the i-th <SQL argument> of RI, then let
RT denote the declared type of the i-th SQL parameter of the subject routine of RI
determined by applying the Syntax Rules of Subclause 8.1, ‘‘<routine invocation>’’, to RI.
Case:
1) If DP is the i-th <SQL argument> of RI, then DT is RT.
b) If DT is undefined, then an exception condition is raised: syntax error or access rule viola-
tion.
Dynamic SQL 97
7) Whether a <dynamic parameter specification> is an input argument, an output argument, or

both an input and an output argument is determined as follows.
Case:
a) If P is a <call statement>, then:
i) Let SR be the subject routine of the <routine invocation> RI immediately contained in

P. Let n be the number of <SQL argument>s in the <SQL argument list> immediately
contained in RI.
ii) Let Ay , 1 (one) y n, be the y-th <SQL argument> of the <SQL argument list>
immediately contained in RI.
iii) For each <dynamic parameter specification> D contained in some <SQL argument> Ak ,
1 (one) k n:
1) D is an input <dynamic parameter specification> if the <SQL parameter mode> of

the k-th SQL parameter of SR is INPUT or INOUT.
2) D is an output <dynamic parameter specification> if the <SQL parameter mode> of

the k-th SQL parameter of SR is OUTPUT or INOUT.
b) Otherwise:
i) If a <dynamic parameter specification> is contained in a <target specification>, then it

is an output <dynamic parameter specification>.
ii) If a <dynamic parameter specification> is contained in a <value specification>, then it is

an input <dynamic parameter specification>.
8) If P or PS is a <preparable dynamic delete statement: positioned> or a <preparable dynamic

update statement: positioned>, then let CN be the <cursor name> contained in P or PS, respec-
tively.
Case:
a) If P or PS contains a <scope option> that specifies GLOBAL, then

Case:
i) If there exists an extended dynamic cursor EDC with an <extended cursor name> having
a global scope and a <cursor name> that is equivalent to CN, then EDC is the cursor
referenced by P or PS.
ii) Otherwise, an exception condition is raised: invalid cursor name.
b) If P or PS contains a <scope option> that specifies LOCAL, or if no <scope option> is speci-

fied, then the potentially referenced cursors of P or PS include every declared dynamic cursor
whose <cursor name> is equivalent to CN and whose scope is the containing module and
every extended dynamic cursor having an <extended cursor name> that has a scope of the
containing module and whose <cursor name> is equivalent to CN.
Case:
i) If the number of potentially referenced cursors is greater than 1 (one), then an exception
condition is raised: ambiguous cursor name.

ii) If the number of potentially referenced cursors is less than 1 (one), then an exception
condition is raised: invalid cursor name.
iii) Otherwise, CN refers to the single potentially referenced cursor of P.
9) If <extended statement name> is specified for the <SQL statement name>, then let S be <simple
target specification> and let V be the character string that is the result of
condition is raised: invalid SQL statement identifier.
10) If <statement name> is specified for the <SQL statement name>, P is not a <cursor specifica-
tion>, and <statement name> is associated with a cursor C through a <dynamic declare cursor>,
then an exception condition is raised: dynamic SQL error — prepared statement not a cursor
specification.
11) If the value of the <SQL statement name> identifies an existing prepared statement, then an
implicit
DEALLOCATE PREPARE SSN
is executed, where SSN is the value of the <SQL statement name>.
12) P is prepared for execution.
13) Case:
a) If <extended statement name> is specified for the <SQL statement name>, then the value
of the <extended statement name> is associated with the prepared statement. This value
and explicit or implied <scope option> shall be specified for each <execute statement> or
<allocate cursor statement> that is to be associated with this prepared statement.
b) If <statement name> is specified for the <SQL statement name>, then:
i) If <statement name> is not associated with a cursor and either P is not a <cursor
specification> or P is a <cursor specification> that conforms to the Format and Syntax
Rules of a <dynamic single row select statement>, then an equivalent <statement
name> shall be specified for each <execute statement> that is to be associated with this
prepared statement.
ii) If P is a <cursor specification> and <statement name> is associated with a cursor C

through a <dynamic declare cursor>, then an association is made between C and P. The
association is preserved until the prepared statement is destroyed.
14) The validity of an <extended statement name> value or a <statement name> that does not
identify a held cursor in an SQL-transaction different from the one in which the statement was
prepared is implementation-dependent.
Conformance Rules
<prepare statement>.
Dynamic SQL 99
15.7 <deallocate prepared statement>
15.7 <deallocate prepared statement>
Function
Deallocate SQL-statements that have been prepared with a <prepare statement>.
Format
<deallocate prepared statement> ::=

DEALLOCATE PREPARE <SQL statement name>
Syntax Rules
1) If <SQL statement name> is a <statement name>, then the containing <SQL-client module
definition> shall contain a <prepare statement> whose <statement name> is equivalent to the
<statement name> of the <deallocate prepared statement>.
Access Rules
None.
General Rules
1) If the <SQL statement name> does not identify a statement prepared in the scope of the <SQL
statement name>, then an exception condition is raised: invalid SQL statement name.
2) If the value of <SQL statement name> identifies an existing prepared statement that is the
<cursor specification> of an open cursor, then an exception condition is raised: invalid cursor
state.
3) The prepared statement identified by the <SQL statement name> is destroyed. Any cursor
that was allocated with an <allocate cursor statement> that is associated with the prepared
statement identified by the <SQL statement name> is destroyed. If the value of the <SQL
statement name> identifies an existing prepared statement that is a <cursor specification>, then
any prepared statements that reference that cursor are destroyed.
Conformance Rules
1) Without Feature B032, ‘‘Extended dynamic SQL’’, conforming SQL language shall contain no
<deallocate prepared statement>.

15.8 <describe statement>
Function
Obtain information about the <select list> columns or <dynamic parameter specification>s contained
in a prepared statement or about the columns of the result set associated with a cursor.
Format
<describe statement> ::=

<describe input statement>
| <describe output statement>
<describe input statement> ::=

DESCRIBE INPUT <SQL statement name> <using descriptor>
[ <nesting option> ]
<describe output statement> ::=

DESCRIBE [ OUTPUT ] <described object> <using descriptor>
[ <nesting option> ]
<nesting option> ::=

WITH NESTING
| WITHOUT NESTING
<using descriptor> ::=

USING [ SQL ] DESCRIPTOR <descriptor name>
<described object> ::=

<SQL statement name>
| CURSOR <extended cursor name> STRUCTURE
Syntax Rules
<statement name> of the <describe statement>.
2) If <nesting option> is not specified, then WITHOUT NESTING is implicit.
Access Rules
None.
General Rules
1) If <describe input statement> is executed and the value of the <SQL statement name> does not
identify a statement prepared in the scope of the <SQL statement name>, then an exception
condition is invalid SQL statement name.
2) If <describe output statement> is executed, <SQL statement name> is specified, and the value
of the <SQL statement name> does not identify a statement prepared in the scope of the <SQL
statement name>, then an exception condition is invalid SQL statement name.
Dynamic SQL 101

3) If <describe output statement> is executed, <extended cursor name> is specified, and the value
of the <extended cursor name> does not identify a known allocated cursor, then an exception
condition is invalid cursor name.
4) An SQL system descriptor area shall have been allocated and not yet deallocated whose name
is the value of the <descriptor name>’s <simple value specification> and whose scope is that
specified by the <scope option>. Otherwise, an exception condition is raised: invalid SQL
descriptor name.
5) Let DA be the descriptor area identified by <descriptor name>. Let N be the <occurrences>
specified when DA was allocated.
6) Case:
a) If the statement being executed is a <describe input statement>, then a descriptor for the
input <dynamic parameter specification>s for the prepared statement is stored in DA. Let
D be the number of input <dynamic parameter specification>s in the prepared statement. If
WITH NESTING is specified, then let NSi , 1 (one) i D, be the number of subordinate
descriptors of the descriptor for the i-th input dynamic parameter; otherwise, let NSi be 0
(zero).
b) If the statement being executed is a <describe output statement> and the prepared state-
ment that is being described is a <dynamic select statement> or a <dynamic single row
select statement>, then a descriptor for the <select list> columns for the prepared statement
is stored in DA. Let T be the table defined by the prepared statement and let D be the de-
gree of T. If WITH NESTING is specified, then let NSi , 1 (one) i D, be the number of
subordinate descriptors of the descriptor for the i-th column of T; otherwise, let NSi be 0
(zero).
c) Otherwise, a descriptor for the output <dynamic parameter specification>s for the prepared
statement is stored in DA. Let D be the number of output <dynamic parameter specifica-
tion>s in the prepared statement. If WITH NESTING is specified, then let NSi , 1 (one) i
D, be the number of subordinate descriptors of the descriptor for the i-th output dynamic
parameter; otherwise, let NSi be 0 (zero).
7) DA is set as follows:
a) Let TD be the value of D+NS1 +NS2 + . . . +NSD . COUNT is set to TD.
b) TOP_LEVEL_COUNT is set to D.
c) DYNAMIC_FUNCTION and DYNAMIC_FUNCTION_CODE are set to the identifier and

code, respectively, for the prepared statement as shown in Table 9, ‘‘SQL-statement codes’’.
d) If the statement being executed is a <describe output statement> and the prepared state-
ment that is being described is a <dynamic select statement> or a <dynamic single row
select statement>:
Case:
i) If some subset of the columns of T is the primary key of T, then KEY_TYPE is set to 1
(one).

ii) If some subset of the columns of T is the preferred candidate key of T, then KEY_TYPE
is set to 2.
NOTE 12 – Primary keys and preferred candidate keys are defined in Subclause 4.18, "Functional
dependencies", ISO/IEC 9075-2.
e) If TD is greater than N, then a completion condition is raised: warning — insufficient item

descriptor areas.
f) If TD is 0 (zero) or TD is greater than N, then no item descriptor areas are set. Otherwise:
i) The first TD item descriptor areas are set with values from the descriptors and, option-
ally, subordinate descriptors for
Case:
1) If the statement being executed is a <describe input statement>, then the input
<dynamic parameter specification>s.
2) If the statement being executed is a <describe output statement> and the statement
being described is a <dynamic select statement> or a <dynamic single row select
statement>, then the columns of T.
3) Otherwise, the output <dynamic parameter specification>s.
ii) The descriptor for the first such column or <dynamic parameter specification> is as-
signed to the first item descriptor area.
iii) If the descriptor for the j-th column or <dynamic parameter specification> is assigned to
the k-th item descriptor area, then:
1) The descriptor for the (j+1)-th column or <dynamic parameter specification> is

assigned to the (k+NSj+1 )-th item descriptor area.
2) If WITH NESTING is specified, then the implicitly ordered subordinate descriptors

for the j-th column or <dynamic parameter specification> are assigned to contiguous
item descriptor areas starting at the (k+1)-th item descriptor area.
8) An SQL item descriptor area, if set, consists of values for LEVEL, TYPE, NULLABLE, NAME,
UNNAMED, PARAMETER_ORDINAL_POSITION, PARAMETER_SPECIFIC_CATALOG,
PARAMETER_SPECIFIC_SCHEMA, PARAMETER_SPECIFIC_NAME, and other fields de-
pending on the value of TYPE as described below. The DATA and INDICATOR fields are not
relevant. Those fields and fields that are not applicable for a particular value of TYPE are set
to implementation-dependent values.
a) If the SQL item descriptor area is set to a descriptor that is immediately subordinate to
another whose LEVEL value is K, then LEVEL is set to K+1; otherwise, LEVEL is set to 0
(zero).
b) TYPE is set to a code, as shown in Table 4, ‘‘Codes used for SQL data types in Dynamic
SQL’’, indicating the declared type of the column, <dynamic parameter specification>, or
subordinate descriptor.
Dynamic SQL 103

c) Case:
i) If the value of LEVEL is 0 (zero) and the item descriptor area describes a column, then:
1) If the column is possibly nullable, then NULLABLE is set to 1 (one); otherwise,

NULLABLE is set to 0 (zero).
2) If the column name is implementation-dependent, then NAME is set to the

implementation-dependent name of the column and UNNAMED is set to 1 (one); oth-
erwise, NAME is set to the <derived column> name for the column and UNNAMED
is set to 0 (zero).
3) If the column is a member of the primary key of T and KEY_TYPE was set to 1 (one)
or if the column is a member of the preferred candidate key of T and KEY_TYPE
was set to 2, then KEY_MEMBER is set to 1 (one); otherwise, KEY_MEMBER is set
to 0 (zero).
ii) If the value of LEVEL is 0 (zero) and the item descriptor area describes a <dynamic
parameter specification>, then:
1) NULLABLE is set to 1 (one).

NOTE 13 – This indicates that the <dynamic parameter specification> can have the null
value.
2) UNNAMED is set to 1 (one) and NAME is set to an implementation-dependent

value.
3) KEY_MEMBER is set to 0 (zero).
iii) Otherwise:
1) NULLABLE is set to 1 (one).
2) Case:
A) If the item descriptor area describes a field of a row, then

Case:
I) If the name of the field is implementation-dependent, then NAME is set to

the implementation-dependent name of the field and UNNAMED is set to 1
(one).
II) Otherwise, NAME is set to the name of the field and UNNAMED is set to 0
(zero).
B) Otherwise, UNNAMED is set to 1 (one) and NAME is set to an implementation-

defined value.
3) KEY_MEMBER is set to 0 (zero).
d) Case:
i) If TYPE indicates a <character string type>, then LENGTH is set to the length or
maximum length in characters of the character string; OCTET_LENGTH is set to
the maximum possible length in octets of the character string; CHARACTER_SET_

CATALOG, CHARACTER_SET_SCHEMA and CHARACTER_SET_NAME are set to

the <character set name> of the character string’s character set; and COLLATION_
CATALOG, COLLATION_SCHEMA and COLLATION_NAME are set to the <collation
name> of the character string’s collation. If the subject <language clause> specifies
C, then the lengths specified in LENGTH and OCTET_LENGTH do not include the
implementation-defined null character that terminates a C character string.
ii) If TYPE indicates a <bit string type>, then LENGTH is set to the length or maximum
length in bits of the bit string and OCTET_LENGTH is set to the maximum possible
length in octets of the bit string.
iii) If TYPE indicates a <binary large object string type>, then LENGTH is set to the length
or maximum length in octets of the binary string and OCTET_LENGTH is set to the
maximum possible length in octets of the binary string.
iv) If TYPE indicates an <exact numeric type>, then PRECISION and SCALE are set to the
precision and scale of the exact numeric.
v) If TYPE indicates an <approximate numeric type>, then PRECISION is set to the

precision of the approximate numeric.
vi) If TYPE indicates a <datetime type>, then LENGTH is set to the length in positions
of the datetime type, DATETIME_INTERVAL_CODE is set to a code as specified in
Table 5, ‘‘Codes associated with datetime data types in Dynamic SQL’’, to indicate the
specific datetime data type and PRECISION is set to the <time precision> or <times-
tamp precision>, if either is applicable.
vii) If TYPE indicates an <interval type>, then LENGTH is set to the length in positions
of the interval type, DATETIME_INTERVAL_CODE is set to a code as specified in
Table 6, ‘‘Codes used for <interval qualifier>s in Dynamic SQL’’, to indicate the <interval
qualifier> of the interval data type, DATETIME_INTERVAL_PRECISION is set to the
<interval leading field precision> and PRECISION is set to the <interval fractional
seconds precision>, if applicable.
viii) If TYPE indicates a user-defined type, then USER_DEFINED_TYPE_CATALOG, USER_

DEFINED_TYPE_SCHEMA, and USER_DEFINED_TYPE_NAME are set to the <user-
defined type name> of the user-defined type’s name.
ix) If TYPE indicates a <reference type>, then USER_DEFINED_TYPE_CATALOG, USER_

DEFINED_TYPE_SCHEMA, USER_DEFINED_TYPE_NAME, SCOPE_CATALOG,
SCOPE_SCHEMA, and SCOPE_NAME are set to the <user-defined type name> of
the referenced type and qualified name of the referenceable base table; LENGTH and
OCTET_LENGTH are set to the implementation-defined length in octets of a <reference
type>.
x) If TYPE indicates ROW, then DEGREE is set to the degree of the row type.
xi) If TYPE indicates ARRAY, then CARDINALITY is set to the cardinality of the array
type.
e) If LEVEL is 0 (zero) and the prepared statement is a <call statement>, then:
i) Let SR be the subject routine for the <routine invocation> of the <call statement>.
ii) Let Dx be the x-th <dynamic parameter specification> simply contained in an SQL
argument Ay of the <call statement>.
Dynamic SQL 105

iii) Let Py be the y-th SQL parameter of SR.

NOTE 14 – A P whose <SQL parameter mode> is IN can be a <value expression> that contains
zero, one, or more <dynamic parameter specification>s. Thus:
— Every Dx maps to one and only one Py .
— Several Dx instances can map to the same Py .
— There can be Py instances that have no Dx instances that map to them.
iv) The PARAMETER_MODE value in the descriptor for each Dx is set to the value from
Table 7, ‘‘Codes used for input/output SQL parameter modes in Dynamic SQL’’, that
indicates the <SQL parameter mode> of Py .
v) The PARAMETER_ORDINAL_POSITION value in the descriptor for each Dx is set to

the ordinal position of Py .
vi) The PARAMETER_SPECIFIC_CATALOG, PARAMETER_SPECIFIC_SCHEMA, and

PARAMETER_SPECIFIC_NAME values in the descriptor for each Dx are set to the
values that identify the catalog, schema, and specific name of SR.
Conformance Rules
1) Without Feature B032, ‘‘Extended dynamic SQL’’, conforming SQL language shall not contain
any <describe input statement>.
<describe output statement>.

15.9 <input using clause>
Function
Supply input values for an <SQL dynamic statement>.
Format
<input using clause> ::=

<using arguments>
| <using input descriptor>
<using arguments> ::=

USING <using argument> [ { <comma> <using argument> }... ]
<using argument> ::= <general value specification>
<using input descriptor> ::= <using descriptor>
Syntax Rules
1) The <general value specification> immediately contained in <using argument> shall be either a
<host parameter specification> or an <embedded variable specification>.
Access Rules
None.
General Rules
1) If <using input descriptor> is specified, then an SQL system descriptor area shall have been
allocated and not yet deallocated whose name is the value of the <descriptor name>’s <simple
value specification> and whose scope is that specified by the <scope option>. Otherwise, an
exception condition is raised: invalid SQL descriptor name.
2) When an <input using clause> is used in a <dynamic open statement> or as the <parameter us-
ing clause> in an <execute statement>, the <input using clause> describes the input <dynamic
parameter specification> values for the <dynamic open statement> or the <execute statement>,
respectively. Let PS be the prepared <dynamic select statement> referenced by the <dynamic
open statement> or the prepared statement referenced by the <execute statement>, respectively.
3) Let D be the number of input <dynamic parameter specification>s in PS.
4) If <using arguments> is specified and the number of <using argument>s is not D, then an
exception condition is raised: dynamic SQL error — using clause does not match dynamic
parameter specifications.
5) If <using input descriptor> is specified, then:
a) Let N be the value of COUNT.
Dynamic SQL 107

b) If N is greater than the value of <occurrences> specified when the SQL descriptor area iden-
tified by <descriptor name> was allocated or is less than zero, then an exception condition is
raised: dynamic SQL error — invalid descriptor count.
c) If the first N item descriptor areas are not valid as specified in Subclause 15.1, ‘‘Description
of SQL descriptor areas’’, then an exception condition is raised: dynamic SQL error — using
clause does not match dynamic parameter specifications.
d) In the first N item descriptor areas:
i) If the number of item descriptor areas in which the value of LEVEL is 0 (zero) is not D,
then an exception condition is raised: dynamic SQL error — using clause does not match
dynamic parameter specifications.
ii) If the value of INDICATOR is not negative, TYPE does not indicate ROW, and the item
descriptor area is not subordinate to an item descriptor area whose INDICATOR value
is negative or whose TYPE field indicates ARRAY or ARRAY LOCATOR, and if the value
of DATA is not a valid value of the data type represented by the item descriptor area,
then an exception condition is raised: dynamic SQL error — using clause does not match
dynamic parameter specifications.
6) For 1 (one) i D:
a) Let TDT be the effective declared type of the i-th input <dynamic parameter specification>,
defined to be the type represented by the item descriptor area and its subordinate descriptor
areas that would be set by a <describe input statement> to reflect the description of the i-th
input <dynamic parameter specification> of PS.
NOTE 15 – See the General Rules of Subclause 15.8, ‘‘<describe statement>’’.
NOTE 16 – ‘‘Represented by’’, as applied to the relationship between a data type and an item
descriptor area, is defined in the Syntax Rules of Subclause 15.1, ‘‘Description of SQL descriptor
areas’’.
b) Case:
i) If <using input descriptor> is specified, then:
1) Let IDA be the i-th item descriptor area whose LEVEL value is 0 (zero).
2) Let SDT be the effective declared type represented by IDA.

NOTE 17 – ‘‘Represented by’’, as applied to the relationship between a data type and an
item descriptor area, is defined in the Syntax Rules of Subclause 15.1, ‘‘Description of SQL
descriptor areas’’.
3) Let SV be the associated value of IDA, which is defined to be

Case:
A) If the value of INDICATOR is negative, then SV is the null value.
B) Otherwise,
Case:
I) If TYPE indicates ROW, then SV is a row whose type is SDT and whose field
values are the associated values of the immediately subordinate descriptor
areas of IDA.

II) Otherwise, SV is the value of DATA with data type SDT.
ii) If <using arguments> is specified, then let SDT and SV be the declared type and value,
respectively, of the i-th <using argument>.
c) Case:
i) If SDT is a locator type, then:
1) If SV is not the null value, then let the value of the i-th dynamic parameter be the
value of SV.
2) Otherwise, let the value of the i-th dynamic parameter be the null value.
ii) If SDT and TDT are predefined data types, then

Case:
1) If the <cast specification>

CAST ( IV AS TDT )
does not conform to the Syntax Rules of Subclause 6.22, "<cast specification>", in
ISO/IEC 9075-2, and there is an implementation-defined conversion from type STD
to type TDT, then that implementation-defined conversion is effectively performed,
converting IV to type TDT, and the result is the value TV of the i-th input dynamic
parameter.
2) Otherwise:
A) If the <cast specification>

CAST ( IV AS TDT )
does not conform to the Syntax Rules of Subclause 6.22, "<cast specification>",
in ISO/IEC 9075-2, then an exception condition is raised: dynamic SQL error —
restricted data type attribute violation.
B) If the <cast specification>

CAST ( IV AS TDT )
does not conform to the General Rules of Subclause 6.22, "<cast specification>",
in ISO/IEC 9075-2, then an exception condition is raised in accordance with the
General Rules of Subclause 6.22, "<cast specification>", in ISO/IEC 9075-2.
C) The <cast specification>

CAST ( IV AS TDT )
is effectively performed and is the value of the i-th input dynamic parameter.
iii) If SDT is a predefined data type and TDT is a user-defined type, then:
1) Let DT be the data type identified by TDT.
2) If the current SQL-session has a group name corresponding to the user-defined name
of DT, then let GN be that group name; Otherwise, let GN be the default transform
group name associated with the current SQL-session.
Dynamic SQL 109

3) The Syntax Rules of Subclause 10.17, "Determination of a to-sql function", in

ISO/IEC 9075-2, are applied with DT and GN as TYPE and GROUP, respectively.
Case:
A) If there is an applicable to-sql function, then let TSF be that to-sql function.
If TSF is an SQL-invoked method, then let TSFPT be the declared type of the
second SQL parameter of TSF; otherwise, let TSFPT be the declared type of the
first SQL parameter of TSF.
Case:
I) If TSFPT is compatible with SDT, then

Case:
1) If TSF is an SQL-invoked method, then TSF is effectively invoked with

the value returned by the function invocation:
DT( )
as the first parameter and SV as the second parameter. The <return
value> is the value of the i-th input dynamic parameter.
2) Otherwise, TSF is effectively invoked with SV as the first parameter.

The <return value> is the value of the i-th input dynamic parameter.
II) Otherwise, an exception condition is raised: dynamic SQL error — restricted

data type attribute violation.
B) Otherwise, an exception condition is raised: dynamic SQL error — data type

transform function violation.
Conformance Rules
<using input clause>.

15.10 <output using clause>
Function
Supply output variables for an <SQL dynamic statement>.
Format
<output using clause> ::=

<into arguments>
| <into descriptor>
<into arguments> ::=

INTO <into argument> [ { <comma> <into argument> }... ]
<into argument> ::= <target specification>
<into descriptor> ::=

INTO [ SQL ] DESCRIPTOR <descriptor name>
Syntax Rules
None.
Access Rules
None.
General Rules
1) If <into descriptor> is specified, then an SQL system descriptor area shall have been allocated
and not yet deallocated whose name is the value of the <descriptor name>’s <simple value
specification> and whose scope is that specified by the <scope option>. Otherwise, an exception
2) When an <output using clause> is used in a <dynamic fetch statement> or as the <result using
clause> of an <execute statement>, let PS be the prepared <dynamic select statement> refer-
enced by the <dynamic fetch statement> or the prepared <dynamic single row select statement>
referenced by the <execute statement>, respectively.
3) Case:
a) If PS is a <prepared dynamic select statement> or a <dynamic single row select statement>,

then the <output using clause> describes the <target specification>s for the <dynamic fetch
statement> or the <execute statement>. Let D be the degree of the table specified by PS.
b) Otherwise, the <output using clause> describes the <target specification>s for the output
<dynamic parameter specification>s contained in PS. Let D be the number of such output
<dynamic parameter specification>s.
4) If <into arguments> is specified and the number of <into argument>s is not D, then an exception
condition is raised: dynamic SQL error — using clause does not match target specifications.
Dynamic SQL 111

5) If <into descriptor> is specified, then:
a) Let N be the value of COUNT.
b) If N is greater than the value of <occurrences> specified when the SQL descriptor area
identified by <descriptor name> was allocated or less than zero, then an exception condition
is raised: dynamic SQL error — invalid descriptor count.
c) If the first N item descriptor areas are not valid as specified in Subclause 15.1, ‘‘Description
of SQL descriptor areas’’, then an exception condition is raised: dynamic SQL error — using
clause does not match target specifications.
d) In the first N item descriptor areas, if the number of item descriptor areas in which the
value of LEVEL is 0 (zero) is not D, then an exception condition is raised: dynamic SQL
error — using clause does not match target specifications.
6) For 1 (one) i D:
a) Let SDT be the effective declared type of the i-th <select list> column or output <dynamic
parameter specification>, defined to be the type represented by the item descriptor area and
its subordinate descriptor areas that would be set by
Case:
i) If PS is a <prepared dynamic select statement> or a <dynamic single row select state-

ment>, then a <describe output statement> to reflect the description of the i-th <select
list> column; let SV be the value of that <select list> column, with data type SDT.
ii) Otherwise, a <describe output statement> to reflect the description of the i-th output
<dynamic parameter specification>; let SV be the value of that <dynamic parameter
specification>, with data type SDT.
areas’’.
b) Case:
i) If <into descriptor> is specified, then let TDT be the declared type of the i-th <target
specification> as represented by the i-th item descriptor area IDA whose LEVEL value
is 0 (zero).
areas’’.
ii) If <into arguments> is specified, then let TDT be the data type of the i-th <into argu-
ment>.
c) If the <output using clause> is used in a <dynamic fetch statement>, then let LTDT be the
data type on the most recently executed <dynamic fetch statement>, if any, for the cursor
CR. It is implementation-defined whether or not an exception condition is raised: dynamic
SQL error — restricted data type attribute violation if any of the following are true:
i) LTDT and TDT both identify a binary large object type and only one of LTDT and TDT
is a binary large object locator.

ii) LTDT and TDT both identify a character large object type and only one of LTDT and
TDT is a character large object locator.
iii) LTDT and TDT both identify an array type and only one of LTDT and TDT is an array
locator.
iv) LTDT and TDT both identify a user-defined type and only one of LTDT and TDT is a
user-defined type locator.
d) Case:
i) If TDT is a locator type, then:
1) If SV is not the null value, then a locator L that uniquely identifies SV is generated
and is the value TV of the i-th <target specification>.
2) Otherwise, the value TV of the i-th <target specification> is the null value.
ii) If STD and TDT are predefined data types, then

Case:
1) If the <cast specification>

CAST ( SV AS TDT )
in ISO/IEC 9075-2, and there is an implementation-defined conversion of type
STD to type TDT, then that implementation-defined conversion is effectively per-
formed, converting SV to type TDT, and the result is the value TV of the i-th <target
specification>.
2) Otherwise:
A) If the <cast specification>

CAST ( SV AS TDT )
in ISO/IEC 9075-2, then an exception condition is raised: dynamic SQL error —
restricted data type attribute violation.
B) If the <cast specification>

CAST ( SV AS TDT )
does not conform to the General Rules of Subclause 6.22, "<cast specification>",
in ISO/IEC 9075-2, then an exception condition is raised in accordance with the
General Rules of Subclause 6.22, "<cast specification>", in ISO/IEC 9075-2.
C) The <cast specification>

CAST ( SV AS TDT )
is effectively performed, and is the value TV of the i-th <target specification>.
iii) If SDT is a user-defined type and TDT is a predefined data type, then:
1) Let DT be the data type identified by SDT.
Dynamic SQL 113

2) If the current SQL-session has a group name corresponding to the user-defined type
name of DT, then let GN be that group name; otherwise, let GN be the default
transform group name associated with the current SQL-session.
3) Apply the Syntax Rules of Subclause 10.15, "Determination of a from-sql function",

in ISO/IEC 9075-2, with DT and GN as TYPE and GROUP, respectively.
Case:
A) If there is an applicable from-sql function, then let FSF be that from-sql function
and let FSFRT be the <returns data type> of FSF.
Case:
I) If FSFRT is compatible with TDT, then the from-sql function FSF is effec-
tively invoked with SV as its input parameter and the <return value> is the
value TV of the i-th <target specification>.
II) Otherwise, an exception condition is raised: dynamic SQL error — restricted

data type attribute violation.
B) Otherwise, an exception condition is raised: dynamic SQL error — data type

transform function violation.
e) Case:
i) If <into descriptor> is specified, then IDA is set to reflect the value of TV as follows:
Case:
1) If TYPE indicates ROW, then

Case:
A) If TV is the null value, then the value of INDICATOR in IDA and in all subordi-
nate descriptor areas of IDA that are not subordinate to an item descriptor area
whose TYPE indicates ARRAY or ARRAY LOCATOR is set to 01.
B) Otherwise, the i-th subordinate descriptor area of IDA is set to reflect the value
of the i-th field of TV by applying this subrule (beginning with the outermost
’Case’) to the i-th subordinate descriptor area of IDA as IDA, the value of the
i-th field of TV as TV, the value of the i-th field of SV as SV, and the data type
of the i-th field of SV as SDT.
2) Otherwise,
Case:
A) If TV is the null value, then the value of INDICATOR is set to 01.

B) If TV is not the null value, then:
I) The value of INDICATOR is set to 0 (zero).
II) Case:
1) If TYPE indicates a locator type, then a locator L that uniquely identifies

TV is generated and the value of DATA is set to an implementation-
dependent four-octet value that represents L.

2) Otherwise, the value of DATA is set to TV.
III) Case:
1) If TYPE indicates CHARACTER VARYING, BIT VARYING, or BINARY

LARGE OBJECT, then RETURNED_LENGTH is set to the length in
characters, bits, or octets, respectively, of TV, and RETURNED_OCTET_
LENGTH is set to the length in octets of TV.
2) If SDT is CHARACTER VARYING, BIT VARYING, or BINARY LARGE

OBJECT, then RETURNED_LENGTH is set to the length in characters,
bits, or octets, respectively, of SV, and RETURNED_OCTET_LENGTH is
set to the length in octets of SV.
3) If TYPE indicates ARRAY or ARRAY LOCATOR, then RETURNED_

CARDINALITY is set to the cardinality of TV.
ii) If <into arguments> is specified, then the Rules in Subclause 9.1, ‘‘Retrieval assign-
ment’’, are applied to TV and the i-th <into argument> as VALUE and TARGET,
respectively.
NOTE 20 – All other values of the SQL descriptor area are unchanged.
Conformance Rules
<output using clause>.
Dynamic SQL 115

15.11 <execute statement>
Function
Associate input SQL parameters and output targets with a prepared statement and execute the
statement.
Format
<execute statement> ::=

EXECUTE <SQL statement name>
[ <result using clause> ]
[ <parameter using clause> ]
<result using clause> ::= <output using clause>
<parameter using clause> ::= <input using clause>
Syntax Rules
<statement name> of the <execute statement>.
Access Rules
None.
General Rules
1) When the <execute statement> is executed, if the <SQL statement name> does not identify a
statement P previously prepared in the scope of the <SQL statement name>, then an exception
condition is raised: invalid SQL statement name.
2) Let PS be the statement previously prepared using <SQL statement name>.
3) If PS is a <dynamic select statement> that does not conform to the Format and Syntax Rules of
a <dynamic single row select statement>, then an exception condition is raised: dynamic SQL
error — cursor specification cannot be executed.
4) If PS contains the <table name> of a created or declared local temporary table and if the <exe-
cute statement> is not in the same <SQL-client module definition> as the <prepare statement>
that prepared the prepared statement, then an exception condition is raised: syntax error or
access rule violation.
5) If PS contains input <dynamic parameter specification>s and a <parameter using clause> is not
specified, then an exception condition is raised: dynamic SQL error — using clause required for
dynamic parameters.
6) If PS is a <dynamic single row select statement> or it contains output <dynamic parameter

specification>s and a <result using clause> is not specified, then an exception condition is
raised: dynamic SQL error — using clause required for result fields.

7) If a <parameter using clause> is specified, then the General Rules specified in Subclause 15.9,
‘‘<input using clause>’’, for a <parameter using clause> in an <execute statement> are applied.
8) PS is executed by applying the General Rules of Subclause 11.3, ‘‘<SQL procedure statement>’’,
to PS as if it were immediately contained in an <externally-invoked procedure>. All General
Rules are applied except those associated with input and output parameters.
9) If PA is a <preparable dynamic delete statement: positioned>, then when it is executed all

General Rules in Subclause 15.21, ‘‘<preparable dynamic delete statement: positioned>’’, apply
to the <preparable statement>.
10) If PS is a <preparable dynamic update statement: positioned>, then when it is executed, all
General Rules in Subclause 15.22, ‘‘<preparable dynamic update statement: positioned>’’, apply
to the <preparable statement>.
11) If a <result using clause> is specified, then the General Rules specified in Subclause 15.10,
‘‘<output using clause>’’, for a <result using clause> in an <execute statement> are applied.
Conformance Rules
<result using clause>.
<execute statement>.
Dynamic SQL 117

15.12 <execute immediate statement>
15.12 <execute immediate statement>
Function
Dynamically prepare and execute a preparable statement.
Format
<execute immediate statement> ::=

EXECUTE IMMEDIATE <SQL statement variable>
Syntax Rules
1) The declared type of <SQL statement variable> shall be character string.
Access Rules
None.
General Rules
1) Let P be the contents of the <SQL statement variable>.
2) If one or more of the following are true, then an exception condition is raised: syntax error or
access rule violation.
a) P is a <dynamic select statement> or a <dynamic single row select statement>.
b) P contains a <dynamic parameter specification>.
3) Let SV be <SQL statement variable>. <execute immediate statement> is equivalent to the

following:
PREPARE IMMEDIATE_STMT FROM SV ;

EXECUTE IMMEDIATE_STMT ;
DEALLOCATE PREPARE IMMEDIATE_STMT ;
where IMMEDIATE_STMT is an implementation-defined <statement name> that is not equiva-
lent to any other <statement name> in the containing <SQL-client module definition>.
NOTE 21 – Exception condition or completion condition information resulting from the PREPARE or
EXECUTE is reflected in the diagnostics area.
Conformance Rules
<execute immediate statement>.

15.13 <dynamic declare cursor>
Function
Declare a cursor to be associated with a <statement name>, which may in turn be associated with a
<cursor specification>.
Format
<dynamic declare cursor> ::=

DECLARE <cursor name> [ <cursor sensitivity> ]
[ <cursor scrollability> ] CURSOR
[ <cursor holdability> ]
[ <cursor returnability> ]
FOR <statement name>
Syntax Rules
1) The <cursor name> shall not be identical to the <cursor name> specified in any other <declare
cursor> or <dynamic declare cursor> in the same <SQL-client module definition>.
2) The containing <SQL-client module definition> shall contain a <prepare statement> whose
<statement name> is equivalent to the <statement name> of the <dynamic declare cursor>.
3) If <cursor scrollability is not specified, then NO SCROLL is implicit.
4) If <cursor holdability is not specified, then WITHOUT HOLD is implicit.
5) If <cursor returnability is not specified, then WITHOUT RETURN is implicit.
Access Rules
None.
General Rules
1) All General Rules of Subclause 14.1, "<declare cursor>", in ISO/IEC 9075-2, apply to <dynamic
declare cursor>, replacing ‘‘<cursor specification>’’ with ‘‘prepared statement’’.
Conformance Rules
2) Without Feature B031, ‘‘Basic dynamic SQL’’, and Feature T231, ‘‘SENSITIVE cursors’’, a
<dynamic declare cursor> shall not specify SENSITIVE.
3) Without Feature B031, ‘‘Basic dynamic SQL’’, and Feature F791, ‘‘Insensitive cursors’’, a <dy-
namic declare cursor> shall not specify INSENSITIVE.
4) Without Feature B031, ‘‘Basic dynamic SQL’’, and either Feature F791, ‘‘Insensitive cur-
sors’’, or Feature T231, ‘‘SENSITIVE cursors’’, a <dynamic declare cursor> shall not specify
ASENSITIVE.
Dynamic SQL 119

5) Without Feature B031, ‘‘Basic dynamic SQL’’, and Feature T471, ‘‘Result sets return value’’, a
<dynamic declare cursor> shall not specify <cursor returnability>.
6) Without Feature B031, ‘‘Basic dynamic SQL’’, and Feature F341, ‘‘Scrolled cursors’’, and Feature
F831, ‘‘Full cursor update’’, if an <updatability clause> of FOR UPDATE with or without a
<column name list> is specified, then <cursor scrollability> shall not be specified.
7) Without Feature B031, ‘‘Basic dynamic SQL’’, and Feature F831, ‘‘Full cursor update’’, if an
<updatability clause> of FOR UPDATE with or without a <column name list> is specified, then
ORDER BY shall not be specified.
8) Without Feature B031, ‘‘Basic dynamic SQL’’, and Feature F421, ‘‘Scrolled cursors’’, a <dynamic
declare cursor> shall not specify <cursor scrollability>.
9) Without Feature T551, ‘‘Optional key words for default syntax’’, a <dynamic declare cursor>
shall not specify WITHOUT HOLD.
10) Without Feature S024, ‘‘Enhanced structured types’’, a <value expression> that is a <sort key>
shall not be of a structured type.

15.14 <allocate cursor statement>
Function
Define a cursor based on a prepared statement for a <cursor specification> or assign a cursor to the
ordered set of result sets returned from an SQL-invoked procedure.
Format
<allocate cursor statement> ::=

ALLOCATE <extended cursor name> <cursor intent>
<cursor intent> ::=

<statement cursor>
| <result set cursor>
<statement cursor> ::=

[ <cursor sensitivity> ] [ SCROLL ] CURSOR
[ WITH HOLD ]
[ WITH RETURN ]
FOR <extended statement name>
<result set cursor> ::=

FOR PROCEDURE <specific routine designator>
Syntax Rules
1) If <result set cursor> is specified, then the SQL-invoked routine identified by <specific routine
designator> shall be an SQL-invoked procedure.
Access Rules
None.
General Rules
1) Let S be the <simple value specification> immediately contained in <extended cursor name>.
Let V be the character string that is the result of
condition is raised: invalid cursor name.
2) If the value of the <extended cursor name> is identical to the value of the <extended cursor
name> of any other cursor allocated in the scope of the <extended cursor name>, then an
exception condition is raised: invalid cursor name.
3) If <statement cursor> is specified, then:
a) When the <allocate cursor statement> is executed, if the value of the <extended statement
name> does not identify a statement previously prepared in the scope of the <extended
statement name>, then an exception condition is raised: invalid SQL statement name.
Dynamic SQL 121

b) If the prepared statement associated with the <extended statement name> is not a <cur-
sor specification>, then an exception condition is raised: dynamic SQL error — prepared
statement not a cursor specification.
c) All General Rules of Subclause 14.1, "<declare cursor>", in ISO/IEC 9075-2, apply to <allo-
cate cursor statement>, replacing ‘‘<open statement>’’ with ‘‘<dynamic open statement>’’ and
‘‘<cursor specification>’’ with ‘‘prepared statement’’.
d) An association is made between the value of the <extended cursor name> and the prepared
statement in the scope of the <extended cursor name>. The association is preserved until
the prepared statement is destroyed, at which time the cursor identified by <extended cursor
name> is also destroyed.
4) If <result set cursor> is specified, then:
a) When the <allocate cursor statement> is executed, if the <specific routine designator>
does not identify an SQL-invoked procedure P that has been previously invoked during
the current SQL-session, an exception condition is raised: invalid SQL-invoked procedure
reference.
b) If P did not return any result sets, then an exception condition is raised: no data — no
additional dynamic result sets returned.
c) Let RRS be the ordered set of result sets returned by P.
d) When the <allocate cursor statement> is executed, an association is made between the
<extended cursor name> and the first result set FRS in RRS. The definition of FRS is the
definition of the <cursor specification> CS in P that created FRS. Let CR be the cursor
declared by the <declare cursor> that contains CS.
e) Let T be the table specified by CS. T is the first result set returned from P.
f) A table descriptor for T is effectively created.
g) Cursor CR is placed in the open state and its position is before the first row of T.
Conformance Rules
1) Without Feature B032, ‘‘Extended dynamic SQL’’, conforming SQL language shall not contain
any <allocate cursor statement>.

15.15 <dynamic open statement>
15.15 <dynamic open statement>
Function
Associate input dynamic parameters with a <cursor specification> and open the cursor.
Format
<dynamic open statement> ::=

OPEN <dynamic cursor name> [ <input using clause> ]
Syntax Rules
1) If <dynamic cursor name> DCN is a <cursor name> CN, then the containing <SQL-client
module definition> shall contain a <dynamic declare cursor> whose <cursor name> is CN.
2) Let CR be the cursor identified by DCN.
Access Rules
1) The Access Rules for the <query expression> simply contained in the prepared statement
associated with the <dynamic cursor name> are applied.
General Rules
1) If <dynamic cursor name> is a <cursor name> and the <statement name> of the associated
<dynamic declare cursor> is not associated with a prepared statement, then an exception
condition is raised: invalid SQL statement name.
2) If <dynamic cursor name> is an <extended cursor name> whose value does not identify a cursor
allocated in the scope of the <extended cursor name>, then an exception condition is raised:
invalid cursor name.
3) If the prepared statement associated with the <dynamic cursor name> contains <dynamic
parameter specification>s and an <input using clause> is not specified, then an exception
condition is raised: dynamic SQL error — using clause required for dynamic parameters.
4) The cursor specified by <dynamic cursor name> is updatable if and only if the associated <cursor
specification> specified an updatable cursor.
NOTE 22 – ‘‘updatable cursor’’ is defined in Subclause 14.1, "<declare cursor>", in ISO/IEC 9075-2.
5) If an <input using clause> is specified, then the General Rules specified in Subclause 15.9,
‘‘<input using clause>’’, for <dynamic open statement> are applied.
6) All General Rules of Subclause 14.2, "<open statement>", in ISO/IEC 9075-2, apply to the
<dynamic open statement>.
Conformance Rules
<dynamic open statement>.
Dynamic SQL 123

15.16 <dynamic fetch statement>
15.16 <dynamic fetch statement>
Function
Fetch a row for a cursor declared with a <dynamic declare cursor>.
Format
<dynamic fetch statement> ::=

FETCH [ [ <fetch orientation> ] FROM ] <dynamic cursor name> <output using clause>
Syntax Rules
1) If <fetch orientation> is omitted, then NEXT is implicit.
4) If the implicit or explicit <fetch orientation> is not NEXT, then the <dynamic declare cursor> or
<allocate cursor statement> associated with CR shall specify SCROLL.
Access Rules
None.
General Rules
1) All General Rules of Subclause 14.3, "<fetch statement>", in ISO/IEC 9075-2 are applied to
cursor CR, <fetch orientation>, and an empty <fetch target list>.
2) The General Rules of Subclause 15.10, ‘‘<output using clause>’’, are applied to the <dynamic
fetch statement> and the current row of CR as the retrieved row.
Conformance Rules
<dynamic fetch statement>.

15.17 <dynamic single row select statement>
15.17 <dynamic single row select statement>
Function
Retrieve values from a dynamically-specified row of a table.
Format
<dynamic single row select statement> ::= <query specification>
Syntax Rules
None.
Access Rules
None.
General Rules
1) Let Q be the result of the <query specification>.
2) Case:
a) If the cardinality of Q is greater than 1 (one), then an exception condition is raised: cardi-
nality violation.
b) If Q is empty, then a completion condition is raised: no data.
Conformance Rules
1) Without Feature B031, ‘‘Basic dynamic SQL’’, conforming SQL language shall contain no <dy-
namic single row select statement>.
Dynamic SQL 125

15.18 <dynamic close statement>
15.18 <dynamic close statement>
Function
Close a cursor.
Format
<dynamic close statement> ::=

CLOSE <dynamic cursor name>
Syntax Rules
Access Rules
None.
General Rules
1) All General Rules of Subclause 14.4, "<close statement>", in ISO/IEC 9075-2, apply to the
<dynamic close statement>.
Conformance Rules
<dynamic close statement>.

15.19 <dynamic delete statement: positioned>
Function
Delete a row of a table.
Format
<dynamic delete statement: positioned> ::=

DELETE FROM <target table>
WHERE CURRENT OF <dynamic cursor name>
Syntax Rules
2) Let T be the table identified by the <table name> contained in <target table>.
Access Rules
1) All Access Rules of Subclause 14.6, "<delete statement: positioned>", in ISO/IEC 9075-2, apply
to the <dynamic delete statement: positioned>.
General Rules
1) If DCN is a <cursor name> and the <statement name> of the associated <dynamic declare
cursor> is not associated with a prepared statement, then an exception condition is raised:
invalid SQL statement name.
2) If DCN is an <extended cursor name> whose value does not identify a cursor allocated in the
scope of the <extended cursor name>, then an exception condition is raised: invalid cursor
name.
4) If CR is not an updatable cursor, then an exception condition is raised: invalid cursor name.
5) Let T be the simply underlying table of CR. T is the subject table of the <dynamic delete
statement: positioned>. T shall have exactly one leaf underlying table LUT. Let LUTN be a
<table name> that identifies LUT.
6) Let TN be the <table name> contained in <target table>. If TN does not identify LUTN, or if
ONLY is specified and the <table reference> in T that references LUT does not specify ONLY, or
if ONLY is not specified and the <table reference> in T that references LUT does specify ONLY,
then an exception condition is raised: target table disagrees with cursor specification.
7) All General Rules of Subclause 14.6, "<delete statement: positioned>", in ISO/IEC 9075-2, apply
to the <dynamic delete statement: positioned>, replacing ‘‘<delete statement: positioned>’’ with
‘‘<dynamic delete statement: positioned>’’.
Dynamic SQL 127

Conformance Rules
<dynamic delete statement: positioned>.

15.20 <dynamic update statement: positioned>
Function
Update a row of a table.
Format
<dynamic update statement: positioned> ::=

UPDATE <target table>
SET <set clause list>
WHERE CURRENT OF <dynamic cursor name>
Syntax Rules
2) Let T be the table identified by the <table name> contained in <target table>.
3) The scope of the <table name> is the entire <dynamic update statement: positioned>.
Access Rules
1) All Access Rules of Subclause 14.9, "<update statement: positioned>", in ISO/IEC 9075-2, apply
to the <dynamic update statement: positioned>.
General Rules
1) If DCN is a <cursor name> and the <statement name> of the associated <dynamic declare
cursor> is not associated with a prepared statement, then an exception condition is raised:
invalid SQL statement name.
2) If DCN is an <extended cursor name> whose value does not identify a cursor allocated in the
scope of the <extended cursor name>, then an exception condition is raised: invalid cursor
name.
4) If CR is not an updatable cursor, then an exception condition is raised: invalid cursor name.
5) Let T be the simply underlying table of CR. T is the subject table of the <dynamic update
statement: positioned>. T shall have exactly one leaf underlying table LUT. Let LUTN be a
<table name> that identifies LUT.
6) Let TN be the <table name> contained in <target table>. If TN does not identify LUTN, or if
ONLY is specified and the <table reference> in T that references LUT does not specify ONLY, or
if ONLY is not specified and the <table reference> in T that references LUT does specify ONLY,
then an exception condition is raised: target table disagrees with cursor specification.
7) If any object column is directly or indirectly referenced in the <order by clause> of the <cursor
specification> for CR, then an exception condition is raised: attempt to assign to ordering
column.
Dynamic SQL 129

8) If any object column identifies a column that is not identified by a <column name> contained
in the explicit or implicit <column name list> of the explicit or implicit <updatability clause>
of the <cursor specification> for CR, then an exception condition is raised: attempt to assign to
non-updatable column.
9) All General Rules of Subclause 14.9, "<update statement: positioned>", in ISO/IEC 9075-2,
apply to the <dynamic update statement: positioned>, replacing ‘‘<cursor name>’’ with ‘‘<dy-
namic cursor name>’’ and ‘‘<update statement: positioned>’’ with ‘‘<dynamic update statement:
positioned>’’.
Conformance Rules
<dynamic update statement: positioned>.

15.21 <preparable dynamic delete statement: positioned>
15.21 <preparable dynamic delete statement: positioned>
Function
Delete a row of a table through a dynamic cursor.
Format
<preparable dynamic delete statement: positioned> ::=

DELETE [ FROM <target table> ]
WHERE CURRENT OF [ <scope option> ] <cursor name>
Syntax Rules
1) If <target table> is not specified, then let TN be the name of the leaf underlying table LUT of
the <cursor specification> identified by <cursor name>.
Case:
i) If the <table reference> that references LUT specifies ONLY, then the <target table>
ONLY ( TN )
is implicit.
ii) Otherwise, the <target table>

TN
is implicit.
2) All Syntax Rules of Subclause 14.6, "<delete statement: positioned>", in ISO/IEC 9075-2, apply
to the <preparable dynamic delete statement: positioned>, replacing ‘‘<declare cursor>’’ with
‘‘<dynamic declare cursor> or <allocate cursor statement>’’ and ‘‘<delete statement: positioned>’’
with ‘‘<preparable dynamic delete statement: positioned>’’.
Access Rules
1) All Access Rules of Subclause 14.6, "<delete statement: positioned>", in ISO/IEC 9075-2, apply
to the <preparable dynamic delete statement: positioned>.
General Rules
1) All General Rules of Subclause 14.6, "<delete statement: positioned>", in ISO/IEC 9075-2,
apply to the <preparable dynamic delete statement: positioned>, replacing ‘‘<delete statement:
positioned>’’ with ‘‘<preparable dynamic delete statement: positioned>’’.
Conformance Rules
<preparable dynamic delete statement: positioned>.
Dynamic SQL 131

15.22 <preparable dynamic update statement: positioned>
15.22 <preparable dynamic update statement: positioned>
Function
Update a row of a table through a dynamic cursor.
Format
<preparable dynamic update statement: positioned> ::=

UPDATE [ <target table> ]
SET <set clause list>
WHERE CURRENT OF [ <scope option> ] <cursor name>
Syntax Rules
1) If <target table> is not specified, then let TN be the name of the leaf underlying table LUT of
the <cursor specification> identified by <cursor name>.
Case:
i) If the <table reference> that references LUT specifies ONLY, then the <target table>
ONLY ( TN )
is implicit.
ii) Otherwise, the <target table>

TN
is implicit.
2) All Syntax Rules of Subclause 14.9, "<update statement: positioned>", in ISO/IEC 9075-2,
apply to the <preparable dynamic update statement: positioned>, replacing ‘‘<declare cur-
sor>’’ with ‘‘<dynamic declare cursor> or <allocate cursor statement>’’ and ‘‘<update statement:
positioned>’’ with ‘‘<preparable dynamic update statement: positioned>’’.
Access Rules
1) All Access Rules of Subclause 14.9, "<update statement: positioned>", in ISO/IEC 9075-2, apply
to the <preparable dynamic update statement: positioned>.
General Rules
1) All General Rules of Subclause 14.9, "<update statement: positioned>", in ISO/IEC 9075-2,
apply to the <preparable dynamic update statement: positioned>, replacing ‘‘<update statement:
positioned>’’ with ‘‘<preparable dynamic update statement: positioned>’’.
Conformance Rules
<preparable dynamic update statement: positioned>.

16 Embedded SQL
16.1 <embedded SQL host program>
Function
Specify an <embedded SQL host program>.
Format
<embedded SQL host program> ::=

<embedded SQL Ada program>
| <embedded SQL C program>
| <embedded SQL COBOL program>
| <embedded SQL Fortran program>
| <embedded SQL MUMPS program>
| <embedded SQL Pascal program>
| <embedded SQL PL/I program>
<embedded SQL statement> ::=

<SQL prefix>
<statement or declaration>
[ <SQL terminator> ]
<statement or declaration> ::=

<declare cursor>
| <dynamic declare cursor>
| <temporary table declaration>
| <embedded authorization declaration>
| <embedded path specification>
| <embedded transform group specification>
| <embedded exception declaration>
| <handler declaration>
| <SQL-invoked routine>
| <SQL procedure statement>
<SQL prefix> ::=

EXEC SQL
| <ampersand>SQL<left paren>
<SQL terminator> ::=

END-EXEC
| <semicolon>
| <right paren>
<embedded authorization declaration> ::=

DECLARE <embedded authorization clause>
<embedded authorization clause> ::=

SCHEMA <schema name>
| AUTHORIZATION <embedded authorization identifier>
| SCHEMA <schema name> AUTHORIZATION <embedded authorization identifier>
Embedded SQL 133

<embedded authorization identifier> ::=

<module authorization identifier>
<embedded path specification> ::=
<path specification>
<embedded transform group specification> ::=

<transform group specification>
<embedded SQL declare section> ::=

<embedded SQL begin declare>
[ <embedded character set declaration> ]
[ <host variable definition>... ]
<embedded SQL end declare>
| <embedded SQL MUMPS declare>
<embedded character set declaration> ::=

SQL NAMES ARE <character set specification>
<embedded SQL begin declare> ::=

<SQL prefix> BEGIN DECLARE SECTION [ <SQL terminator> ]
<embedded SQL end declare> ::=

<SQL prefix> END DECLARE SECTION [ <SQL terminator> ]
<embedded SQL MUMPS declare> ::=

<SQL prefix>
BEGIN DECLARE SECTION
[ <embedded character set declaration> ]
[ <host variable definition>... ]
END DECLARE SECTION
<SQL terminator>
<host variable definition> ::=

<Ada variable definition>
| <C variable definition>
| <COBOL variable definition>
| <Fortran variable definition>
| <MUMPS variable definition>
| <Pascal variable definition>
| <PL/I variable definition>
<embedded variable name> ::=

<colon><host identifier>
<host identifier> ::=

<Ada host identifier>
| <C host identifier>
| <COBOL host identifier>
| <Fortran host identifier>
| <MUMPS host identifier>
| <Pascal host identifier>
| <PL/I host identifier>

Syntax Rules
1) An <embedded SQL host program> is a compilation unit that consists of programming language
text and SQL text. The programming language text shall conform to the requirements of a
specific standard programming language. The SQL text shall consist of one or more <embedded
SQL statement>s and, optionally, one or more <embedded SQL declare section>s, as defined in
this International Standard.
NOTE 23 – ‘‘Compilation unit’’ is defined in Subclause 4.21, "SQL-client modules", in ISO/IEC 9075-2.
2) Case:
a) An <embedded SQL statement> or <embedded SQL MUMPS declare> that is contained

in an <embedded SQL MUMPS program> shall contain an <SQL prefix> that is ‘‘<amper-
sand>SQL<left paren>’’. There shall be no <separator> between the <ampersand> and
‘‘SQL’’ nor between ‘‘SQL’’ and the <left paren>.
b) An <embedded SQL statement>, <embedded SQL begin declare>, or <embedded SQL end
declare> that is not contained in an <embedded SQL MUMPS program> shall contain an
<SQL prefix> that is ‘‘EXEC SQL’’.
3) Case:
a) An <embedded SQL statement>, <embedded SQL begin declare>, or <embedded SQL end
declare> contained in an <embedded SQL COBOL program> shall contain an <SQL termi-
nator> that is END-EXEC.
b) An <embedded SQL statement>, <embedded SQL begin declare>, or <embedded SQL end
declare> contained in an <embedded SQL Fortran program> shall not contain an <SQL
terminator>.
c) An <embedded SQL statement>, <embedded SQL begin declare>, or <embedded SQL end
declare> contained in an <embedded SQL Ada program>, <embedded SQL C program>,
<embedded SQL Pascal program>, or <embedded SQL PL/I program> shall contain an
<SQL terminator> that is a <semicolon>.
d) An <embedded SQL statement> or <embedded SQL MUMPS declare> that is contained in

an <embedded SQL MUMPS program> shall contain an <SQL terminator> that is a <right
paren>.
4) Case:
a) An <embedded SQL declare section> that is contained in an <embedded SQL MUMPS

program> shall be an <embedded SQL MUMPS declare>.
b) An <embedded SQL declare section> that is not contained in an <embedded SQL MUMPS
program> shall not be an <embedded SQL MUMPS declare>.
NOTE 24 – There is no restriction on the number of <embedded SQL declare section>s that may be
contained in an <embedded SQL host program>.
5) The <token>s comprising an <SQL prefix>, <embedded SQL begin declare>, or <embedded
SQL end declare> shall be separated by <space> characters and shall be specified on one line.
Otherwise, the rules for the continuation of lines and tokens from one line to the next and
for the placement of host language comments are those of the programming language of the
containing <embedded SQL host program>.
Embedded SQL 135

6) If an <embedded authorization declaration> appears in an <embedded SQL host program>,

then it shall be contained in the first <embedded SQL statement> of that <embedded SQL host
program>.
7) An <embedded SQL host program> shall not contain more than one <embedded path specifica-
tion>.
8) An <embedded SQL host program> shall not contain more than one <embedded transform group
specification>.
9) Case:
i) If <embedded transform group specification> is not specified, then an <embedded transform

group specification> containing a <multiple group specification> with a <group specification>
GS for each <host variable declaration> that has an associated user-defined type UDT, but is
not a user-defined locator variable is implicit. The <group name> of GS is implementation-
defined and its <user-defined type> is UDT.
ii) If <embedded transform group specification> contains a <single group specification> with
a <group name> GN, then an <embedded transform group specification> containing a
<multiple group specification> with a <group specification> GS for each <host variable
declaration> that has an associated user-defined type UDT, but is not a user-defined type
locator variable is implicit. The <group name> of GS is GN and its <user-defined type> is
UDT.
iii) If <embedded transform group specification> contains a <multiple group specification> MGS,
then an <embedded transform group specification> containing a <multiple group specifica-
tion> that contains MGS extended with a <group specification> GS for each <host variable
declaration> that has an associated user-defined type UDT, but is not a user-defined locator
variable and the <user-defined type name> of UDT is not contained in any <group specifica-
tion> contained in MGS is implicit. The <group name> of GS is implementation-defined and
its <user-defined type> is UDT.
10) The implicit or explicit <embedded transform group specification> precedes in the text of the
<embedded SQL host program> every <host variable declaration>.
11) An <embedded SQL host program> shall contain no more than one <embedded character set
declaration>. If an <embedded character set declaration> is not specified, then an <embedded
character set declaration> that specifies an implementation-defined character set that contains
at least every character that is in <SQL language character> is implicit.
12) A <temporary table declaration> that is contained in an <embedded SQL host program> shall
precede in the text of that <embedded SQL host program> any SQL-statement or <declare
cursor> that references the <table name> of the <temporary table declaration>.
13) A <declare cursor> that is contained in an <embedded SQL host program> shall precede in the
text of that <embedded SQL host program> any SQL-statement that references the <cursor
name> of the <declare cursor>.
14) A <dynamic declare cursor> that is contained in an <embedded SQL host program> shall
precede in the text of that <embedded SQL host program> any SQL-statement that references
the <cursor name> of the <dynamic declare cursor>.

15) An <embedded exception declaration> that is contained in an <embedded SQL host program>
shall precede in the text of that <embedded SQL host program> any SQL-statement that refer-
ences the <exception name> contained in the <embedded exception declaration>.
16) An <exception name> contained in an <embedded exception declaration> that is immediately

contained in an <embedded SQL host program> shall not be equivalent to any other <exception
name> contained in any other <embedded exception declaration> that is immediately contained
in the <embedded SQL host program>.
17) Any <host identifier> that is contained in an <embedded SQL statement> in an <embedded
SQL host program> shall be defined in exactly one <host variable definition> contained in
that <embedded SQL host program>. In programming languages that support <host variable
definition>s in subprograms, two <host variable definition>s with different, non-overlapping
scope in the host language are to be regarded as defining different host variables, even if they
specify the same variable name. That <host variable definition> shall appear in the text of the
<embedded SQL host program> prior to any <embedded SQL statement> that references the
<host identifier>. The <host variable definition> shall be such that a host language reference
to the <host identifier> is valid at every <embedded SQL statement> that contains the <host
identifier>.
18) A <host variable definition> defines the host language data type of the <host identifier>.
For every such host language data type an equivalent SQL <data type> is specified in
Subclause 16.3, ‘‘<embedded SQL Ada program>’’, Subclause 16.4, ‘‘<embedded SQL C pro-
gram>’’, Subclause 16.5, ‘‘<embedded SQL COBOL program>’’, Subclause 16.6, ‘‘<embedded
SQL Fortran program>’’, Subclause 16.7, ‘‘<embedded SQL MUMPS program>’’, Subclause 16.8,
‘‘<embedded SQL Pascal program>’’, and Subclause 16.9, ‘‘<embedded SQL PL/I program>’’.
19) An <embedded SQL host program> shall contain a <host variable definition> that specifies
SQLSTATE.
20) If one or more <host variable definition>s that specify SQLSTATE appear in an <embedded
SQL host program>, then the <host variable definition>s shall be such that a host language
reference to SQLSTATE is valid at every <embedded SQL statement>, including <embedded
SQL statement>s that appear in any subprograms contained in that <embedded SQL host
program>. The first such <host variable definition> of SQLSTATE shall appear in the text of
the <embedded SQL host program> prior to any <embedded SQL statement>.
21) Given an <embedded SQL host program> H, there is an implied standard-conforming SQL-client
module M and an implied standard-conforming host program P derived from H. The derivation
of the implied program P and the implied <SQL-client module definition> M of an <embedded
SQL host program> H effectively precedes the processing of any host language program text
manipulation commands such as inclusion or copying of text.
Given an <embedded SQL host program> H with an implied <SQL-client module definition> M
and an implied program P defined as above:
a) The implied <SQL-client module definition> M of H shall be a standard-conforming <SQL-

client module definition>.
b) If H is an <embedded SQL Ada program>, an <embedded SQL C program>, an <embed-

ded SQL COBOL program>, an <embedded SQL Fortran program>, an <embedded SQL
MUMPS program>, an <embedded SQL Pascal program>, or an <embedded SQL PL/I
program>, then the implied program P shall be a standard-conforming Ada program, a
Embedded SQL 137

standard-conforming C program, a standard-conforming COBOL program, a standard-

conforming Fortran program, a standard-conforming MUMPS program, a standard-
conforming Pascal program, or standard-conforming PL/I program, respectively.
22) M is derived from H as follows:
a) M contains a <module name clause> whose <module name> is either implementation-

dependent or is omitted.
b) M contains a <module character set specification> that is identical to the explicit or implicit
<embedded character set declaration> with the keyword ‘‘SQL’’ removed.
c) M contains a <language clause> that specifies either ADA, C, COBOL, FORTRAN, MUMPS,
PASCAL, or PLI, where H is respectively an <embedded SQL Ada program>, an <embedded
SQL C program>, an <embedded SQL COBOL program>, an <embedded SQL Fortran
program>, an <embedded SQL MUMPS program>, an <embedded SQL Pascal program>, or
an <embedded SQL PL/I program>.
d) Case:
i) If H contains an <embedded authorization declaration> EAD, then let EAC be the

<embedded authorization clause>contained in EAD; M contains a <module authorization
clause> that specifies EAC.
ii) Otherwise, let SN be an implementation-defined <schema name>; M contains a <module

authorization clause> that specifies ‘‘SCHEMA SN’’.
e) Case:
i) If H contains an <embedded path specification> EPS, then M contains the <module path
specification> EPS.
ii) Otherwise, M contains am implementation-defined <module path specification>.
f) M contains a <module transform group specification> that is identical to the explicit or

implicit <embedded transform group specification>.
g) For every <declare cursor> EC contained in H, M contains one <declare cursor> PC and one
<externally-invoked procedure> PS that contains an <open statement> that references PC.
i) The <procedure name> of PS is implementation-dependent. PS contains a <host pa-

rameter declaration> PD for each distinct <embedded variable name> EVN contained
in PC with an implementation-dependent <host parameter name> PN and the <host
parameter data type> PT, determined as follows:
Case:
1) If EVN identifies a binary large object locator variable, then PT is BLOB AS

LOCATOR.
2) If EVN identifies a character large object locator variable, then PT is CLOB AS

LOCATOR.
3) If EVN identifies an array locator variable, then PT is AAT AS LOCATOR, where

AAT is the associated array type of V.

4) If EVN identifies a user-defined type locator variable, then PT is UDT AS

LOCATOR, where UDT is the associated user-defined type of V.
5) Otherwise, PT is the SQL data type that corresponds to the host language data
type of EVN as specified in Subclause 13.6, "Data type correspondences", in ISO/IEC
9075-2.
ii) PS contains a <host parameter declaration> that specifies SQLSTATE . The order of
<host parameter declaration>s in PS is implementation-dependent. PC is a copy of EC
in which each EVN has been replaced as follows:
Case:
1) If EVN does not identify user-defined type locator variable, but EVN identifies a host
variable that has an associated user-defined type UT, then:
A) Let GN be the <group name> corresponding to the <user-defined type name> of

UT contained in <group specification> contained in <embedded group specifica-
tion>.
B) Apply the Syntax Rules of Subclause 10.17, "Determination of a to-sql function",

in ISO/IEC 9075-2, with DT and GN as TYPE and GROUP, respectively. There
shall be an applicable to-sql function TSF.
C) Let the declared type of the single SQL parameter of TSF be TPT. PT and TPT
shall be mutually assignable.
D) EVN is replaced by:

TSFN(CAST(PN AS TPT))
2) Otherwise, EVN is replaced by:

PN
h) For every <dynamic declare cursor> EC in H, M contains one <dynamic declare cursor> PC
that is a copy of EC.
i) M contains one <temporary table declaration> for each <temporary table declaration>
contained in H. Each <temporary table declaration> of M is a copy of the corresponding
<temporary table declaration> of H.
j) M contains one <embedded exception declaration> for each <embedded exception decla-
ration> contained in H. Each <embedded exception declaration> of M is a copy of the
corresponding <embedded exception declaration> of H.
k) M contains an <externally-invoked procedure> for each <SQL procedure statement> con-

tained in H. The <externally-invoked procedure> PS of M corresponding with an <SQL
procedure statement> ES of H is defined as follows.
Case:
i) If ES is not an <open statement>, then:
1) The <procedure name> of PS is implementation-dependent.
Embedded SQL 139

2) Let n be the number of distinct <embedded variable name>s contained in ES. Let
HVNi , 1 (one) i n, be the i-th such <embedded variable name> and let HVi be
the host variable identified by HVNi .
3) For each HVNi , 1 (one) i n, PS contains a <host parameter declaration> PDi

defining a host parameter Pi such that:
A) The <host parameter name> PNi of PDi is implementation-dependent.
B) The <host parameter data type> PTi of PDi is determined as follows:
I) If HVi is a binary large object locator variable, then PTi is BLOB AS

LOCATOR.
II) If HVi is a character large object locator variable, then PTi is CLOB AS
LOCATOR.
III) If HVi is an array locator variable, then PTi is AAT AS LOCATOR, where
AAT is the associated array type of HVi .
IV) If HVi is user-defined type locator variable, then PTi is UDT AS LOCATOR,
where UDT is the associated user-defined type of HVi .
V) Otherwise, PTi is the SQL data type that corresponds to the host language
data type of HVi as specified in Subclause 13.6, "Data type correspondences",
in ISO/IEC 9075-2.
4) PS contains a <host parameter declaration> that specifies SQLSTATE.
5) The order of the <host parameter declaration>s PDi , 1 (one) i n, is implementation-

dependent.
6) For each HVNi , 1 (one) i n, that identifies some HVi that has an associated
user-defined type, but is not a user-defined type locator variable, apply the Syntax
Rules of Subclause 9.6, "Host parameter mode determination", in ISO/IEC 9075-2,
with the PDi corresponding to HVNi and ES as <host parameter declaration> and
<SQL procedure statement>, respectively, to determine whether the corresponding
Pi is an input host parameter, an output host parameter, or both an input host
parameter and an output host parameter.
A) Among Pi , 1 (one) i n, let a be the number of input host parameters, b be the

number of output host parameters, and let c be the number of host parameters
that are both input host parameters and output host parameters.
B) Among Pi , 1 (one) i n, let PIj , 1 (one) j a, be the input host parameters,

let POk , 1 (one) k b, be the output host parameters, and let PIOl , 1 (one) l
c, be the host parameters that are both input host parameters and output host
parameters.
C) Let PNIj , 1 (one) j a, be the <host parameter name> of PIj . Let PNOk , 1
(one) k b, be the <host parameter name> of POk . Let PNIOl , 1 (one) l
c, be the <host parameter name> of PIOl .
D) Let HVIj , 1 (one) j a, be the host variable corresponding to PIj . Let HVOk , 1
(one) k b, be the host variable corresponding to POk . Let HVIOl , 1 (one) l
c, be the host variable corresponding to PIOl .

E) Let TSIj , 1 (one) j a, be the associated SQL data types of HVIj . Let TSOk , 1
(one) k b, be the associated SQL data types of HVOk . Let TSIOl , 1 (one) l
c, be the associated SQL data types of HVIOl.
F) Let TUIj , 1 (one) j a, be the associated user-defined types of HVIj . Let
TUOk , 1 (one) k b, be the associated user-defined types of HVOk . Let
TUIOl , 1 (one) l c, be the associated user-defined types of HVIOl .
G) Let GNIj , 1 (one) j a, be the <group name>s corresponding to the <user-

defined type name> of TUIj contained in the <group specification> contained
in <embedded group specification>. Let GNOk , 1 (one) k b, be the <group
name>s corresponding to the <user-defined type name> of TUOk contained in the
<group specification> contained in <embedded group specification>. Let GNIOl ,
1 (one) l c, be the <group name>s corresponding to the <user-defined type
name> of TUIOl contained in the <group specification> contained in <embedded
group specification>.
H) For every j, 1 (one) j a, apply the Syntax Rules of Subclause 10.17,

"Determination of a to-sql function", in ISO/IEC 9075-2, with TUIj and GNIj
as TYPE and GROUP, respectively. There shall be an applicable to-sql function
TSFIj identified by <routine name> TSINj . Let TTIj be the data type of the
single SQL parameter of TSFIj . TTIj and TSIj shall be mutually assignable.
I) For every l, 1 (one) l c, apply the Syntax Rules of Subclause 10.17,

"Determination of a to-sql function", in ISO/IEC 9075-2, with TUIOl and GNIOl
as TYPE and Subclause 7.9, "<group by clause>", respectively. There shall be
an applicable to-sql function TSFIOl identified by <routine name> TSIONl . Let
TTIOl be the data type of the single SQL parameter of TSFIOl . TTIOl and
TSIOl shall be mutually assignable.
J) For every k, 1 (one) k b, apply the Syntax Rules of Subclause 10.15,

"Determination of a from-sql function", in ISO/IEC 9075-2, with TUOk and
GNOk as TYPE and GROUP, respectively. There shall be an applicable from-sql
function FSFOk identified by <routine name> FSONk . Let TROk be the result
data type of FSFOk . TROk and TSOk shall be mutually assignable.
K) For every l, 1 (one) l c, apply the Syntax Rules of Subclause 10.15,

"Determination of a from-sql function", in ISO/IEC 9075-2, with TUIOl and
GNIOl as TYPE and GROUP, respectively. There shall be an applicable from-sql
function FSFIOl identified by <routine name> FSIONl . Let TRIOl be the result
data type of FSFIOl . TRIOl and TSIOl shall be mutually assignable.
L) Let SVIj , 1 (one) j a, SVOk , 1 (one) k b, and SVIOl , 1 (one) l

c, be implementation-dependent <SQL variable name>s, each of which is not
equivalent to any other <SQL variable name> contained in ES, to any <SQL
parameter name> contained in ES, or to any <column name> contained in ES.
7) Let NES be an <SQL procedure statement> that is a copy of ES in which every

HVNi , 1 (one) i n, is replaced as follows.
Case:
A) If HVi has an associated user-defined type but is not a user-defined type locator
variable, then
Embedded SQL 141

Case:
I) If Pi is an input host parameter, then let PIj , 1 (one) j a, be the input

host parameter that corresponds to Pi ; HVNi is replaced by SVIj .
II) If Pi is an output host parameter, then let POk , 1 (one) k b, be the

output host parameter that corresponds to Pi ; HVNi is replaced by SVOk .
III) Otherwise, let PIOl , 1 (one) l c, be the intput host parameter and the
output host parameter that corresponds to Pi ; HVNi is replaced by SVIOl .
B) Otherwise, HVNi is replaced by PNi .
8) The <SQL procedure statement> of PS is:
BEGIN ATOMIC
DECLARE SVI1 TUI1;
.
.
.
DECLARE SVIa TUIa;
DECLARE SVO1 TUO1;
.
.
.
DECLARE SVOa TUOa;
DECLARE SVIO1 TUIO1;
.
.
.
DECLARE SVIOa TUIOa;
SET SVI1 = TSIN1 (CAST (PNI1 AS TTI1));
.
.
.
SET SVIa = TSINa (CAST (PNIa AS TTIa));
SET SVIO1 = TSION1 (CAST (PNIO1 AS TTIO1));
.
.
.
SET SVIOc = TSIONc (CAST (PNIOc AS TTIOc));
NES;
SET PNO1 = CAST ( FSON1 (SVO1) AS TSO1);
.
.
.
SET PNOb = CAST ( FSONb (SVOb) AS TSOb);
SET PNIO1 = CAST ( FSION1 (SVIO1) AS TSIO1);
.
.
.
SET PNIOc = CAST ( FSIONc (SVIOc) AS TSIOc);
END;
9) Whether one <externally-invoked procedure> of M can correspond to more than one

<SQL procedure statement> of H is implementation-dependent.

ii) If ES is an <open statement>, then:
1) Let EC be the <declare cursor> in H referenced by ES.
2) PS is the <externally-invoked procedure> in M that contains an <open statement>

that references the <declare cursor> in M corresponding to EC.
23) P is derived from H as follows:
a) Each <embedded SQL begin declare>, <embedded SQL end declare>, and <embedded char-
acter set declaration> has been deleted. If the embedded host language is MUMPS, then
each <embedded SQL MUMPS declare> has been deleted.
b) Each <host variable definition> in an <embedded SQL declare section> has been replaced by
a valid data definition in the target host language according to the Syntax Rules specified in
an <embedded SQL Ada program>, <embedded SQL C program>, <embedded SQL COBOL
program>, <embedded SQL Fortran program>, <embedded SQL Pascal program>, or an
<embedded SQL PL/I program> clause.
c) Each <embedded SQL statement> that contains a <declare cursor>, a <dynamic declare
cursor>, an <SQL-invoked routine>, or a <temporary table declaration> has been deleted,
and every <embedded SQL statement> that contains an <embedded exception declaration>
has been replaced with statements of the host language that will have the effect specified by
the General Rules of Subclause 16.2, ‘‘<embedded exception declaration>’’.
d) Each <embedded SQL statement> that contains an <SQL procedure statement> has been
replaced by host language statements that perform the following actions:
i) A host language procedure or subroutine call of the <externally-invoked procedure> of

the implied <SQL-client module definition> M of H that corresponds with the <SQL
procedure statement>.
If the <SQL procedure statement> is not an <open statement>, then the arguments
of the call include each distinct <host identifier> contained in the <SQL procedure
statement> together with the SQLSTATE <host identifier>. If the <SQL procedure
statement> is an <open statement>, then the arguments of the call include each distinct
<host identifier> contained in the corresponding <declare cursor> of H together with the
SQLSTATE <host identifier>.
The order of the arguments in the call corresponds with the order of the corresponding
<host parameter declaration>s in the corresponding <externally-invoked procedure>.
NOTE 25 – In an <embedded SQL Fortran program>, the ‘‘SQLSTATE’’ variable may be
abbreviated to ‘‘SQLSTA’’. See the Syntax Rules of Subclause 16.6, ‘‘<embedded SQL Fortran
program>’’.
ii) Exception actions, as specified in Subclause 16.2, ‘‘<embedded exception declaration>’’.
e) Each <statement or declaration> that contains an <embedded authorization declaration> is

deleted.
Embedded SQL 143

Access Rules
1) For every host variable whose <embedded variable name> is contained in <statement or decla-
ration> and has an associated user-defined type, the current privileges shall include EXECUTE
privilege on all from-sql functions (if any) and all to-sql functions (if any) referenced in the
corresponding SQL-client module.
General Rules
1) The interpretation of an <embedded SQL host program> H is defined to be equivalent to the
interpretation of the implied program P of H and the implied <SQL-client module definition> M
of H.
2) If the cursor mode of the current SQL-transaction is cascade off, and the <embedded SQL state-
ment> is other than a <close statement>, a <delete statement: positioned>, a <fetch statement>,
an <open statement>, an <update statement: positioned>, a <dynamic close statement>, a
<dynamic delete statement: positioned>, a <dynamic fetch statement>, a <dynamic open state-
ment>, or a <dynamic update statement: positioned>, then an exception condition is raised:
invalid SQL statement.
Conformance Rules
1) Without Feature B051, ‘‘Enhanced execution rights’’, conforming SQL language shall not contain
any <embedded authorization declaration>.
2) Without Feature F451, ‘‘Character set definition’’, or Feature F461, ‘‘Named character sets’’, an
<embedded SQL declare section> shall not contain an <embedded character set declaration>.
3) Without Feature F361, ‘‘Subprogram support’’, no two <host variable definition>s shall specify
the same variable name.
4) Without Feature S071, ‘‘SQL paths in function and type name resolution’’, <embedded path
specification> shall not be specified.
5) Without Feature S241, ‘‘Transform functions’’, <embedded transform group specification> shall
not be specified.

16.2 <embedded exception declaration>
Function
Specify the action to be taken when an SQL-statement causes a specific class of condition to be
raised.
Format
<embedded exception declaration> ::=

WHENEVER <condition> <condition action>
<condition> ::=
<SQL condition>
<SQL condition> ::=

<major category>
| SQLSTATE ( <SQLSTATE class value> [ , <SQLSTATE subclass value> ] )
| CONSTRAINT <constraint name>
<major category> ::=

SQLEXCEPTION
| SQLWARNING
| NOT FOUND
<SQLSTATE class value> ::=

<SQLSTATE char><SQLSTATE char> !! See the Syntax Rules.
<SQLSTATE subclass value> ::=

<SQLSTATE char><SQLSTATE char><SQLSTATE char> !! See the Syntax Rules.
<SQLSTATE char> ::= <simple Latin upper case letter> | <digit>
<condition action> ::=

CONTINUE | <go to>
<go to> ::=

{ GOTO | GO TO } <goto target>
<goto target> ::=

<host label identifier>
| <unsigned integer>
| <host PL/I label variable>
<host label identifier> ::= !! See the Syntax Rules.
<host PL/I label variable> ::= !! See the Syntax Rules.
Syntax Rules
1) SQLWARNING, NOT FOUND, and SQLEXCEPTION correspond to SQLSTATE class values
corresponding to categories W, N, and X in Table 10, ‘‘SQLSTATE class and subclass values’’,
respectively.
Embedded SQL 145

2) An <embedded exception declaration> contained in an <embedded SQL host program> applies

to an <SQL procedure statement> contained in that <embedded SQL host program> if and only
if the <SQL procedure statement> appears after the <embedded exception declaration> that has
condition C in the text sequence of the <embedded SQL host program> and no other <embedded
exception declaration> E that satisfies one of the following conditions appears between the
<embedded exception declaration> and the <SQL procedure statement> in the text sequence of
the <embedded SQL host program>.
Let D be the <condition> contained in E.
Case:
a) D is the same as C.
b) D is a <major category> and belongs to the same class to which C belongs.
c) D contains an <SQLSTATE class value>, but does not contain an <SQLSTATE subclass
value>, and E contains the same <SQLSTATE class value> that C contains.
d) D contains the <SQLSTATE class value> that corresponds to integrity constraint violation
and C contains CONSTRAINT.
3) In the values of <SQLSTATE class value> and <SQLSTATE subclass value>, there shall be no
<separator> between the <SQLSTATE char>s.
4) The values of <SQLSTATE class value> and <SQLSTATE subclass value> shall correspond
to class values and subclass values, respectively, specified in Table 10, ‘‘SQLSTATE class and
subclass values’’.
5) If an <embedded exception declaration> specifies a <go to>, then the <host label identifier>,
<host PL/I label variable>, or <unsigned integer> of the <go to> shall be such that a host
language GO TO statement specifying that <host label identifier>, <host PL/I label variable>,
or <unsigned integer> is valid at every <SQL procedure statement> to which the <embedded
exception declaration> applies.
NOTE 26 –
If an <embedded exception declaration> is contained in an <embedded SQL Ada program>, then
the <goto target> of a <go to> should specify a <host label identifier> that is a label_name in the
containing <embedded SQL Ada program>.
If an <embedded exception declaration> is contained in an <embedded SQL C program>, then the
<goto target> of a <go to> should specify a <host label identifier> that is a label in the containing
<embedded SQL C program>.
If an <embedded exception declaration> is contained in an <embedded SQL COBOL program>, then
the <goto target> of a <go to> should specify a <host label identifier> that is a section-name or an
unqualified paragraph-name in the containing <embedded SQL COBOL program>.
If an <embedded exception declaration> is contained in an <embedded SQL Fortran program>, then
the <goto target> of a <go to> should be an <unsigned integer> that is the statement label of an
executable statement that appears in the same program unit as the <go to>.
If an <embedded exception declaration> is contained in an <embedded SQL MUMPS program>,
then the <goto target> of a <go to> should be a gotoargument that is the statement label of an
executable statement that appears in the same <embedded SQL MUMPS program>.
If an <embedded exception declaration> is contained in an <embedded SQL Pascal program>, then
the <goto target> of a <go to> should be an <unsigned integer> that is a label.
If an <embedded exception declaration> is contained in an <embedded SQL PL/I program>, then
the <goto target> of a <go to> should specify either a <host label identifier> or a <host PL/I label
variable>.

Case:
— If <host label identifier> is specified, then the <host label identifier> should be a label constant
in the containing <embedded SQL PL/I program>.
— If <host PL/I label variable> is specified, then the <host PL/I label variable> should be a PL/I
label variable declared in the containing <embedded SQL PL/I program>.
Access Rules
None.
General Rules
1) Immediately after the execution of an <SQL procedure statement> STMT in an <embedded SQL
host program> that returns an SQLSTATE value other than successful completion:
a) Let E be the set of <embedded exception declaration>s that are contained in the <embed-
ded SQL host program> containing STMT, that applies to STMT, and that specifies an
<condition action> that is <go to>.
b) Let CV and SCV be respectively the values of the class and subclass of the SQLSTATE value
that indicates the result of the <SQL procedure statement>.
c) If the execution of the <SQL procedure statement> caused the violation of one or more
constraints or assertions, then:
i) Let ECN be the set of <embedded exception declaration>s in E that specify CONSTRAINT
and the <constraint name> of a constraint that was violated by execution of STMT.
ii) If ECN contains more than one <embedded exception declaration>, then an implementation-
dependent <embedded exception declaration> is chosen from ECN; otherwise, the single
<embedded exception declaration> in ECN is chosen.
iii) A GO TO statement of the host language is performed, specifying the <host label iden-
tifier>, <host PL/I label variable>, or <unsigned integer> of the <go to> specified in the
<embedded exception declaration> chosen from ECN.
d) Otherwise:
i) Let ECS be the set of <embedded exception declaration>s in E that specify SQLSTATE,
an <SQLSTATE class value>, and an <SQLSTATE subclass value>.
ii) If ECS contains an <embedded exception declaration> EY that specifies an <SQLSTATE

class value> identical to CV and an <SQLSTATE subclass value> identical to SCV,
then a GO TO statement of the host language is performed, specifying the <host label
identifier>, <host PL/I label variable>, or <unsigned integer> of the <go to> specified in
the <embedded exception declaration> EY.
iii) Otherwise:
1) Let EC be the set of <embedded exception declaration>s in E that specify SQLSTATE

and an <SQLSTATE class value> without an <SQLSTATE subclass value>.
Embedded SQL 147

2) If EC contains an <embedded exception declaration> EY that specifies an

<SQLSTATE class value> identical to CV, then a GO TO statement of the host
language is performed, specifying the <host label identifier>, <host PL/I label vari-
able>, or <unsigned integer> of the <go to> specified in the <embedded exception
declaration> EY.
3) Otherwise:
A) Let EX be the set of <embedded exception declaration>s in E that specify

SQLEXCEPTION.
B) If EX contains an <embedded exception declaration> EY and CV belongs to

Category X in Table 10, ‘‘SQLSTATE class and subclass values’’, then a GO
TO statement of the host language is performed, specifying the <host label
identifier>, <host PL/I label variable>, or <unsigned integer> of the <go to>
specified in the <embedded exception declaration> EY.
C) Otherwise:
I) Let EW be the set of <embedded exception declaration>s in E that specify

SQLWARNING.
II) If EW contains an <embedded exception declaration> EY and CV belongs to

Category W in Table 10, ‘‘SQLSTATE class and subclass values’’, then a GO
TO statement of the host language is performed, specifying the <host label
identifier>, <host PL/I label variable>, or <unsigned integer> of the <go to>
specified in the <embedded exception declaration> EY.
III) Otherwise, let ENF be the set of <embedded exception declaration>s in

E that specify NOT FOUND. If ENF contains an <embedded exception
declaration> EY and CV belongs to Category N in Table 10, ‘‘SQLSTATE
class and subclass values’’, then a GO TO statement of the host language is
performed, specifying the <host label identifier>, <host PL/I label variable>,
or <unsigned integer> of the <go to> specified in the <embedded exception
declaration> EY.
Conformance Rules
1) Without Feature B041, ‘‘Extensions to embedded SQL exception declarations’’, an <SQL condi-
tion> shall not specify SQLSTATE or CONSTRAINT.
2) Without Feature B041, ‘‘Extensions to embedded SQL exception declarations’’, a <major cate-
gory> shall not specify SQLEXCEPTION or SQLWARNING.

16.3 <embedded SQL Ada program>
Function
Specify an <embedded SQL Ada program>.
Format
<embedded SQL Ada program> ::= !! See the Syntax Rules.
<Ada variable definition> ::=

<Ada host identifier> [ { <comma> <Ada host identifier> }... ] <colon>
<Ada type specification> [ <Ada initial value> ]
<Ada initial value> ::=

<Ada assignment operator> <character representation>...
<Ada assignment operator> ::= <colon><equals operator>
<Ada host identifier> ::= !! See the Syntax Rules.
<Ada type specification> ::=

<Ada qualified type specification>
| <Ada unqualified type specification>
| <Ada derived type specification>
<Ada qualified type specification> ::=

Interfaces.SQL <period> CHAR [ CHARACTER SET [ IS ] <character set specification> ]
<left paren> 1 <double period> <length> <right paren>

| Interfaces.SQL <period> BIT <left paren> 1 <double period> <length> <right paren>
| Interfaces.SQL <period> SMALLINT

| Interfaces.SQL <period> INT
| Interfaces.SQL <period> REAL
| Interfaces.SQL <period> DOUBLE_PRECISION
| Interfaces.SQL <period> BOOLEAN
| Interfaces.SQL <period> SQLSTATE_TYPE
| Interfaces.SQL <period> INDICATOR_TYPE
<Ada unqualified type specification> ::=

CHAR <left paren> 1 <double period> <length> <right paren>
| BIT <left paren> 1 <double period> <length> <right paren>
| SMALLINT
| INT
| REAL
| DOUBLE_PRECISION
| BOOLEAN
| SQLSTATE_TYPE
| INDICATOR_TYPE
<Ada derived type specification> ::=

<Ada CLOB variable>
| <Ada BLOB variable>
| <Ada user-defined type variable>
| <Ada CLOB locator variable>
| <Ada BLOB locator variable>
| <Ada user-defined type locator variable>
| <Ada array locator variable>
| <Ada REF variable>
Embedded SQL 149

<Ada CLOB variable> ::=

SQL TYPE IS CLOB <left paren> <large object length> <right paren>
[ CHARACTER SET [ IS ] <character set specification> ]
<Ada BLOB variable> ::=

SQL TYPE IS BLOB <left paren> <large object length> <right paren>
<Ada user-defined type variable> ::=

SQL TYPE IS <user-defined type> AS <predefined type>
<Ada CLOB locator variable> ::=

SQL TYPE IS CLOB AS LOCATOR
<Ada BLOB locator variable> ::=

SQL TYPE IS BLOB AS LOCATOR
<Ada user-defined type locator variable> ::=

SQL TYPE IS <user-defined type name> AS LOCATOR
<Ada array locator variable> ::=

SQL TYPE IS <collection type> AS LOCATOR
<Ada REF variable> ::=

SQL TYPE IS <reference type>
Syntax Rules
1) An <embedded SQL Ada program> is a compilation unit that consists of Ada text and SQL text.
The Ada text shall conform to the Ada standard ISO/IEC 8652. The SQL text shall consist of
one or more <embedded SQL statement>s and, optionally, one or more <embedded SQL declare
section>s.
2) An <embedded SQL statement> may be specified wherever an Ada statement may be specified.
An <embedded SQL statement> may be prefixed by an Ada label.
3) An <Ada host identifier> is any valid Ada identifier. An <Ada host identifier> shall be contained
in an <embedded SQL Ada program>.
4) An <Ada variable definition> defines one or more host variables.
5) An <Ada variable definition> shall be modified as follows before it is placed into the program
derived from the <embedded SQL Ada program> (see the Syntax Rules of Subclause 16.1,
‘‘<embedded SQL host program>’’):
a) Any optional CHARACTER SET specification shall be removed from an <Ada qualified type
specification> and <Ada derived type specification>.
b) The <length> specified in a CHAR declaration of any <Ada qualified type specification>
or <Ada derived type specification> that contains a CHARACTER SET specification shall
be replaced by a length equal to the length in octets of PN, where PN is the <Ada host
identifier> specified in the containing <Ada variable definition>.
c) The syntax
SQL TYPE IS CLOB ( L )

and the syntax

SQL TYPE IS BLOB ( L )
for a given <Ada host identifier> HVN shall be replaced by
TYPE HVN IS RECORD

HVN_RESERVED : Interfaces.SQL.INT;
HVN_LENGTH : Interfaces.SQL.INT;
HVN_DATA : Interfaces.SQL.CHAR(1..L);
END RECORD;
in any <Ada CLOB variable> or <Ada BLOB variable>, where L is the numeric value of
<large object length> as specified in Subclause 5.2, "<token> and <separator>", in ISO/IEC
9075-2.
d) The syntax
SQL TYPE IS UDTN AS PDT
shall be replaced by
ADT
in any <Ada user-defined type variable>, where ADT is the data type listed in the ‘‘Ada
data type’’ column corresponding to the row for SQL data type PDT in Table 18, "Data
type correspondences for Ada", in ISO/IEC 9075-2. ADT shall not be ‘‘none’’. The data type
identified by UDTN is called the associated user-defined type of the host variable and the
data type identified by PDT is called the associated SQL data type of the host variable.
e) The syntax
Interfaces.SQL.INT
in any <Ada BLOB locator variable>. The host variable defined by <Ada BLOB locator
variable> is called a binary large object locator variable.
f) The syntax
Interfaces.SQL.INT
in any <Ada CLOB locator variable>. The host variable defined by <Ada CLOB locator
variable> is called a character large object locator variable.
g) The syntax
SQL TYPE IS <user-defined type> AS LOCATOR
Interfaces.SQL.INT
Embedded SQL 151

in any <Ada user-defined type locator variable>. The host variable defined by <Ada user-
defined type locator variable> is called a user-defined type locator variable. The data type
identified by <user-defined type> is called the associated user-defined type of the host vari-
able.
h) The syntax
Interfaces.SQL.INT
in any <Ada array locator variable>. The host variable defined by <Ada array locator
variable> is called an array locator variable. The data type identified by <collection type> is
called the associated array type of the host variable.
i) The syntax
for a given <Ada host identifier> RTV shall be replaced by
RTV : Interfaces.SQL.CHAR(1..<length>)
in any <Ada reference type>, where <length> is the implementation-defined length in octets
of a reference type.
The modified <Ada variable definition> shall be a valid Ada object-declaration in the program
derived from the <embedded SQL Ada program>.
6) The reference type identified by <reference type> contained in an <Ada REF variable> is called
the referenced type of the reference.
7) An <Ada variable definition> shall be specified within the scope of Ada with and use clauses
that specify the following:
with Interfaces.SQL;
use Interfaces.SQL;
use Interfaces.SQL.CHARACTER_SET;
8) The <character representation> sequence in an <Ada initial value> specifies an initial value to
be assigned to the Ada variable. It shall be a valid Ada specification of an initial value.
9) CHAR describes a character string variable whose equivalent SQL data type is CHARACTER
with the same length and character set specified by <character set specification>. If <character
set specification> is not specified, then an implementation-defined <character set specification>
is implicit.
10) BIT describes a bit string variable. The equivalent SQL data type is BIT with the same length.
11) INT and SMALLINT describe exact numeric variables. The equivalent SQL data types are
INTEGER and SMALLINT, respectively.
12) REAL and DOUBLE_PRECISION describe approximate numeric variables. The equivalent SQL
data types are REAL and DOUBLE PRECISION, respectively.
13) BOOLEAN describes a boolean variable. The equivalent SQL data type is BOOLEAN.

14) SQLSTATE_TYPE describes a character string variable whose length is the length of the
SQLSTATE parameter, five characters.
15) INDICATOR_TYPE describes an exact numeric variable whose specific data type is any <exact
numeric type> with a scale of 0 (zero).
Access Rules
None.
General Rules
1) See Subclause 16.1, ‘‘<embedded SQL host program>’’.
Conformance Rules
1) Without Feature B011, ‘‘Embedded Ada’’, <embedded SQL Ada program> shall not be specified.
2) Without Feature F511, ‘‘BIT data type’’, an <Ada variable definition> shall not specify a bit
string variable.
3) Without Feature F451, ‘‘Character set definition’’, or Feature F461, ‘‘Named character sets’’, an
<Ada qualified type specification> shall not contain a <character set specification>.
4) Without Feature S041, ‘‘Basic reference types’’, an <Ada derived type specification> shall not be
an <Ada REF variable>.
5) Without Feature S241, ‘‘Transform functions’’, an <Ada derived type specification> shall not be
an <Ada user-defined type variable>.
6) Without Feature S232, ‘‘Array locators’’, an <Ada derived type specification> shall not be an
<Ada array locator variable>.
7) Without Feature S231, ‘‘Structured type locators’’, the <user-defined type name> simply con-
tained in an <Ada user-defined type locator variable> shall not identify a structured type.
8) Without Feature T041, ‘‘Basic LOB data type support’’, an <Ada BLOB variable>, <Ada CLOB
variable>, <Ada BLOB locator variable>, and <Ada CLOB locator variable> shall not be speci-
fied.
Embedded SQL 153

16.4 <embedded SQL C program>
Function
Specify an <embedded SQL C program>.
Format
<embedded SQL C program> ::= !! See the Syntax Rules.
<C variable definition> ::=

[ <C storage class> ]
[ <C class modifier> ]
<C variable specification>
<semicolon>
<C variable specification> ::=

<C numeric variable>
| <C character variable>
| <C derived variable>
<C storage class> ::=

auto
| extern
| static
<C class modifier> ::=

const
| volatile
<C numeric variable> ::=

{ long | short | float | double }
<C host identifier> [ <C initial value> ]
[ { <comma> <C host identifier> [ <C initial value> ] }... ]
<C character variable> ::=

<C character type> [ CHARACTER SET [ IS ] <character set specification> ]
<C host identifier> <C array specification> [ <C initial value> ]
[ { <comma> <C host identifier> <C array specification>
[ <C initial value> ] }... ]
<C character type> ::=

char
| unsigned char
| unsigned short
<C array specification> ::=

<left bracket> <length> <right bracket>
<C host identifier> ::= !! See the Syntax Rules.
<C derived variable> ::=

<C VARCHAR variable>
| <C NCHAR variable>
| <C NCHAR VARYING variable>
| <C CLOB variable>
| <C NCLOB variable>
| <C BLOB variable>
| <C bit variable>

| <C user-defined type variable>

| <C CLOB locator variable>
| <C BLOB locator variable>
| <C array locator variable>
| <C user-defined type locator variable>
| <C REF variable>
<C VARCHAR variable> ::=

VARCHAR [ CHARACTER SET [ IS ] <character set specification> ]
[ { <comma> <C host identifier> <C array specification> [ <C initial value> ] }... ]
<C NCHAR variable> ::=

NCHAR [ CHARACTER SET [ IS ] <character set specification> ]
[ { <comma> <C host identifier> <C array specification> [ <C initial value> ] } ... ]
<C NCHAR VARYING variable> ::=

NCHAR VARYING [ CHARACTER SET [ IS ] <character set specification> ]
[ { <comma> <C host identifier> <C array specification> [ <C initial value> ] } ... ]
<C CLOB variable> ::=

<C NCLOB variable> ::=

SQL TYPE IS NCLOB <left paren> <large object length> <right paren>
<C bit variable> ::=

BIT <C host identifier> <C array specification> [ <C initial value> ]
[ { <comma> <C host identifier> <C array specification>
[ <C initial value> ] }... ]
<C user-defined type variable> ::=

[ { <comma> <C host identifier> [ <C initial value> ] } ... ]
<C BLOB variable> ::=

<C CLOB locator variable> ::=

<C BLOB locator variable> ::=

Embedded SQL 155

<C array locator variable> ::=

<C user-defined type locator variable> ::=

SQL TYPE IS
<user-defined type> AS LOCATOR
<C REF variable> ::=

<C initial value> ::=

<equals operator> <character representation>...
Syntax Rules
1) An <embedded SQL C program> is a compilation unit that consists of C text and SQL text. The
C text shall conform to the C standard ISO/IEC 9899. The SQL text shall consist of one or more
<embedded SQL statement>s and, optionally, one or more <embedded SQL declare section>s.
2) An <embedded SQL statement> may be specified wherever a C statement may be specified

within a function block. If the C statement could include a label prefix, then the <embedded
SQL statement> may be immediately preceded by a label prefix.
3) A <C host identifier> is any valid C variable identifier. A <C host identifier> shall be contained
in an <embedded SQL C program>.
4) A <C variable definition> defines one or more host variables.
5) The <collection type> contained in a <C array locator variable> shall specify an array data type.
The array data type specified by the <collection type> contained in a <C array locator variable>
is called the associated array data type of the array locator.
6) A <C variable definition> shall be modified as follows before it is placed into the program
derived from the <embedded SQL C program> (see the Syntax Rules of Subclause 16.1, ‘‘<em-
bedded SQL host program>’’):
a) Any optional CHARACTER SET specification shall be removed from a <C VARCHAR vari-
able>, a <C character variable>, a <C CLOB variable>, a <C NCHAR variable>, <C NCHAR
VARYING variable>, or a <C NCLOB variable>.
b) The syntax ‘‘VARCHAR’’ shall be replaced by ‘‘char’’ in any <C VARCHAR variable>.
c) The syntax ‘‘BIT’’ shall be replaced by ‘‘char’’ in any <C bit variable>.
d) The <length> specified in a <C array specification> in any <C bit variable> shall be replaced
by a length equal to the smallest integer not less than L/B, as defined in the Syntax Rules
of this Subclause.
e) The <length> specified in a <C array specification> in any <C character variable> whose
<C character type> specifies ‘‘char’’ or ‘‘unsigned char’’, in any <C VARCHAR variable>, in
any <C NCHAR variable>, or in any <C NCHAR VARYING variable>, and the <large object
length> specified in a <C CLOB variable> that contains a CHARACTER SET specification

or <C NCLOB variable> shall be replaced by a length equal to the length in octets of PN,
where PN is the <C host identifier> specified in the containing <C variable definition>.
NOTE 27 – The <length> does not have to be adjusted for <C character type>s that specify ‘‘un-
signed short’’ because the units of <length> are already the same units as used by the underlying
character set.
f) The syntax ‘‘NCHAR’’ in any <C NCHAR variable> and the syntax ‘‘NCHAR VARYING ’’ in any <C
NCHAR VARYING variable> shall be replaced by ‘‘char’’.
g) The syntax
SQL TYPE IS NCLOB ( L )
for a given <C host identifier> hvn shall be replaced by
struct {
long hvn_reserved;
unsigned long hvn_length;
char hvn_data[L];
} hvn
in any <CNCLOB variable>, where L is the numeric value of <large object length> as
specified in Subclause 5.2, "<token> and <separator>", in ISO/IEC 9075-2.
h) The syntax
or the syntax
for a given <C host identifier> hvn shall be replaced by:
struct {
long hvn_reserved;
unsigned long hvn_length;
char hvn_data[L];
} hvn
in any <C CLOB variable> or <C BLOB variable>, where L is the numeric value of <large
object length> as specified in Subclause 5.2, "<token> and <separator>", in ISO/IEC 9075-2.
i) The syntax
ADT
in any <C user-defined type variable>, where ADT is the data type listed in the ‘‘C data
type’’ column corresponding to the row for SQL data type PDT in Table 19, "Data type cor-
respondences for C", in ISO/IEC 9075-2. ADT shall not be ‘‘none’’. The data type identified
by UDTN is called the associated user-defined type of the host variable and the data type
identified by PDT is called the associated SQL data type of the host variable.
j) The syntax
Embedded SQL 157

unsigned long
in any <C BLOB locator variable>. The host variable defined by <C BLOB locator variable>
is called a binary large object locator variable.
k) The syntax
unsigned long
in any <C CLOB locator variable>. The host variable defined by <C CLOB locator variable>
is called a character large object locator variable.
l) The syntax
unsigned long
in any <C array locator variable>. The host variable defined by <C array locator variable>
is called an array locator variable. The data type identified by <collection type> is called the
associated array type of the host variable.
m) The syntax
unsigned long
in any <C user-defined type locator variable>. The host variable defined by <C user-defined
type locator variable> is called a user-defined type locator variable. The data type identified
by <user-defined type> is called the associated user-defined type of the host variable.
n) The syntax
for a given <C host identifier> hvn shall be replaced by
unsigned char hvn[L]
in any <C REF variable>, where L is the implementation-defined length in octets of a
reference type.
The modified <C variable definition> shall be a valid C data declaration in the program derived
from the <embedded SQL C program>.
7) The reference type identified by <reference type> contained in a <C REF variable> is called the
referenced type of the reference.
8) The <character representation> sequence contained in a <C initial value> specifies an initial
value to be assigned to the C variable. It shall be a valid C specification of an initial value.
9) Except for array specifications for character strings and bit strings, a <C variable definition>
shall specify a scalar type.

10) In a <C variable definition>, the words ‘‘VARCHAR’’, ‘‘CHARACTER’’, ‘‘SET’’, ‘‘IS’’, ‘‘BIT’’,
‘‘VARYING’’, ‘‘BLOB’’, ‘‘CLOB’’, ‘‘NCHAR’’, ‘‘NCLOB’’, ‘‘AS’’, ‘‘LOCATOR’’, and ‘‘REF’’ may be
specified in any combination of upper-case and lower-case letters (see the Syntax Rules of
Subclause 5.2, "<token> and <separator>", in ISO/IEC 9075-2).
11) In a <C character variable>, a <C VARCHAR variable>, or a <C CLOB variable>, if a <char-
acter set specification> is specified, then the equivalent SQL data type is CHARACTER,
CHARACTER VARYING, or CHARACTER LARGE OBJECT whose character repertoire is
the same as the repertoire specified by the <character set specification>. In a <C NCHAR
variable>, a <C NCHAR VARYING variable>, or a <C NCLOB variable>, if a <character set
specification> is specified, then the equivalent SQL data type is NATIONAL CHARACTER,
NATIONAL CHARACTER VARYING, or NATIONAL CHARACTER LARGE OBJECT whose
character repertoire is the same as the repertoire specified by the <character set specification>.
If <character set specification> is not specified, then an implementation-defined <character set
specification> is implicit.
12) Each <C host identifier> specified in a <C character variable> or a <C NCHAR variable>
describes a fixed-length character string. The length is specified by the <length> of the <C
array specification>. The value in the host variable is terminated by a null character and the
position occupied by this null character is included in the length of the host variable. The
equivalent SQL data type is CHARACTER or NATIONAL CHARACTER, respectively, whose
length is one less than the <length> of the <C array specification> and whose value does not
include the terminating null character. The <length> shall be greater than 1 (one).
13) Each <C host identifier> specified in a <C VARCHAR variable> or a <C NCHAR VARYING
variable> describes a variable-length character string. The maximum length is specified by the
<length> of the <C array specification>. The value in the host variable is terminated by a null
character and the position occupied by this null character is included in the maximum length
of the host variable. The equivalent SQL data type is CHARACTER VARYING or NATIONAL
CHARACTER VARYING, respectively, whose maximum length is 1 (one) less than the <length>
of the <C array specification> and whose value does not include the terminating null character.
The <length> shall be greater than 1 (one).
14) Each <C host identifier> specified in a <C bit variable> describes a fixed-length bit string. The
value in the host variable has a BIT_LENGTH of <length>. Let B be the number of bits in a C
char and let L be the <length> of the <C array specification>. The length of an equivalent C
char variable is the smallest integer that is not less than the result of L/B. The equivalent SQL
data type is BIT whose length is L.
15) ‘‘long’’ describes an exact numeric variable. The equivalent SQL data type is INTEGER or
BOOLEAN.
16) ‘‘short’’ describes an exact numeric variable. The equivalent SQL data type is SMALLINT.
17) ‘‘float’’ describes an approximate numeric variable. The equivalent SQL data type is REAL.
18) ‘‘double’’ describes an approximate numeric variable. The equivalent SQL data type is DOUBLE
PRECISION.
Access Rules
None.
Embedded SQL 159

General Rules
Conformance Rules
1) Without Feature B012, ‘‘Embedded C’’, <embedded SQL C program> shall not be specified.
2) Without Feature F511, ‘‘BIT data type’’, a <C derived variable> shall not be a <C bit variable>.
3) Without Feature F451, ‘‘Character set definition’’, or Feature F461, ‘‘Named character sets’’, a
<C variable definition> shall not contain a <character set specification>.
4) Without Feature S041, ‘‘Basic reference types’’, a <C derived variable> shall not be a <C REF
variable>.
5) Without Feature S241, ‘‘Transform functions’’, a <C derived type specification> shall not be a <C
user-defined type variable>.
6) Without Feature S232, ‘‘Array locators’’, a <C derived variable> shall not be a <C array locator
variable>.
tained in a <C user-defined type locator variable> shall not identify a structured type.
8) Without Feature T041, ‘‘Basic LOB data type support’’, a <C BLOB variable>, <C CLOB vari-
able>, <C BLOB locator variable>, and <C CLOB locator variable> shall not be specified.

16.5 <embedded SQL COBOL program>
Function
Specify an <embedded SQL COBOL program>.
Format
<embedded SQL COBOL program> ::= !! See the Syntax Rules.
<COBOL variable definition> ::=

{01|77} <COBOL host identifier> <COBOL type specification>
[ <character representation>... ] <period>
<COBOL host identifier> ::= !! See the Syntax Rules.
<COBOL type specification> ::=

<COBOL character type>
| <COBOL national character type>
| <COBOL bit type>
| <COBOL numeric type>
| <COBOL integer type>
| <COBOL derived type specification>
<COBOL derived type specification> ::=

<COBOL CLOB variable>
| <COBOL NCLOB variable>
| <COBOL BLOB variable>
| <COBOL user-defined type variable>
| <COBOL CLOB locator variable>
| <COBOL BLOB locator variable>
| <COBOL array locator variable>
| <COBOL user-defined type locator variable>
| <COBOL REF variable>
<COBOL character type> ::=

{ PIC | PICTURE } [ IS ] { X [ <left paren> <length> <right paren> ] }...
<COBOL national character type> ::=

{ PIC | PICTURE } [ IS ] { N [ <left paren> <length> <right paren> ] }...
<COBOL CLOB variable> ::=

[ USAGE [ IS ] ]
<COBOL NCLOB variable> ::=

[ USAGE [ IS ] ]
SQL TYPE IS NCLOB <left paren> <large object length> <right paren>
<COBOL bit type> ::=

{ PIC | PICTURE } [ IS ] { X [ <left paren> <length> <right paren> ] }...
USAGE [ IS ] BIT
<COBOL BLOB variable> ::=

[ USAGE [ IS ] ]
Embedded SQL 161

<COBOL user-defined type variable> ::=

[ USAGE [ IS ] ]
<COBOL CLOB locator variable> ::=

[ USAGE [ IS ] ]
<COBOL BLOB locator variable> ::=

[ USAGE [ IS ] ]
<COBOL array locator variable> ::=

[ USAGE [ IS ] ]
<COBOL user-defined type locator variable> ::=

[ USAGE [ IS ] ]
<COBOL REF variable> ::=

[ USAGE [ IS ] ]
<COBOL numeric type> ::=

{ PIC | PICTURE } [ IS ]
S <COBOL nines specification>
[ USAGE [ IS ] ] DISPLAY SIGN LEADING SEPARATE
<COBOL nines specification> ::=

<COBOL nines> [ V [ <COBOL nines> ] ]
| V <COBOL nines>
<COBOL integer type> ::=

<COBOL binary integer>
<COBOL binary integer> ::=

{ PIC | PICTURE } [ IS ] S<COBOL nines>
[ USAGE [ IS ] ] BINARY
<COBOL nines> ::= { 9 [ <left paren> <length> <right paren> ] }...
NOTE 28 – The syntax ‘‘N(L)’’ is not part of the current COBOL standard, so its use is merely a recom-
mendation; therefore, the production <COBOL national character type> is not normative in ISO/IEC 9075.
Syntax Rules
1) An <embedded SQL COBOL program> is a compilation unit that consists of COBOL text
and SQL text. The COBOL text shall conform to the COBOL standard ISO 1989. The SQL
text shall consist of one or more <embedded SQL statement>s and, optionally, one or more
<embedded SQL declare section>s.

2) An <embedded SQL statement> in an <embedded SQL COBOL program> may be specified

wherever a COBOL statement may be specified in the Procedure Division of the <embedded SQL
COBOL program>. If the COBOL statement could be immediately preceded by a paragraph-
name, then the <embedded SQL statement> may be immediately preceded by a paragraph-
name.
3) A <COBOL host identifier> is any valid COBOL data-name. A <COBOL host identifier> shall
be contained in an <embedded SQL COBOL program>.
4) A <COBOL variable definition> is a restricted form of COBOL data description entry that
defines a host variable.
5) The <collection type> contained in a <COBOL array locator variable> shall specify an array
data type. The array data type specified by the <collection type> contained in a <COBOL array
locator variable> is called the associated array data type of the array locator.
6) A <COBOL variable definition> shall be modified as follows before it is placed into the program
derived from the <embedded SQL COBOL program> (see the Syntax Rules of Subclause 16.1,
‘‘<embedded SQL host program>’’).
a) Any optional CHARACTER SET specification shall be removed from a <COBOL character
type>, a <COBOL national character type>, a <COBOL CLOB variable>, and a <COBOL
NCLOB variable>.
b) The syntax
USAGE IS BIT
shall be deleted.
c) The <length> specified in any <COBOL bit type> shall be replaced by a length equal to the
smallest integer not less than L/B, as defined in the Syntax Rules of this Subclause.
d) The <length> specified in any <COBOL character type> and the <large object length>
specified in any <COBOL CLOB variable> or <COBOL NCLOB variable> that contains a
CHARACTER SET specification shall be replaced by a length equal to the length in octets of
PN, where PN is the <COBOL host identifier> specified in the containing <COBOL variable
definition>.
NOTE 29 – The <length> specified in a <COBOL national character type> does not have to be
adjusted, because the units of <length> are already the same units as used by the underlying
character set.
NOTE 30 – The syntax ‘‘N(L)’’ is not part of the current COBOL standard, so its use is merely a
recommendation; therefore, the production <COBOL national character type> is not normative in
ISO/IEC 9075.
e) The syntax
or the syntax
SQL TYPE IS NCLOB ( L )
or the syntax
Embedded SQL 163

for a given <COBOL host identifier> HVN shall be replaced by:
49 HVN-RESERVED PIC S9(9) USAGE IS BINARY.

49 HVN-LENGTH PIC S9(9) USAGE IS BINARY.
49 HVN-DATA PIC X(L).
in any <COBOL CLOB variable> or <COBOL BLOB variable>.
f) The syntax
ADT
in any <COBOL user-defined type variable>, where ADT is the data type listed in the
‘‘COBOL data type’’ column corresponding to the row for SQL data type PDT in Table 20,
"Data type correspondences for COBOL", in ISO/IEC 9075-2. ADT shall not be ‘‘none’’. The
data type identified by UDTN is called the associated user-defined type of the host variable
and the data type identified by PDT is called the associated SQL data type of the host
variable.
g) The syntax
PIC S9(9) USAGE IS BINARY
in any <COBOL BLOB locator variable>. The host variable defined by <COBOL BLOB
locator variable> is called a binary large object locator variable.
h) The syntax
in any <COBOL CLOB locator variable>. The host variable defined by <COBOL CLOB
locator variable> is called a character large object locator variable.
i) The syntax
in any <COBOL array locator variable>. The host variable defined by <COBOL array
locator variable> is called an array locator variable. The data type identified by <collection
type> is called the associated array type of the host variable.
j) The syntax

in any <COBOL user-defined type locator variable>. The host variable defined by <COBOL
user-defined type locator variable> is called a user-defined type locator variable. The data
type identified by <user-defined type> is called the associated user-defined type of the host
variable.
k) The syntax
for a given <COBOL host identifier> HVN shall be replaced by
01 HVN PICTURE X(L)
in any <COBOL REF variable>, where L is the implementation-defined length in octets of a
reference type.
The modified <COBOL variable definition> shall be a valid data description entry in the Data
Division of the program derived from the <embedded SQL COBOL program>.
7) The reference type identified by <reference type> contained in a <COBOL REF variable> is
called the referenced type of the reference.
8) The optional <character representation> sequence in a <COBOL variable definition> may

specify a VALUE clause. Whether other clauses may be specified is implementation-defined.
The <character representation> sequence shall be such that the <COBOL variable definition> is
a valid COBOL data description entry.
9) A <COBOL character type> describes a character string variable whose equivalent SQL data
type is CHARACTER with the same length and character set specified by <character set spec-
ification>. If <character set specification> is not specified, then an implementation-defined
<character set specification> is implicit.
10) A <COBOL bit type> describes a bit string variable. Let B be the number of bits in a COBOL
character and let L be the <length> of the <COBOL bit type>. The length of an equivalent
COBOL character variable is the smallest integer not less than L/B. The equivalent SQL data
type is BIT whose length is the <length> of the <COBOL bit type>. If the length of the <COBOL
bit type> is 1 (one), then the equivalent SQL data type may be BOOLEAN.
11) A <COBOL numeric type> describes an exact numeric variable. The equivalent SQL data type
is NUMERIC of the same precision and scale.
12) A <COBOL binary integer> describes an exact numeric variable. The equivalent SQL data type
is SMALLINT or INTEGER.
Access Rules
None.
General Rules
Embedded SQL 165

Conformance Rules
1) Without Feature B013, ‘‘Embedded COBOL’’, <embedded SQL COBOL program> shall not be
specified.
2) Without Feature F511, ‘‘BIT data type’’, a <COBOL type specification> shall not be a <COBOL
bit type>.
<COBOL character type> shall not contain a <character set specification>.
4) Without Feature S041, ‘‘Basic reference types’’, a <COBOL type specification> shall not be a
<COBOL REF variable>.
5) Without Feature S241, ‘‘Transform functions’’, a <COBOL derived type specification> shall not
be a <COBOL user-defined type variable>.
6) Without Feature S232, ‘‘Array locators’’, a <COBOL derived type specification> shall not be a
<COBOL array locator variable>.
tained in a <COBOL user-defined type locator variable> shall not identify a structured type.
8) Without Feature T041, ‘‘Basic LOB data type support’’, a <COBOL BLOB variable>, <COBOL
CLOB variable>, <COBOL BLOB locator variable>, and <COBOL CLOB locator variable> shall
not be specified.

16.6 <embedded SQL Fortran program>
Function
Specify an <embedded SQL Fortran program>.
Format
<embedded SQL Fortran program> ::= !! See the Syntax Rules.
<Fortran variable definition> ::=

<Fortran type specification>
<Fortran host identifier> [ { <comma> <Fortran host identifier> }... ]
<Fortran host identifier> ::= !! See the Syntax Rules.
<Fortran type specification> ::=

CHARACTER [ <asterisk> <length> ]
| CHARACTER KIND = n [ <asterisk> <length> ]
| BIT [ <asterisk> <length> ]
| INTEGER
| REAL
| DOUBLE PRECISION
| LOGICAL
| <Fortran derived type specification>
<Fortran derived type specification> ::=

<Fortran CLOB variable>
| <Fortran BLOB variable>
| <Fortran user-defined type variable>
| <Fortran CLOB locator variable>
| <Fortran BLOB locator variable>
| <Fortran user-defined type locator variable>
| <Fortran array locator variable>
| <Fortran REF variable>
<Fortran CLOB variable> ::=

<Fortran BLOB variable> ::=

<Fortran user-defined type variable> ::=

<Fortran CLOB locator variable> ::=

<Fortran BLOB locator variable> ::=

<Fortran user-defined type locator variable> ::=

<Fortran array locator variable> ::=

Embedded SQL 167

<Fortran REF variable> ::=

Syntax Rules
1) An <embedded SQL Fortran program> is a compilation unit that consists of Fortran text and
SQL text. The Fortran text shall conform to the Fortran standard ISO 1539. The SQL text shall
consist of one or more <embedded SQL statement>s and, optionally, one or more <embedded
SQL declare section>s.
2) An <embedded SQL statement> may be specified wherever an executable Fortran statement

may be specified. An <embedded SQL statement> that precedes any executable Fortran state-
ment in the containing <embedded SQL Fortran program> shall not have a Fortran statement
number. Otherwise, if the Fortran statement could have a statement number then the <embed-
ded SQL statement> can have a statement number.
3) Blanks are significant in <embedded SQL statement>s. The rules for <separator>s in an
<embedded SQL statement> are as specified in Subclause 5.2, "<token> and <separator>",
in ISO/IEC 9075-2.
4) A <Fortran host identifier> is any valid Fortran variable name with all <space> characters re-
moved. A <Fortran host identifier> shall be contained in an <embedded SQL Fortran program>.
5) A <Fortran variable definition> is a restricted form of Fortran type-statement that defines one
or more host variables.
6) A <Fortran variable definition> shall be modified as follows before it is placed into the program
derived from the <embedded SQL Fortran program> (see the Syntax Rules Subclause 16.1,
a) Any optional CHARACTER SET specification shall be removed from the CHARACTER and
the CHARACTER KIND=n alternatives in a <Fortran type specification>.
b) The <length> specified in the CHARACTER alternative of any <Fortran type specification>
and the <large object length> specified in any <Fortran CLOB variable> that contains a
CHARACTER SET specification shall be replaced by a length equal to the length in octets of
PN, where PN is the <Fortran host identifier> specified in the containing <Fortran variable
definition>.
NOTE 31 – The <length> does not have to be adjusted for CHARACTER KIND=n alternatives of
any <Fortran type specification>, because the units of <length> are already the same units as used
by the underlying character set.
c) The syntax ‘‘BIT’’ shall be replaced by ‘‘CHARACTER’’ in any BIT alternative of a <Fortran
type specification>.
d) The <length> specified in any BIT alternative of a <Fortran type specification> shall be
replaced by a length equal to the smallest integer not less than L/B, as defined in the
Syntax Rules of this Subclause.
e) The syntax

and the syntax

for a given <Fortran host identifier> HVN shall be replaced by
INTEGER HVN_RESERVED
INTEGER HVN_LENGTH
CHARACTER HVN_DATA [ <asterisk> L ]
in any <Fortran CLOB variable> or <Fortran BLOB variable>, where L is the numeric
value of <large object length> as specified in Subclause 5.2, "<token> and <separator>", of
ISO/IEC 9075-2.
f) The syntax
ADT
in any <Fortran user-defined type variable>, where ADT is the data type listed in the
‘‘Fortran data type’’ column corresponding to the row for SQL data type PDT in Table 21,
"Data type correspondences for Fortran", in ISO/IEC 9075-2. ADT shall not be ‘‘none’’. The
variable.
g) The syntax
INTEGER
in any <Fortran BLOB locator variable>. The host variable defined by <Fortran BLOB
h) The syntax
INTEGER
in any <Fortran CLOB locator variable>. The host variable defined by <Fortran CLOB
i) The syntax
INTEGER
in any <Fortran user-defined type locator variable>. The host variable defined by <Fortran
variable.
Embedded SQL 169

j) The syntax
INTEGER
in any <Fortran array locator variable>. The host variable defined by <Fortran array locator
k) The syntax
for a given <Fortran host identifier> HVN shall be replaced by
CHARACTER HVN * <length>
in any <Fortran reference type>, where <length> is the implementation-defined in octets of
a reference type.
The modified <Fortran variable definition> shall be a valid Fortran type-statement in the
program derived from the <embedded SQL Fortran program>.
7) The reference type identified by <reference type> contained in an <Fortran REF variable> is
8) CHARACTER without ‘‘KIND=n’’ describes a character string variable whose equivalent SQL
data type is CHARACTER with the same length and character set specified by <character set
specification>. If <character set specification> is not specified, then an implementation-defined
<character set specification> is implicit.
9) CHARACTER KIND=n describes a character string variable whose equivalent SQL data type
is either CHARACTER or NATIONAL CHARACTER with the same length and character set
specified by <character set specification>. If <character set specification> is not specified, then
an implementation-defined <character set specification> is implicit. The value of n determines
implementation-defined characteristics of the Fortran variable; values of n are implementation-
defined.
10) BIT describes a bit string variable. Let B be the number of bits in a Fortran character and
let L be the <length> of the bit string variable. The length of an equivalent Fortran character
variable is the smallest integer not less than L/B. The equivalent SQL data type is BIT whose
length is the <length> of the bit string variable.
11) INTEGER describes an exact numeric variable. The equivalent SQL data type is INTEGER.
12) REAL describes an approximate numeric variable. The equivalent SQL data type is REAL.
13) DOUBLE PRECISION describes an approximate numeric variable. The equivalent SQL data
type is DOUBLE PRECISION.
14) LOGICAL describes a boolean variable. The equivalent SQL data type is BOOLEAN.
Access Rules
None.

General Rules
Conformance Rules
1) Without Feature B014, ‘‘Embedded Fortran’’, <embedded SQL Fortran program> shall not be
specified.
2) Without Feature F511, ‘‘BIT data type’’, a <Fortran type specification> shall not specify BIT.
<Fortran type specification> shall not contain a <character set specification>.
4) Without Feature S041, ‘‘Basic reference types’’, a <Fortran derived type specification> shall not
be a <Fortran REF variable>.
5) Without Feature S241, ‘‘Transform functions’’, a <Fortran derived type specification> shall not
be a <Fortran user-defined type variable>.
6) Without Feature S232, ‘‘Array locators’’, a <Fortran derived type specification> shall not be a
<Fortran array locator variable>.
tained in a <Fortran user-defined type locator variable> shall not identify a structured type.
8) Without Feature T041, ‘‘Basic LOB data type support’’, a <Fortran BLOB variable>, <Fortran
CLOB variable>, <Fortran BLOB locator variable>, and <Fortran CLOB locator variable> shall
not be specified.
Embedded SQL 171

16.7 <embedded SQL MUMPS program>
Function
Specify an <embedded SQL MUMPS program>.
Format
<embedded SQL MUMPS program> ::= !! See the Syntax Rules.
<MUMPS variable definition> ::=

<MUMPS numeric variable> <semicolon>
| <MUMPS character variable> <semicolon>
| <MUMPS derived type specification> <semicolon>
<MUMPS character variable> ::=

VARCHAR <MUMPS host identifier> <MUMPS length specification>
[ { <comma> <MUMPS host identifier> <MUMPS length specification> }... ]
<MUMPS host identifier> ::= !! See the Syntax Rules.
<MUMPS length specification> ::=

<left paren> <length> <right paren>
<MUMPS numeric variable> ::=

<MUMPS type specification>
<MUMPS host identifier> [ { <comma> <MUMPS host identifier> }... ]
<MUMPS type specification> ::=

INT
| DEC [ <left paren> <precision> [ <comma> <scale> ] <right paren> ]
| REAL
<MUMPS derived type specification> ::=

<MUMPS CLOB variable>
| <MUMPS BLOB variable>
| <MUMPS user-defined type variable>
| <MUMPS CLOB locator variable>
| <MUMPS BLOB locator variable>
| <MUMPS user-defined type locator variable>
| <MUMPS array locator variable>
| <MUMPS REF variable>
<MUMPS CLOB variable> ::=

<MUMPS BLOB variable> ::=

<MUMPS user-defined type variable> ::=

<MUMPS CLOB locator variable> ::=

<MUMPS BLOB locator variable> ::=

<MUMPS user-defined type locator variable> ::=

<MUMPS array locator variable> ::=

<MUMPS REF variable> ::=

Syntax Rules
1) An <embedded SQL MUMPS program> is a compilation unit that consists of MUMPS text and
SQL text. The MUMPS text shall conform to the MUMPS standard ISO/IEC 11756. The SQL
text shall consist of one or more <embedded SQL statement>s and, optionally, one or more
<embedded SQL declare section>s.
2) A <MUMPS host identifier> is any valid MUMPS variable name. A <MUMPS host identifier>
shall be contained in an <embedded SQL MUMPS program>.
3) An <embedded SQL statement> may be specified wherever a MUMPS command may be speci-
fied.
4) A <MUMPS variable definition> defines one or more host variables.
5) The <MUMPS character variable> describes a variable-length character string. The equivalent
SQL data type is CHARACTER VARYING whose maximum length is the <length> of the
<MUMPS length specification> and whose character set is implementation-defined.
6) INT describes an exact numeric variable. The equivalent SQL data type is INTEGER.
7) DEC describes an exact numeric variable. The <scale> shall not be greater than the <preci-
sion>. The equivalent SQL data type is DECIMAL with the same <precision> and <scale>.
9) A <MUMPS derived type specification> shall be modified as follows before it is placed into
the program derived from the <embedded SQL MUMPS program> (see the Syntax Rules of
Subclause 16.1, ‘‘<embedded SQL host program>’’).
a) Any optional CHARACTER SET specification shall be removed from a <MUMPS CLOB
variable>.
b) The syntax
and the syntax
Embedded SQL 173

for a given <MUMPS host identifier> HVN shall be replaced by
INT HVN_RESERVED
INT HVN_LENGTH
VARCHAR HVN_DATA L
in any <MUMPS CLOB variable> or <MUMPS BLOB variable>, where L is the numeric
value of <large object length> as specified in Subclause 5.2, "<token> and <separator>", of
ISO/IEC 9075-2.
c) The syntax
ADT
in any <MUMPS user-defined type variable>, where ADT is the data type listed in the
‘‘MUMPS data type’’ column corresponding to the row for SQL data type PDT in Table 22,
"Data type correspondences for MUMPS", in ISO/IEC 9075-2. ADT shall not be ‘‘none’’. The
variable.
d) The syntax
INT
in any or <MUMPS BLOB locator variable>. The host variable defined by <MUMPS BLOB
e) The syntax
INT
in any <MUMPS CLOB locator variable>. The host variable defined by <MUMPS CLOB
f) The syntax
INT
in any <MUMPS user-defined type locator variable>. The host variable defined by <MUMPS
variable.

g) The syntax
INT
in any <MUMPS array locator variable>. The host variable defined by <MUMPS array
locator variable> is called an array locator variable. The data type identified by <collection
type> is called the associated array type of the host variable.
h) The syntax
for a given <MUMPS host identifier> HVN shall be replaced by
VARCHAR HVN L
in any <MUMPS reference type>, where L is the implementation-defined length in octets of
a reference type.
The modified <MUMPS variable definition> shall be a valid MUMPS variable in the program
derived from the <embedded SQL MUMPS program>.
10) The reference type identified by <reference type> contained in an <MUMPS REF variable> is
Access Rules
None.
General Rules
Conformance Rules
1) Without Feature B015, ‘‘Embedded MUMPS’’, <embedded SQL MUMPS program> shall not be
specified.
2) Without Feature S041, ‘‘Basic reference types’’, a <MUMPS derived type specification> shall not
be a <MUMPS REF variable>.
3) Without Feature S241, ‘‘Transform functions’’, a <MUMPS derived type specification> shall not
be a <MUMPS user-defined type variable>.
4) Without Feature S232, ‘‘Array locators’’, a <MUMPS derived type specification> shall not be a
<MUMPS array locator variable>.
tained in a <MUMPS user-defined type locator variable> shall not identify a structured type.
6) Without Feature T041, ‘‘Basic LOB data type support’’, a <MUMPS BLOB variable>, <MUMPS
CLOB variable>, <MUMPS BLOB locator variable>, and <MUMPS CLOB locator variable>
shall not be specified.
Embedded SQL 175

16.8 <embedded SQL Pascal program>
Function
Specify an <embedded SQL Pascal program>.
Format
<embedded SQL Pascal program> ::= !! See the Syntax Rules.
<Pascal variable definition> ::=

<Pascal host identifier> [ { <comma> <Pascal host identifier> }... ] <colon>
<Pascal type specification> <semicolon>
<Pascal host identifier> ::= !! See the Syntax Rules.
<Pascal type specification> ::=

PACKED ARRAY <left bracket> 1 <double period> <length> <right bracket>
OF CHAR
| PACKED ARRAY <left bracket> 1 <double period> <length> <right bracket>
OF BIT
| INTEGER
| REAL
| CHAR [ CHARACTER SET [ IS ] <character set specification> ]
| BIT
| BOOLEAN
| <Pascal derived type specification>
<Pascal derived type specification> ::=

<Pascal CLOB variable>
| <Pascal BLOB variable>
| <Pascal user-defined type variable>
| <Pascal CLOB locator variable>
| <Pascal BLOB locator variable>
| <Pascal user-defined type locator variable>
| <Pascal array locator variable>
| <Pascal REF variable>
<Pascal CLOB variable> ::=

<Pascal BLOB variable> ::=

<Pascal CLOB locator variable> ::=

<Pascal user-defined type variable> ::=

<Pascal BLOB locator variable> ::=

<Pascal user-defined type locator variable> ::=

<Pascal array locator variable> ::=

<Pascal REF variable> ::=

Syntax Rules
1) An <embedded SQL Pascal program> is a compilation unit that consists of Pascal text and SQL
text. The Pascal text shall conform to one of the Pascal standards ISO/IEC 7185 and ISO/IEC
10206. The SQL text shall consist of one or more <embedded SQL statement>s and, optionally,
one or more <embedded SQL declare section>s.
2) An <embedded SQL statement> may be specified wherever a Pascal statement may be specified.
An <embedded SQL statement> may be prefixed by a Pascal label.
3) A <Pascal host identifier> is a Pascal variable-identifier whose applied instance denotes a defin-
ing instance within an <embedded SQL begin declare> and an <embedded SQL end declare>.
4) A <Pascal variable definition> defines one or more <Pascal host identifier>s.
5) A <Pascal variable definition> shall be modified as follows before it is placed into the program
derived from the <embedded SQL Pascal program> (see the Syntax Rules of Subclause 16.1,
a) Any optional CHARACTER SET specification shall be removed from the PACKED ARRAY
OF CHAR or CHAR alternatives of a <Pascal type specification> and a <Pascal CLOB
variable>.
b) The <length> specified in the PACKED ARRAY OF CHAR alternative of any <Pascal type
specification> that contains a CHARACTER SET specification and the <large object length>
specified in a <Pascal CLOB variable> that contains a CHARACTER SET specification shall
be replaced by a length equal to the length in octets of PN, where PN is the <Pascal host
identifier> specified in the containing <Pascal variable definition>.
c) If any <Pascal type specification> specifies the syntax ‘‘CHAR’’ and contains a CHARACTER
SET specification, then let L be a length equal to the length in octets of PN and PN be
the <Pascal host identifier> specified in the containing <Pascal variable definition>. If L is
greater than 1 (one), then ‘‘CHAR’’ shall be replaced by ‘‘PACKED ARRAY [1..L] OF CHAR’’.
d) The syntax ‘‘BIT’’ shall be replaced by ‘‘CHAR’’ in any PACKED ARRAY OF BIT or BIT
alternatives of a <Pascal type specification>.
e) The <length> specified in any PACKED ARRAY OF BIT alternative in a <Pascal type
specification> shall be replaced by a length equal to the smallest integer not less than L/B,
as defined in the Syntax Rules of this Subclause.
f) The syntax
and the syntax
Embedded SQL 177

for a given <Pascal host identifier> HVN shall be replaced by
VAR HVN = RECORD

HVN_RESERVED : INTEGER;
HVN_LENGTH : INTEGER;
HVN_DATA : PACKED ARRAY [ 1..L ] OF CHAR;
END;
in any <Pascal CLOB variable> or <Pascal BLOB variable>, where L is the numeric value of
<large object length> as specified in Subclause 5.2, "<token> and <separator>", of ISO/IEC
9075-2.
g) The syntax
ADT
in any <Pascal user-defined type variable>, where ADT is the data type listed in the ‘‘Pascal
data type’’ column corresponding to the row for SQL data type PDT in Table 23, "Data type
correspondences for Pascal", in ISO/IEC 9075-2. ADT shall not be ‘‘none’’. The data type
h) The syntax
INTEGER
in any <Pascal BLOB locator variable>. The host variable defined by <Pascal BLOB locator
i) The syntax
INTEGER
in any <Pascal CLOB locator variable>. The host variable defined by <Pascal CLOB locator
j) The syntax
INTEGER
in any <Pascal user-defined type locator variable>. The host variable defined by <Pascal
variable.

k) The syntax
INTEGER
in any <Pascal array locator variable>. The host variable defined by <Pascal array locator
l) The syntax
for a given <Pascal host identifier> HVN shall be replaced by
HVN : PACKED ARRAY [1..<length>] OF CHAR
in any <Pascal reference type>, where <length> is the implementation-defined length in
octets of a reference type.
The modified <Pascal variable definition> shall be a valid Pascal variable-declaration in the
program derived from the <embedded SQL Pascal program>.
6) The reference type identified by <reference type> contained in an <Pascal REF variable> is
7) CHAR specified without a CHARACTER SET specification is the ordinal-type-identifier of

PASCAL. The equivalent SQL data type is CHARACTER with length 1 (one).
8) BIT describes a single-bit variable. It is mapped to a Pascal CHAR ordinal-type-identifier whose

most significant bit contains either 0 (zero) or 1 (one) and whose least significant bits contain 0
(zero). The equivalent SQL data type is BIT with length 1 (one).
9) PACKED ARRAY [1..<length>] OF CHAR describes a character string having 2 or more compo-
nents of the simple type CHAR. The equivalent SQL data type is CHARACTER with the same
length and character set specified by <character set specification>. If <character set specifica-
tion> is not specified, then an implementation-defined <character set specification> is implicit.
10) PACKED ARRAY [1..<length>] OF BIT describes a bit string variable. Let B be the number of
bits in a Pascal CHAR and let L be the <length> of the bit string variable. The length of an
equivalent Pascal character variable is the smallest integer not less than L/B. The equivalent
SQL data type is BIT whose length is the <length> of the bit string variable.
11) INTEGER describes an exact numeric variable. The equivalent SQL data type is INTEGER.
13) BOOLEAN describes a boolean variable. The equivalent SQL data type is BOOLEAN.
Access Rules
None.
Embedded SQL 179

General Rules
Conformance Rules
1) Without Feature B016, ‘‘Embedded Pascal’’, <embedded SQL Pascal program> shall not be
specified.
2) Without Feature F511, ‘‘BIT data type’’, a <Pascal type specification> shall not specify BIT or
PACKED ARRAY [1..<length>] OF BIT.
<Pascal type specification> shall not contain a <character set specification>.
4) Without Feature S041, ‘‘Basic reference types’’, a <Pascal derived type specification> shall not
be a <Pascal REF variable>.
5) Without Feature S241, ‘‘Transform functions’’, a <Pascal derived type specification> shall not be
a <Pascal user-defined type variable>.
6) Without Feature S232, ‘‘Array locators’’, a <Pascal derived type specification> shall not be a
<Pascal array locator variable>.
tained in a <Pascal user-defined type locator variable> shall not identify a structured type.
8) Without Feature T041, ‘‘Basic LOB data type support’’, a <Pascal BLOB variable>, <Pascal
CLOB variable>, <Pascal BLOB locator variable>, and <Pascal CLOB locator variable> shall
not be specified.

16.9 <embedded SQL PL/I program>
Function
Specify an <embedded SQL PL/I program>.
Format
<embedded SQL PL/I program> ::= !! See the Syntax Rules.
<PL/I variable definition> ::=

{DCL | DECLARE}
{ <PL/I host identifier>
| <left paren> <PL/I host identifier>
[ { <comma> <PL/I host identifier> }... ] <right paren> }
<PL/I type specification>
[ <character representation>... ] <semicolon>
<PL/I host identifier> ::= !! See the Syntax Rules.
<PL/I type specification> ::=

{ CHAR | CHARACTER } [ VARYING ] <left paren><length><right paren>
| BIT [ VARYING ] <left paren><length><right paren>
| <PL/I type fixed decimal> <left paren> <precision>
[ <comma> <scale> ] <right paren>
| <PL/I type fixed binary> [ <left paren> <precision> <right paren> ]
| <PL/I type float binary> <left paren> <precision> <right paren>
| <PL/I derived type specification>
<PL/I derived type specification> ::=

<PL/I CLOB variable>
| <PL/I BLOB variable>
| <PL/I user-defined type variable>
| <PL/I CLOB locator variable>
| <PL/I BLOB locator variable>
| <PL/I user-defined type locator variable>
| <PL/I array locator variable>
| <PL/I REF variable>
<PL/I CLOB variable> ::=

<PL/I BLOB variable> ::=

<PL/I user-defined type variable> ::=

<PL/I CLOB locator variable> ::=

<PL/I BLOB locator variable> ::=

<PL/I user-defined type locator variable> ::=

Embedded SQL 181

<PL/I array locator variable> ::=

<PL/I REF variable> ::=

<PL/I type fixed decimal> ::=

{ DEC | DECIMAL } FIXED
| FIXED { DEC | DECIMAL }
<PL/I type fixed binary> ::=

{ BIN | BINARY } FIXED
| FIXED { BIN | BINARY }
<PL/I type float binary> ::=

{ BIN | BINARY } FLOAT
| FLOAT { BIN | BINARY }
Syntax Rules
1) An <embedded SQL PL/I program> is a compilation unit that consists of PL/I text and SQL
text. The PL/I text shall conform to the PL/I standard ISO 6160. The SQL text shall consist of
one or more <embedded SQL statement>s and, optionally, one or more <embedded SQL declare
section>s.
2) An <embedded SQL statement> may be specified wherever a PL/I statement may be specified
within a procedure block. If the PL/I statement could include a label prefix, the <embedded SQL
statement> may be immediately preceded by a label prefix.
3) A <PL/I host identifier> is any valid PL/I variable identifier. A <PL/I host identifier> shall be
contained in an <embedded SQL PL/I program>.
4) A <PL/I variable definition> defines one or more host variables.
5) A <PL/I variable definition> shall be modified as follows before it is placed into the program
derived from the <embedded SQL PL/I program> (see the Syntax Rules of Subclause 16.1,
a) Any optional CHARACTER SET specification shall be removed from the CHARACTER or
CHARACTER VARYING alternatives of a <PL/I type specification>.
b) The <length> specified in the CHARACTER or CHARACTER VARYING alternatives of any

<PL/I type specification> or a <PL/I CLOB variable> that contains a CHARACTER SET
specification shall be replaced by a length equal to the length in octets of PN, where PN is
the <PL/I host identifier> specified in the containing <PL/I variable definition>.
c) The syntax
and the syntax

for a given <PL/I host identifier> HVN shall be replaced by
DCL 1 HVN
2 HVN_RESERVED FIXED BINARY(31),
2 HVN_LENGTH FIXED BINARY(31),
2 HVN_DATA CHARACTER(<length>);
in any <PL/I CLOB variable> or <PL/I BLOB variable>, where L is the numeric value of
<large object length> as specified in Subclause 5.2, "<token> and <separator>", of ISO/IEC
9075-2.
d) The syntax
ADT
in any <PL/I user-defined type variable>, where ADT is the data type listed in the ‘‘PL/I
data type’’ column corresponding to the row for SQL data type PDT in Table 24, "Data type
correspondences for PL/I", in ISO/IEC 9075-2. ADT shall not be ‘‘none’’. The data type
e) The syntax
FIXED BINARY(31)
in any <PL/I BLOB locator variable>. The host variable defined by <PL/I BLOB locator
f) The syntax
FIXED BINARY(31)
in any <PL/I CLOB locator variable>. The host variable defined by <PL/I CLOB locator
g) The syntax
FIXED BINARY(31)
in any <PL/I user-defined type locator variable>. The host variable defined by <PL/I user-
defined type locator variable> is called a user-defined type locator variable. The data type
identified by <user-defined type> is called the associated user-defined type of the host vari-
able.
h) The syntax
Embedded SQL 183

FIXED BINARY(31)
in any <PL/I array locator variable>. The host variable defined by <PL/I array locator
i) The syntax
for a given <PL/I host identifier> HVN shall be replaced by
DCL HVN CHARACTER(<length>) VARYING
in any <PL/I reference type>, where <length> is the implementation-defined length in octets
of a reference type.
The modified <PL/I variable definition> shall be a valid PL/I data declaration in the program
derived from the <embedded SQL PL/I program>.
6) The reference type identified by <reference type> contained in an <PL/I REF variable> is called
the referenced type of the reference.
7) A <PL/I variable definition> shall specify a scalar variable, not an array or structure.
8) The optional <character representation> sequence in a <PL/I variable definition> may specify
an INITIAL clause. Whether other clauses may be specified is implementation-defined. The
<character representation> sequence shall be such that the <PL/I variable definition> is a valid
PL/I DECLARE statement.
9) CHARACTER describes a character string variable whose equivalent SQL data type has the
character set specified by <character set specification>. If <character set specification> is not
specified, then an implementation-defined <character set specification> is implicit.
Case:
a) If VARYING is not specified, then the length of the variable is fixed. The equivalent SQL
data type is CHARACTER with the same length.
b) If VARYING is specified, then the variable is of variable length, with maximum size the
value of <length>. The equivalent SQL data type is CHARACTER VARYING with the same
maximum length.
10) BIT describes a bit string variable.

Case:
a) If VARYING is not specified, then the length of the variable is fixed. The equivalent SQL
data type is BIT with the same length. If the length of the variable is 1 (one), then the
equivalent SQL data type may be BOOLEAN.
b) If VARYING is specified, then the variable is of variable length with maximum size of the
value of <length>. The equivalent SQL data type is BIT VARYING with the same maximum
length.
11) FIXED DECIMAL describes an exact numeric variable. The <scale> shall not be greater than
the <precision>. The equivalent SQL data type is DECIMAL with the same <precision> and
<scale>.

12) FIXED BINARY describes an exact numeric variable. The equivalent SQL data type is
SMALLINT or INTEGER.
13) FLOAT BINARY describes an approximate numeric variable. The equivalent SQL data type is
FLOAT with the same <precision>.
Access Rules
None.
General Rules
1) See Subclause 16.1, ‘‘<embedded SQL host program>’’
Conformance Rules
1) Without Feature B017, ‘‘Embedded PL/I’’, <embedded SQL PL/I program> shall not be specified.
2) Without Feature F511, ‘‘BIT data type’’, a <PL/I type specification> shall not specify BIT or BIT
VARYING.
<PL/I type specification> shall not contain a <character set specification>.
4) Without Feature S041, ‘‘Basic reference types’’, a <PL/I derived type specification> shall not be
a <PL/I REF variable>.
5) Without Feature S241, ‘‘Transform functions’’, a <PL/I derived type specification> shall not be a
<PL/I user-defined type variable>.
6) Without Feature S232, ‘‘Array locators’’, a <PL/I derived type specification> shall not be a <PL/I
array locator variable>.
tained in a <PL/I user-defined type locator variable> shall not identify a structured type.
8) Without Feature T041, ‘‘Basic LOB data type support’’, a <PL/I BLOB variable>, <PL/I CLOB
variable>, <PL/I BLOB locator variable>, and <PL/I CLOB locator variable> shall not be speci-
fied.
Embedded SQL 185


17 Direct invocation of SQL
17.1 <direct SQL statement>
Function
Specify direct execution of SQL.
Format
<direct SQL statement> ::=

<directly executable statement> <semicolon>
<directly executable statement> ::=

<direct SQL data statement>
| <SQL schema statement>
| <SQL transaction statement>
| <SQL connection statement>
| <SQL session statement>
| <direct implementation-defined statement>
<direct SQL data statement> ::=

<delete statement: searched>
| <direct select statement: multiple rows>
| <insert statement>
| <update statement: searched>
| <temporary table declaration>
<direct implementation-defined statement> ::= !! See the Syntax Rules
Syntax Rules
1) The <direct SQL data statement> shall not contain any SQL parameter reference, SQL variable
reference, <dynamic parameter specification>, or <embedded variable specification>.
2) The <value specification> that represents the null value is implementation-defined.
3) The Format and Syntax Rules for <direct implementation-defined statement> are implementation-
defined.
Access Rules
1) The Access Rules for <direct implementation-defined statement> are implementation-defined.
General Rules
1) The following <direct SQL statement>s are transaction-initiating <direct SQL statement>s:
a) <direct SQL statement>s that are transaction-initiating <SQL procedure statement>s;
b) <direct select statement: multiple rows>; and
Direct invocation of SQL 187

c) <direct implementation-defined statement>s that are transaction-initiating.
2) After the last invocation of an SQL-statement by an SQL-agent in an SQL-session:
a) A <rollback statement> or a <commit statement> is effectively executed. If an unrecov-

erable error has occurred, or if the direct invocation of SQL terminated unexpectedly, or
if any constraint is not satisfied, then a <rollback statement> is performed. Otherwise,
the choice of which of these SQL-statements to perform is implementation-dependent.
The determination of whether a direct invocation of SQL has terminated unexpectedly is
b) Let D be the <descriptor name> of any system descriptor area that is currently allocated
within the current SQL-session. A <deallocate descriptor statement> that specifies
DEALLOCATE DESCRIPTOR D
is effectively executed.
c) All SQL-sessions associated with the SQL-agent are terminated.
3) Let S be the <direct SQL statement>.
4) The current authorization identifier for privilege determination for the execution of S is the
SQL-session user identifier.
5) If S does not conform to the Format, Syntax Rules, and Access Rules for a <direct SQL state-
ment>, then an exception condition is raised: syntax error or access rule violation.
6) When S is invoked by the SQL-agent:

Case:
a) If S is an <SQL connection statement>, then:
i) The diagnostics area is emptied.
ii) S is executed.
iii) If S successfully initiated or resumed an SQL-session, then subsequent invocations of a

<direct SQL statement> by the SQL-agent are associated with that SQL-session until
the SQL-agent terminates the SQL-session or makes it dormant.
b) Otherwise:
i) If no SQL-session is current for the SQL-agent, then

Case:
1) If the SQL-agent has not executed an <SQL connection statement> and there is
no default SQL-session associated with the SQL-agent, then the following <connect
statement> is effectively executed:
CONNECT TO DEFAULT
2) If the SQL-agent has not executed an <SQL connection statement> and there is a de-
fault SQL-session associated with the SQL-agent, then the following <set connection
statement> is effectively executed:
SET CONNECTION DEFAULT

3) Otherwise, an exception condition is raised: connection exception — connection does

not exist.
Subsequent calls to an <externally-invoked procedure> or invocations of a <direct SQL
statement> by the SQL-agent are associated with the SQL-session until the SQL-agent
terminates the SQL-session or makes it dormant.
ii) If an SQL-transaction is active for the SQL-agent, then S is associated with that
SQL-transaction. If S is a <direct implementation-defined statement>, then it is
implementation-defined whether or not S may be associated with an active SQL-
transaction; if not, then an exception condition is raised: invalid transaction state —
active SQL-transaction.
iii) If no SQL-transaction is active for the SQL-agent, then
1) Case:
A) If S is a transaction-initiating <direct SQL statement>, then an SQL-transaction

is initiated.
B) If S is a <direct implementation-defined statement>, then it is implementation-

defined whether or not S initiates an SQL-transaction. If an implementation
defines S to be transaction-initiating, then an SQL-transaction is initiated.
2) If S initiated an SQL-transaction, then:
A) Let T be the SQL-transaction initiated by S.
B) T is associated with this invocation and any subsequent invocations of <direct

SQL statement>s or calls to an <externally-invoked procedure> by the SQL-
agent until the SQL-agent terminates T.
C) If S is not a <start transaction statement>, then

Case:
I) If a <set transaction statement> has been executed since the termination of

the last SQL-transaction in the SQL-session (or if there has been no previous
SQL-transaction in the SQL-session and a <set transaction statement> has
been executed), then the access mode, constraint mode, and isolation level of
T are set as specified by the <set transaction statement>.
II) Otherwise, the access mode, constraint mode for all constraints, and isolation
level for T are read-write, immediate, and SERIALIZABLE, respectively.
D) T is associated with the SQL-session.
iv) If S contains an <SQL schema statement> and the access mode of the current SQL-
transaction is read-only, then an exception condition is raised: invalid transaction state
— read-only SQL-transaction.
v) The diagnostics area is emptied.
vi) S is executed.

7) If the execution of a <direct SQL data statement> occurs within the same SQL-transaction as
the execution of an SQL-schema statement and this is not allowed by the SQL-implementation,
then an exception condition is raised: invalid transaction state — schema and data statement
mixing not supported.
8) Case:
a) If S executed successfully, then either a completion condition is raised: successful comple-

tion, or a completion condition is raised: warning, or a completion condition is raised: no
data.
b) If S did not execute successfully, then all changes made to SQL-data or schemas by the
execution of S are canceled and an exception condition is raised.
NOTE 32 – The method of raising a condition is implementation-defined.
9) Diagnostics information resulting from the execution of S is placed into the diagnostics area as
specified in Clause 18, ‘‘Diagnostics management’’.
NOTE 33 – The method of accessing the diagnostics information is implementation-defined, but does
not alter the contents of the diagnostics area.
Conformance Rules
1) Without Feature B021, ‘‘Direct SQL’’, <direct SQL statement> shall not be specified.

17.2 <direct select statement: multiple rows>
Function
Specify a statement to retrieve multiple rows from a specified table.
Format
<direct select statement: multiple rows> ::=

<query expression> [ <order by clause> ]
Syntax Rules
1) All Syntax Rules of Subclause 7.12, "<query expression>", in ISO/IEC 9075-2, apply to the
<direct select statement: multiple rows>.
2) The <query expression> or <order by clause> of a <direct select statement: multiple rows> shall
not contain any <value specification> other than a <literal>, CURRENT_USER, CURRENT_
ROLE, SESSION_USER, SYSTEM_USER, or CURRENT_PATH.
3) Let T be the table specified by the <query expression>.
4) If ORDER BY is specified, then each <sort specification> in the <order by clause> shall contain
a <value expression> VE, which shall not contain a <subquery> or a <set function specification>,
but shall contain a <column reference>.
a) Let X be any <column reference> directly contained in VE.
b) If X does not contain an explicit <table or query name> or <correlation name>, then VE
shall be a <column name> that shall be equivalent to the name of exactly one column of ST.
NOTE 34 – A previous version of ISO/IEC 9075 allows <sort specification> to simply contain a
<signed integer> to denote a column reference of a column of T. That facility no longer exists. See
Appendix E, "Incompatibilities with ISO/IEC 9075:1992 and ISO/IEC 9075-4:1996", in ISO/IEC 9075.
Access Rules
None.
General Rules
1) All General Rules of Subclause 7.12, "<query expression>", in ISO/IEC 9075-2, apply to the
<direct select statement: multiple rows>.
2) Let Q be the result of the <query expression>.
3) If Q is empty, then a completion condition is raised: no data.
4) If an <order by clause> is not specified, then the ordering of the rows of Q is implementation-
dependent.

5) If an <order by clause> is specified, then the ordering of rows of the result is effectively deter-
mined by the <order by clause> as follows:
a) Each <sort specification> specifies the sort direction for the corresponding sort key Ki . If
ASC is specified or implied in the i-th <sort specification>, then the sort direction for Ki is
ascending and the applicable <comp op> is the <less than operator>. Otherwise, the sort
direction for Ki is descending and the applicable <comp op> is the <greater than operator>.
b) Let X and Y be distinct rows in the result table, and let XVi and YVi be the values of Ki in
these rows, respectively. The relative position of rows X and Y in the result is determined by
comparing XVi and YVi according to the rules of Subclause 8.2, "<comparison predicate>", in
ISO/IEC 9075-2, where the <comp op> is the applicable <comp op> for Ki , with the following
special treatment of null values. Whether a sort key value that is null is considered greater
or less than a non-null value is implementation-defined, but all sort key values that are null
shall either be considered greater than all non-null values or be considered less than all
non-null values. XVi is said to precede YVi if the value of the <comparison predicate> ‘‘XVi
<comp op> YVi ’’ is true for the applicable <comp op>.
c) In the result table, the relative position of row X is before row Y if and only if XVn precedes
YVn for some n greater than 0 (zero) and less than the number of <sort specification>s
and XVi = YVi for all i < n. The relative order of two rows for which XVi = YVi for all i is
6) If Q is not empty, then Q is returned. The method of returning Q is implementation-defined.
Conformance Rules
None.

18 Diagnostics management
18.1 <get diagnostics statement>
Function
Get exception or completion condition information from the diagnostics area.
Format
<statement information item name> ::=

| DYNAMIC_FUNCTION
| DYNAMIC_FUNCTION_CODE
Syntax Rules
Table 8—<identifier>s for use with <get diagnostics statement>

<identifier> Data Type
<statement information item name>s
All alternatives from ISO/IEC

9075-2
DYNAMIC_FUNCTION character varying (L)
DYNAMIC_FUNCTION_CODE exact numeric with scale 0 (zero)
Access Rules
General Rules
1) Augments GR1) Specification of <statement information item> retrieves information about the
statement execution recorded in the diagnostics area into <simple target specification>.
a) The value of DYNAMIC_FUNCTION is a character string that identifies the type of the
SQL-statement being prepared or executed dynamically. Table 9, ‘‘SQL-statement codes’’,
specifies the identifier of the SQL-statements.
b) The value of DYNAMIC_FUNCTION_CODE is a number that identifies the type of the SQL-
statement being prepared or executed dynamically. Table 9, ‘‘SQL-statement codes’’, specifies
the code for the SQL-statements. Positive values are reserved for SQL-statements defined
by ISO/IEC 9075; negative values are reserved for implementation-defined SQL-statements.
Diagnostics management 193

Table 9—SQL-statement codes

SQL-statement Identifier Code
All alternatives from ISO/IEC 9075-2

<allocate cursor statement> ALLOCATE CURSOR 1 (one)
<allocate descriptor statement> ALLOCATE DESCRIPTOR 2
<deallocate descriptor statement> DEALLOCATE DESCRIPTOR 15
<deallocate prepared statement> DEALLOCATE PREPARE 16
<describe statement> DESCRIBE 20
<direct select statement: multiple rows> SELECT 21
<dynamic close statement> DYNAMIC CLOSE 37
<dynamic delete statement: positioned> DYNAMIC DELETE CURSOR 38
<dynamic fetch statement> DYNAMIC FETCH 39
<dynamic open statement> DYNAMIC OPEN 40
<dynamic select statement> SELECT CURSOR 85
<dynamic single row select statement> SELECT 41
<dynamic update statement: positioned> DYNAMIC UPDATE CURSOR 42
<execute immediate statement> EXECUTE IMMEDIATE 43
<execute statement> EXECUTE 44
<get descriptor statement> GET DESCRIPTOR 47
<preparable dynamic delete statement: positioned> DYNAMIC DELETE CURSOR 54
<preparable dynamic update statement: positioned> DYNAMIC UPDATE CURSOR 55
<prepare statement> PREPARE 56
<set catalog statement> SET CATALOG 66
<set descriptor statement> SET DESCRIPTOR 70
<set path statement> SET CURRENT_PATH 69
<set names statement> SET NAMES 72
<set schema statement> SET SCHEMA 74
<set transform group statement> SET TRANSFORM GROUP 118
Implementation-defined statements An implementation-defined character x1
string value different from the value
associated with any other SQL-statement
Unrecognized statements A zero-length string 0 (zero)
1 An implementation-defined negative number different from the value associated with any other SQL-statement.
2) Augments GR1) It is implementation-defined whether the identifier and code from Table 9, ‘‘SQL-
statement codes’’, for <dynamic select statement> or <dynamic single row select statement> is
used to describe a <dynamic select statement> or <dynamic single row select statement> that
has been prepared but has not yet been executed dynamically.

Conformance Rules
Diagnostics management 195


19 Definition Schema
19.1 SQL_LANGUAGES base table
Function
The SQL_LANGUAGES table has one row for each ISO and implementation-defined SQL language
binding and programming language for which conformance is claimed.
Definition
Add a new table constraint
CONSTRAINT SQL_LANGUAGE_BINDING_STYLE_ISO_1999
CHECK ( SQL_LANGUAGE_SOURCE <> ’ISO 9075’
OR
( SQL_LANGUAGE_YEAR <> ’1999’
OR
( SQL_LANGUAGE_BINDING_STYLE IS NOT NULL
AND
SQL_LANGUAGE_BINDING_STYLE IN
( ’DIRECT’, ’EMBEDDED’, ’MODULE’ ) ) ) ),
Add a new table constraint
CONSTRAINT SQL_LANGUAGES_STANDARD_VALID_CHECK_ISO_1999
CHECK ( SQL_LANGUAGE_SOURCE <> ’ISO 9075’
OR
( SQL_LANGUAGE_YEAR <> ’1999’
OR
( SQL_LANGUAGE_BINDING_STYLE = ’DIRECT’
AND
SQL_LANGUAGE_PROGRAMMING_LANGUAGE IS NULL )
OR
( SQL_LANGUAGE_BINDING_STYLE IN
( ’EMBEDDED’, ’MODULE’ )
AND
SQL_LANGUAGE_PROGRAMMING_LANGUAGE IN
( ’ADA’, ’C’, ’COBOL’, ’FORTRAN’,
’MUMPS’, ’PASCAL’, ’PLI’ ) ) ) )
Description
No additional Descriptions.
Definition Schema 197


20 Status codes
20.1 SQLSTATE
Table 10—SQLSTATE class and subclass values

Category Condition Class Subcondition Subclass
All alternatives from ISO/IEC

9075-2
X attempt to assign to non-updatable 0U (no subclass) 000
column
X attempt to assign to ordering col- 0V (no subclass) 000
umn
X dynamic SQL error 07 (no subclass) 000
cursor specification cannot be exe- 003
cuted
invalid descriptor count 008
invalid descriptor index 009
prepared statement not a cursor 005
specification
restricted data type attribute viola- 006
tion
undefined DATA value 00C
undefined DATA target 00D
undefined LEVEL value 00E
undefined DATETIME_INTERVAL_ 00F
CODE
using clause does not match dy- 001
namic parameter specifications
using clause does not match target 002
specifications
using clause required for dynamic 004
parameters
using clause required for result 007
fields
data type transform function viola- 00B
tion
X invalid SQL-invoked procedure 0M (no subclass) 000
reference
X invalid character set name 2C (no subclass) 000
Status codes 199

20.1 SQLSTATE
Table 10—SQLSTATE class and subclass values (Cont.)

Category Condition Class Subcondition Subclass
X invalid schema name list specifica- 0E (no subclass) 000

tion
X invalid transform group name 0S (no subclass) 000
specification
X target table disagrees with cursor 0T (no subclass) 000
specification
W warning 01 (no subclass) 000
insufficient item descriptor areas 005

21 Conformance
21.1 General conformance requirements
Insert this paragraph The list of features that are implied by other features is shown in Table 11,
‘‘Implied feature relationships’’.
Table 11—Implied feature relationships

Implied
Feature Feature
ID Feature Description ID Implied Feature Description
B032 Extended dynamic SQL B031 Basic dynamic SQL
21.2 Claims of conformance
Insert this paragraph In addition to the requirements of Subclause 8.1.5, "Claims of conformance", in
ISO/IEC 9075-1, a claim of conformance to this part of ISO/IEC 9075 shall state:
1) Whether direct invocation (<direct SQL statement>) is supported.
2) Whether embedded SQL is supported and, if so, for which of the following programming lan-
guages:
a) Ada
b) C
c) COBOL
d) Fortran
e) MUMPS
f) Pascal
g) PL/I
Conformance 201

Annex A
(informative)
SQL Conformance Summary
Replicated paragraph The contents of this Annex summarizes all Conformance Rules, ordered by
Feature ID and by Subclause.
1) Specifications for Feature B011, ‘‘Embedded Ada’’:
a) Subclause 16.3, ‘‘<embedded SQL Ada program>’’:
i) Without Feature B011, ‘‘Embedded Ada’’, <embedded SQL Ada program> shall not be
specified.
2) Specifications for Feature B012, ‘‘Embedded C’’:
a) Subclause 16.4, ‘‘<embedded SQL C program>’’:
i) Without Feature B012, ‘‘Embedded C’’, <embedded SQL C program> shall not be speci-
fied.
3) Specifications for Feature B013, ‘‘Embedded COBOL’’:
a) Subclause 16.5, ‘‘<embedded SQL COBOL program>’’:
i) Without Feature B013, ‘‘Embedded COBOL’’, <embedded SQL COBOL program> shall
not be specified.
4) Specifications for Feature B014, ‘‘Embedded Fortran’’:
a) Subclause 16.6, ‘‘<embedded SQL Fortran program>’’:
i) Without Feature B014, ‘‘Embedded Fortran’’, <embedded SQL Fortran program> shall
not be specified.
5) Specifications for Feature B015, ‘‘Embedded MUMPS’’:
a) Subclause 16.7, ‘‘<embedded SQL MUMPS program>’’:
i) Without Feature B015, ‘‘Embedded MUMPS’’, <embedded SQL MUMPS program> shall
not be specified.
SQL Conformance Summary 203

6) Specifications for Feature B016, ‘‘Embedded Pascal’’:
a) Subclause 16.8, ‘‘<embedded SQL Pascal program>’’:
i) Without Feature B016, ‘‘Embedded Pascal’’, <embedded SQL Pascal program> shall not
be specified.
7) Specifications for Feature B017, ‘‘Embedded PL/I’’:
a) Subclause 16.9, ‘‘<embedded SQL PL/I program>’’:
i) Without Feature B017, ‘‘Embedded PL/I’’, <embedded SQL PL/I program> shall not be
specified.
8) Specifications for Feature B021, ‘‘Direct SQL’’:
a) Subclause 17.1, ‘‘<direct SQL statement>’’:
i) Without Feature B021, ‘‘Direct SQL’’, <direct SQL statement> shall not be specified.
9) Specifications for Feature B031, ‘‘Basic dynamic SQL’’:
a) Subclause 5.3, ‘‘Names and identifiers’’:
i) Insert this CR Without Feature B031, ‘‘Basic dynamic SQL’’, conforming SQL language
shall not contain any <SQL statement name>, <dynamic cursor name>, or <descriptor
name>.
b) Subclause 6.1, ‘‘<value specification> and <target specification>’’:
i) Insert this CR Without Feature B031, ‘‘Basic dynamic SQL’’, a <general value specifica-
tion> shall not be a <dynamic parameter specification>.
c) Subclause 11.1, ‘‘<SQL-client module definition>’’:
i) Insert this CR Without Feature B031, ‘‘Basic dynamic SQL’’, a <module contents> shall
not be a <dynamic declare cursor>.
d) Subclause 11.3, ‘‘<SQL procedure statement>’’:
i) Insert this CR Without Feature B031, ‘‘Basic dynamic SQL’’, an <SQL procedure state-
ment> shall not be an <SQL dynamic statement>.
e) Subclause 15.2, ‘‘<allocate descriptor statement>’’:
i) Without Feature B031, ‘‘Basic dynamic SQL’’, conforming SQL language shall not con-
tain any <allocate descriptor statement>.
f) Subclause 15.3, ‘‘<deallocate descriptor statement>’’:
tain any <deallocate descriptor statement>.
g) Subclause 15.4, ‘‘<get descriptor statement>’’:
tain any <get descriptor statement>.

ii) Without Feature T301, ‘‘Functional dependencies’’, and without Feature B031, ‘‘Basic
dynamic SQL’’, conforming SQL language shall not specify KEY_MEMBER.
h) Subclause 15.5, ‘‘<set descriptor statement>’’:
tain any <set descriptor statement>.
i) Subclause 15.6, ‘‘<prepare statement>’’:
tain any <prepare statement>.
j) Subclause 15.8, ‘‘<describe statement>’’:
tain any <describe output statement>.
k) Subclause 15.9, ‘‘<input using clause>’’:
tain any <using input clause>.
l) Subclause 15.10, ‘‘<output using clause>’’:
tain any <output using clause>.
m) Subclause 15.11, ‘‘<execute statement>’’:
tain any <execute statement>.
n) Subclause 15.12, ‘‘<execute immediate statement>’’:
tain any <execute immediate statement>.
o) Subclause 15.13, ‘‘<dynamic declare cursor>’’:
i) Without Feature B031, ‘‘Basic dynamic SQL’’, and Feature F791, ‘‘Insensitive cursors’’, a
<dynamic declare cursor> shall not specify INSENSITIVE.
ii) Without Feature B031, ‘‘Basic dynamic SQL’’, and Feature F421, ‘‘Scrolled cursors’’, a
<dynamic declare cursor> shall not specify <cursor scrollability>.
iii) Without Feature B031, ‘‘Basic dynamic SQL’’, and Feature F831, ‘‘Full cursor update’’,
if an <updatability clause> of FOR UPDATE with or without a <column name list> is
specified, then ORDER BY shall not be specified.
iv) Without Feature B031, ‘‘Basic dynamic SQL’’, and Feature F341, ‘‘Scrolled cursors’’, and
Feature F831, ‘‘Full cursor update’’, if an <updatability clause> of FOR UPDATE with
or without a <column name list> is specified, then <cursor scrollability> shall not be
specified.
v) Without Feature B031, ‘‘Basic dynamic SQL’’, and Feature T471, ‘‘Result sets return
value’’, a <dynamic declare cursor> shall not specify <cursor returnability>.

vi) Without Feature B031, ‘‘Basic dynamic SQL’’, and either Feature F791, ‘‘Insensitive
cursors’’, or Feature T231, ‘‘SENSITIVE cursors’’, a <dynamic declare cursor> shall not
specify ASENSITIVE.
vii) Without Feature B031, ‘‘Basic dynamic SQL’’, conforming SQL language shall not con-
tain any <dynamic declare cursor>.
viii) Without Feature B031, ‘‘Basic dynamic SQL’’, and Feature T231, ‘‘SENSITIVE cursors’’,
a <dynamic declare cursor> shall not specify SENSITIVE.
p) Subclause 15.15, ‘‘<dynamic open statement>’’:
tain any <dynamic open statement>.
q) Subclause 15.16, ‘‘<dynamic fetch statement>’’:
tain any <dynamic fetch statement>.
r) Subclause 15.17, ‘‘<dynamic single row select statement>’’:
i) Without Feature B031, ‘‘Basic dynamic SQL’’, conforming SQL language shall contain no
<dynamic single row select statement>.
s) Subclause 15.18, ‘‘<dynamic close statement>’’:
tain any <dynamic close statement>.
t) Subclause 15.19, ‘‘<dynamic delete statement: positioned>’’:
tain any <dynamic delete statement: positioned>.
u) Subclause 15.20, ‘‘<dynamic update statement: positioned>’’:
tain any <dynamic update statement: positioned>.
10) Specifications for Feature B032, ‘‘Extended dynamic SQL’’:
a) Subclause 5.3, ‘‘Names and identifiers’’:
i) Insert this CR Without Feature B032, ‘‘Extended dynamic SQL’’, conforming SQL lan-
guage shall not contain any <extended statement name> or <extended cursor name>.
b) Subclause 15.2, ‘‘<allocate descriptor statement>’’:
i) Without Feature B032, ‘‘Extended dynamic SQL’’, an <occurrences> and a <descriptor

name> shall be a <literal>.
c) Subclause 15.3, ‘‘<deallocate descriptor statement>’’:
i) Without Feature B032, ‘‘Extended dynamic SQL’’, a <descriptor name> shall be a <lit-
eral>.

d) Subclause 15.4, ‘‘<get descriptor statement>’’:
eral>.
e) Subclause 15.5, ‘‘<set descriptor statement>’’:
eral>.
f) Subclause 15.7, ‘‘<deallocate prepared statement>’’:
i) Without Feature B032, ‘‘Extended dynamic SQL’’, conforming SQL language shall con-
tain no <deallocate prepared statement>.
g) Subclause 15.8, ‘‘<describe statement>’’:
i) Without Feature B032, ‘‘Extended dynamic SQL’’, conforming SQL language shall not
contain any <describe input statement>.
h) Subclause 15.9, ‘‘<input using clause>’’:
eral>.
i) Subclause 15.10, ‘‘<output using clause>’’:
eral>.
j) Subclause 15.11, ‘‘<execute statement>’’:
tain no <result using clause>.
k) Subclause 15.14, ‘‘<allocate cursor statement>’’:
i) Without Feature B032, ‘‘Extended dynamic SQL’’, conforming SQL language shall not
contain any <allocate cursor statement>.
l) Subclause 15.21, ‘‘<preparable dynamic delete statement: positioned>’’:
tain no <preparable dynamic delete statement: positioned>.
m) Subclause 15.22, ‘‘<preparable dynamic update statement: positioned>’’:
tain no <preparable dynamic update statement: positioned>.
11) Specifications for Feature B041, ‘‘Extensions to embedded SQL exception declarations’’:
a) Subclause 16.2, ‘‘<embedded exception declaration>’’:
i) Without Feature B041, ‘‘Extensions to embedded SQL exception declarations’’, a <major

category> shall not specify SQLEXCEPTION or SQLWARNING.

ii) Without Feature B041, ‘‘Extensions to embedded SQL exception declarations’’, an <SQL
condition> shall not specify SQLSTATE or CONSTRAINT.
12) Specifications for Feature B051, ‘‘Enhanced execution rights’’:
a) Subclause 11.1, ‘‘<SQL-client module definition>’’:
i) Insert this CR Without Feature B051, ‘‘Enhanced execution rights’’, conforming SQL
language shall not specify FOR STATIC ONLY or FOR STATIC AND DYNAMIC.
b) Subclause 16.1, ‘‘<embedded SQL host program>’’:
i) Without Feature B051, ‘‘Enhanced execution rights’’, conforming SQL language shall not
contain any <embedded authorization declaration>.
13) Specifications for Feature F341, ‘‘Scrolled cursors’’:
a) Subclause 15.13, ‘‘<dynamic declare cursor>’’:
i) Without Feature B031, ‘‘Basic dynamic SQL’’, and Feature F341, ‘‘Scrolled cursors’’, and
Feature F831, ‘‘Full cursor update’’, if an <updatability clause> of FOR UPDATE with
or without a <column name list> is specified, then <cursor scrollability> shall not be
specified.
14) Specifications for Feature F361, ‘‘Subprogram support’’:
a) Subclause 16.1, ‘‘<embedded SQL host program>’’:
i) Without Feature F361, ‘‘Subprogram support’’, no two <host variable definition>s shall
specify the same variable name.
15) Specifications for Feature F421, ‘‘Scrolled cursors’’:
i) Without Feature B031, ‘‘Basic dynamic SQL’’, and Feature F421, ‘‘Scrolled cursors’’, a
<dynamic declare cursor> shall not specify <cursor scrollability>.
16) Specifications for Feature F451, ‘‘Character set definition’’:
a) Subclause 14.3, ‘‘<set names statement>’’:
i) Without Feature F761, ‘‘Session management’’, and either Feature F451, ‘‘Character set
definition’’, or Feature F461, ‘‘Named character sets’’, conforming SQL language shall
not contain any <set names statement>.
i) Without Feature F451, ‘‘Character set definition’’, or Feature F461, ‘‘Named character
sets’’, an <embedded SQL declare section> shall not contain an <embedded character set
declaration>.
c) Subclause 16.3, ‘‘<embedded SQL Ada program>’’:
sets’’, an <Ada qualified type specification> shall not contain a <character set specifica-
tion>.

d) Subclause 16.4, ‘‘<embedded SQL C program>’’:
sets’’, a <C variable definition> shall not contain a <character set specification>.
e) Subclause 16.5, ‘‘<embedded SQL COBOL program>’’:
sets’’, a <COBOL character type> shall not contain a <character set specification>.
f) Subclause 16.6, ‘‘<embedded SQL Fortran program>’’:
sets’’, a <Fortran type specification> shall not contain a <character set specification>.
g) Subclause 16.8, ‘‘<embedded SQL Pascal program>’’:
sets’’, a <Pascal type specification> shall not contain a <character set specification>.
h) Subclause 16.9, ‘‘<embedded SQL PL/I program>’’:
sets’’, a <PL/I type specification> shall not contain a <character set specification>.
17) Specifications for Feature F461, ‘‘Named character sets’’:
a) Subclause 16.1, ‘‘<embedded SQL host program>’’:
sets’’, an <embedded SQL declare section> shall not contain an <embedded character set
declaration>.
b) Subclause 16.3, ‘‘<embedded SQL Ada program>’’:
sets’’, an <Ada qualified type specification> shall not contain a <character set specifica-
tion>.
c) Subclause 16.4, ‘‘<embedded SQL C program>’’:
sets’’, a <C variable definition> shall not contain a <character set specification>.
d) Subclause 16.5, ‘‘<embedded SQL COBOL program>’’:
sets’’, a <COBOL character type> shall not contain a <character set specification>.
e) Subclause 16.6, ‘‘<embedded SQL Fortran program>’’:
sets’’, a <Fortran type specification> shall not contain a <character set specification>.
f) Subclause 16.8, ‘‘<embedded SQL Pascal program>’’:
sets’’, a <Pascal type specification> shall not contain a <character set specification>.

g) Subclause 16.9, ‘‘<embedded SQL PL/I program>’’:
sets’’, a <PL/I type specification> shall not contain a <character set specification>.
18) Specifications for Feature F511, ‘‘BIT data type’’:
i) Without Feature F511, ‘‘BIT data type’’, an <Ada variable definition> shall not specify a
bit string variable.
b) Subclause 16.4, ‘‘<embedded SQL C program>’’:
i) Without Feature F511, ‘‘BIT data type’’, a <C derived variable> shall not be a <C bit
variable>.
c) Subclause 16.5, ‘‘<embedded SQL COBOL program>’’:
i) Without Feature F511, ‘‘BIT data type’’, a <COBOL type specification> shall not be a
<COBOL bit type>.
d) Subclause 16.6, ‘‘<embedded SQL Fortran program>’’:
i) Without Feature F511, ‘‘BIT data type’’, a <Fortran type specification> shall not specify
BIT.
e) Subclause 16.8, ‘‘<embedded SQL Pascal program>’’:
i) Without Feature F511, ‘‘BIT data type’’, a <Pascal type specification> shall not specify
BIT or PACKED ARRAY [1..<length>] OF BIT.
f) Subclause 16.9, ‘‘<embedded SQL PL/I program>’’:
i) Without Feature F511, ‘‘BIT data type’’, a <PL/I type specification> shall not specify BIT
or BIT VARYING.
19) Specifications for Feature F611, ‘‘Indicator data types’’:
a) Subclause 6.1, ‘‘<value specification> and <target specification>’’:
i) Insert this CR Without Feature F611, ‘‘Indicator data types’’, the specific declared types
of <indicator parameter>s and <indicator variable>s shall be the same implementation-
defined data type.
20) Specifications for Feature F761, ‘‘Session management’’:
a) Subclause 14.1, ‘‘<set catalog statement>’’:
i) Without Feature F761, ‘‘Session management’’, and Feature F651, ‘‘Catalog name quali-
fiers’’, conforming SQL language shall not contain any <set catalog statement>.
b) Subclause 14.2, ‘‘<set schema statement>’’:
i) Without Feature F761, ‘‘Session management’’, conforming SQL language shall not
contain any <set schema statement>.

c) Subclause 14.3, ‘‘<set names statement>’’:
i) Without Feature F761, ‘‘Session management’’, and either Feature F451, ‘‘Character set
definition’’, or Feature F461, ‘‘Named character sets’’, conforming SQL language shall
not contain any <set names statement>.
21) Specifications for Feature F791, ‘‘Insensitive cursors’’:
i) Without Feature B031, ‘‘Basic dynamic SQL’’, and either Feature F791, ‘‘Insensitive
specify ASENSITIVE.
ii) Without Feature B031, ‘‘Basic dynamic SQL’’, and Feature F791, ‘‘Insensitive cursors’’, a
<dynamic declare cursor> shall not specify INSENSITIVE.
22) Specifications for Feature F831, ‘‘Full cursor update’’:
i) Without Feature B031, ‘‘Basic dynamic SQL’’, and Feature F831, ‘‘Full cursor update’’,
if an <updatability clause> of FOR UPDATE with or without a <column name list> is
specified, then ORDER BY shall not be specified.
23) Specifications for Feature S024, ‘‘Enhanced structured types’’:
i) Without Feature S024, ‘‘Enhanced structured types’’, a <value expression> that is a

<sort key> shall not be of a structured type.
24) Specifications for Feature S041, ‘‘Basic reference types’’:
i) Without Feature S041, ‘‘Basic reference types’’, an <Ada derived type specification> shall
not be an <Ada REF variable>.
i) Without Feature S041, ‘‘Basic reference types’’, a <C derived variable> shall not be a <C
REF variable>.
i) Without Feature S041, ‘‘Basic reference types’’, a <COBOL type specification> shall not
be a <COBOL REF variable>.
i) Without Feature S041, ‘‘Basic reference types’’, a <Fortran derived type specification>
shall not be a <Fortran REF variable>.
e) Subclause 16.7, ‘‘<embedded SQL MUMPS program>’’:
i) Without Feature S041, ‘‘Basic reference types’’, a <MUMPS derived type specification>
shall not be a <MUMPS REF variable>.

i) Without Feature S041, ‘‘Basic reference types’’, a <Pascal derived type specification>
shall not be a <Pascal REF variable>.
i) Without Feature S041, ‘‘Basic reference types’’, a <PL/I derived type specification> shall
not be a <PL/I REF variable>.
25) Specifications for Feature S071, ‘‘SQL paths in function and type name resolution’’:
a) Subclause 14.4, ‘‘<set path statement>’’:
i) Without Feature S071, ‘‘SQL paths in function and type name resolution’’, Conforming
SQL language shall not contain any <set path statement>.
i) Without Feature S071, ‘‘SQL paths in function and type name resolution’’, <embedded
path specification> shall not be specified.
26) Specifications for Feature S231, ‘‘Structured type locators’’:
i) Without Feature S231, ‘‘Structured type locators’’, the <user-defined type name> simply
contained in an <Ada user-defined type locator variable> shall not identify a structured
type.
contained in a <C user-defined type locator variable> shall not identify a structured
type.
i) Without Feature S231, ‘‘Structured type locators’’, the <user-defined type name> sim-
ply contained in a <COBOL user-defined type locator variable> shall not identify a
structured type.
ply contained in a <Fortran user-defined type locator variable> shall not identify a
structured type.
ply contained in a <MUMPS user-defined type locator variable> shall not identify a
structured type.

contained in a <Pascal user-defined type locator variable> shall not identify a structured
type.
contained in a <PL/I user-defined type locator variable> shall not identify a structured
type.
27) Specifications for Feature S232, ‘‘Array locators’’:
i) Without Feature S232, ‘‘Array locators’’, an <Ada derived type specification> shall not be
an <Ada array locator variable>.
i) Without Feature S232, ‘‘Array locators’’, a <C derived variable> shall not be a <C array
locator variable>.
i) Without Feature S232, ‘‘Array locators’’, a <COBOL derived type specification> shall not
be a <COBOL array locator variable>.
i) Without Feature S232, ‘‘Array locators’’, a <Fortran derived type specification> shall not
be a <Fortran array locator variable>.
i) Without Feature S232, ‘‘Array locators’’, a <MUMPS derived type specification> shall
not be a <MUMPS array locator variable>.
i) Without Feature S232, ‘‘Array locators’’, a <Pascal derived type specification> shall not
be a <Pascal array locator variable>.
i) Without Feature S232, ‘‘Array locators’’, a <PL/I derived type specification> shall not be
a <PL/I array locator variable>.
28) Specifications for Feature S241, ‘‘Transform functions’’:
a) Subclause 14.5, ‘‘<set transform group statement>’’:
i) Without Feature S241, ‘‘Transform functions’’, conforming SQL language shall not
contain any <set transform group statement>.

i) Without Feature S241, ‘‘Transform functions’’, <embedded transform group specification>

shall not be specified.
c) Subclause 16.3, ‘‘<embedded SQL Ada program>’’:
i) Without Feature S241, ‘‘Transform functions’’, an <Ada derived type specification> shall
not be an <Ada user-defined type variable>.
d) Subclause 16.4, ‘‘<embedded SQL C program>’’:
i) Without Feature S241, ‘‘Transform functions’’, a <C derived type specification> shall not
be a <C user-defined type variable>.
e) Subclause 16.5, ‘‘<embedded SQL COBOL program>’’:
i) Without Feature S241, ‘‘Transform functions’’, a <COBOL derived type specification>

shall not be a <COBOL user-defined type variable>.
f) Subclause 16.6, ‘‘<embedded SQL Fortran program>’’:
i) Without Feature S241, ‘‘Transform functions’’, a <Fortran derived type specification>

shall not be a <Fortran user-defined type variable>.
g) Subclause 16.7, ‘‘<embedded SQL MUMPS program>’’:
i) Without Feature S241, ‘‘Transform functions’’, a <MUMPS derived type specification>

shall not be a <MUMPS user-defined type variable>.
h) Subclause 16.8, ‘‘<embedded SQL Pascal program>’’:
i) Without Feature S241, ‘‘Transform functions’’, a <Pascal derived type specification> shall
not be a <Pascal user-defined type variable>.
i) Subclause 16.9, ‘‘<embedded SQL PL/I program>’’:
i) Without Feature S241, ‘‘Transform functions’’, a <PL/I derived type specification> shall
not be a <PL/I user-defined type variable>.
29) Specifications for Feature T041, ‘‘Basic LOB data type support’’:
i) Without Feature T041, ‘‘Basic LOB data type support’’, an <Ada BLOB variable>, <Ada
CLOB variable>, <Ada BLOB locator variable>, and <Ada CLOB locator variable> shall
not be specified.
i) Without Feature T041, ‘‘Basic LOB data type support’’, a <C BLOB variable>, <C CLOB
variable>, <C BLOB locator variable>, and <C CLOB locator variable> shall not be
specified.

i) Without Feature T041, ‘‘Basic LOB data type support’’, a <COBOL BLOB variable>,
<COBOL CLOB variable>, <COBOL BLOB locator variable>, and <COBOL CLOB
locator variable> shall not be specified.
i) Without Feature T041, ‘‘Basic LOB data type support’’, a <Fortran BLOB variable>,
<Fortran CLOB variable>, <Fortran BLOB locator variable>, and <Fortran CLOB
i) Without Feature T041, ‘‘Basic LOB data type support’’, a <MUMPS BLOB variable>,
<MUMPS CLOB variable>, <MUMPS BLOB locator variable>, and <MUMPS CLOB
i) Without Feature T041, ‘‘Basic LOB data type support’’, a <Pascal BLOB variable>,
<Pascal CLOB variable>, <Pascal BLOB locator variable>, and <Pascal CLOB locator
variable> shall not be specified.
i) Without Feature T041, ‘‘Basic LOB data type support’’, a <PL/I BLOB variable>, <PL/I
CLOB variable>, <PL/I BLOB locator variable>, and <PL/I CLOB locator variable> shall
not be specified.
30) Specifications for Feature T231, ‘‘SENSITIVE cursors’’:
i) Without Feature B031, ‘‘Basic dynamic SQL’’, and either Feature F791, ‘‘Insensitive
specify ASENSITIVE.
ii) Without Feature B031, ‘‘Basic dynamic SQL’’, and Feature T231, ‘‘SENSITIVE cursors’’,
a <dynamic declare cursor> shall not specify SENSITIVE.
31) Specifications for Feature T301, ‘‘Functional dependencies’’:
a) Subclause 15.4, ‘‘<get descriptor statement>’’:
i) Without Feature T301, ‘‘Functional dependencies’’, and without Feature B031, ‘‘Basic
dynamic SQL’’, conforming SQL language shall not specify KEY_MEMBER.
32) Specifications for Feature T471, ‘‘Result sets return value’’:
i) Without Feature B031, ‘‘Basic dynamic SQL’’, and Feature T471, ‘‘Result sets return
value’’, a <dynamic declare cursor> shall not specify <cursor returnability>.

33) Specifications for Feature T551, ‘‘Optional key words for default syntax’’:
i) Without Feature T551, ‘‘Optional key words for default syntax’’, a <dynamic declare
cursor> shall not specify WITHOUT HOLD.

Annex B
(informative)
Implementation-defined elements
Insert this paragraph This Annex references those features that are identified in the body of this part
of ISO/IEC 9075 as implementation-defined.
1) Subclause 4.1, ‘‘Catalogs’’: The default catalog name substitution value for execution of
<preparable statement>s that are dynamically prepared in the current SQL-session through the
execution of <prepare statement>s and <execute immediate statement>s are implementation-
defined.
2) Subclause 4.8, ‘‘Embedded syntax’’: Whether a portion of the name space is reserved by an
implementation for the names of procedures, subroutines, program variables, branch labels,
<SQL-client module definition>s, or <externally-invoked procedure>s is implementation-defined;
if a portion of the name space is so reserved, the portion reserved is also implementation-
defined.
3) Subclause 4.9, ‘‘SQL dynamic statements’’: Within an SQL-session, all prepared statements
belong to the same implementation-defined <SQL-client module definition> that is different
from any other <SQL-client module definition> that exists simultaneously in the environment.
4) Subclause 4.10, ‘‘Direct invocation of SQL’’: The method of invoking <direct SQL statement>s,
the method of raising conditions as a result of <direct SQL statement>s, the method of accessing
diagnostic information, and the method of returning the results are all implementation-defined.
5) Subclause 4.12, ‘‘SQL-transactions’’: It is implementation-defined whether or not the dynamic

execution of an <SQL dynamic data statement> is permitted to occur within the same SQL-
transaction as the dynamic execution of an SQL-schema statement. If it does occur, then the
effect on any prepared dynamic statement is also implementation-defined.
6) Subclause 4.14, ‘‘SQL-sessions’’: When an SQL-session is initiated, there is an implementation-

defined default catalog whose name is used to effectively qualify all unqualified <schema
name>s contained in <preparable statement>s that are dynamically prepared in the current
SQL-session through the execution of <prepare statement>s and <execute immediate state-
ment>s.
7) Subclause 4.14, ‘‘SQL-sessions’’: When an SQL-session is initiated, there is an implementation-

defined default schema whose name is used to effectively qualify all unqualified <schema
qualified name>s contained in <preparable statement>s that are dynamically prepared in the
current SQL-session through the execution of <prepare statement>s and <execute immediate
statement>s.
Implementation-defined elements 217

8) Subclause 4.14, ‘‘SQL-sessions’’: The value of the current SQL-path before a successful execution
of <set path statement> is implementation-defined.
9) Subclause 5.3, ‘‘Names and identifiers’’: If a <schema name> contained in a <preparable state-
ment> that is dynamically prepared in the current SQL-session through the execution of a
<prepare statement> or an <execute immediate statement> does not contain a <catalog name>,
then the implementation-defined <catalog name> for the SQL-session is implicit.
10) Subclause 5.3, ‘‘Names and identifiers’’: If a <schema qualified name> contained in a <prepara-
ble statement> that is dynamically prepared in the current SQL-session through the execution
of a <prepare statement> or an <execute immediate statement> does not contain a <schema
name>, then the implementation-defined <schema name> for the SQL-session is implicit.
11) Subclause 6.1, ‘‘<value specification> and <target specification>’’: In Intermediate SQL, the
specific data type of <indicator parameter>s and <indicator variable>s shall be the same
implementation-defined data type.
12) Subclause 15.2, ‘‘<allocate descriptor statement>’’: If WITH MAX <occurrences> is not specified,
then an implementation-defined default value for <occurrences> that is greater than 0 (zero) is
implicit.
13) Subclause 15.2, ‘‘<allocate descriptor statement>’’: The maximum number of SQL descriptor
areas and the maximum number of item descriptor areas for a single SQL descriptor area are
14) Subclause 15.5, ‘‘<set descriptor statement>’’: Restrictions on changing TYPE, LENGTH,
OCTET_LENGTH, SCALE, COLLATION_CATALOG, COLLATION_SCHEMA, COLLATION_
NAME, CHARACTER_SET_CATALOG, CHARACTER_SET_SCHEMA, and CHARACTER_
SET_NAME values resulting from the execution of a <describe statement> before execution
of an <execute statement>, <dynamic open statement>, or <dynamic fetch statement> are
15) Subclause 15.6, ‘‘<prepare statement>’’: The Format and Syntax Rules for a <preparable
implementation-defined statement> are implementation-defined.
16) Subclause 15.8, ‘‘<describe statement>’’:
a) The character set of the data type of <descriptor name> is implementation-defined.
b) If SR does not contain a single routine SQL-invoked R, then the values of PARAMETER_
MODE, PARAMETER_ORDINAL_POSITION, PARAMETER_SPECIFIC_CATALOG,
PARAMETER_SPECIFIC_SCHEMA, and PARAMETER_SPECIFIC_NAME in the descrip-
tor for each <dynamic parameter specification> simply contained in the <call statement> are
set to implementation-defined values.
17) Subclause 16.1, ‘‘<embedded SQL host program>’’:
a) If H does not contain an <embedded authorization declaration> that specifies SCHEMA,

then the <schema name> of the <module authorization clause> of M is implementation-
defined.
b) If H does not contain an <embedded authorization declaration>, then M contains a <module

authorization clause> that specifies ‘‘SCHEMA SN’’, where SN is an implementation-defined
<schema name>.

c) If an <embedded character set declaration> is not specified, then an <embedded character

set declaration> containing an implementation-defined <character set specification> is
implicit.
d) Each <allocate cursor statement> is replaced with a host language procedure or subroutine
call of an implementation-defined procedure that associates the <dynamic cursor name>
with the prepared statement.
e) If an <embedded SQL host program> does not contain an <embedded path specification>,
then the implied module contains an implementation-defined <module path specification>.
18) Subclause 16.5, ‘‘<embedded SQL COBOL program>’’: The COBOL data description clauses, in
addition to the PICTURE, SIGN, USAGE and VALUE clauses, that may appear in a <COBOL
variable definition> are implementation-defined.
19) Subclause 16.9, ‘‘<embedded SQL PL/I program>’’: The PL/I data description clauses, in addition
to the <PL/I type specification> and the INITIAL clause, that may appear in a <PL/I variable
definition> are implementation-defined.
20) Subclause 17.1, ‘‘<direct SQL statement>’’: The <value specification> that represents the null
value is implementation-defined.
21) Subclause 17.1, ‘‘<direct SQL statement>’’: The Format, Syntax Rules, and Access Rules for
<direct implementation-defined statement> are implementation-defined.
22) Subclause 17.1, ‘‘<direct SQL statement>’’: Whether a <direct implementation-defined state-
ment> may be associated with an active transaction is implementation-defined.
23) Subclause 17.1, ‘‘<direct SQL statement>’’: Whether a <direct implementation-defined state-
ment> initiates a transaction is implementation-defined.
Implementation-defined elements 219


Annex C
(informative)
Implementation-dependent elements
Insert this paragraph This Annex references those places where this part of ISO/IEC 9075 states
explicitly that the actions of a conforming implementation are implementation-dependent.
1) Subclause 15.4, ‘‘<get descriptor statement>’’:
a) If an exception condition is raised in a <get descriptor statement>, then the values of all
targets specified by <simple target specification 1>, <simple target specification 2>, and
<simple target specification 3> are implementation-dependent.
b) For a <dynamic parameter specification>, the value of UNNAMED is 1 (one) and the value
of NAME is implementation-dependent.
c) The value retrieved by a <get descriptor statement> for any field whose value is undefined
is implementation-dependent.
2) Subclause 15.5, ‘‘<set descriptor statement>’’: If an exception condition is raised in a <set

descriptor statement>, then the values of all elements of the descriptor specified in the <set
descriptor statement> are implementation-dependent.
3) Subclause 15.6, ‘‘<prepare statement>’’: The validity of an <extended statement name> value or
a <statement name> in an SQL-transaction different from the one in which the statement was
prepared is implementation-dependent.
4) Subclause 15.9, ‘‘<input using clause>’’: When a <describe input statement> is used, the val-
ues for NAME, DATA, and INDICATOR in the SQL dynamic descriptor area structure is
implementation-dependent. If TYPE indicates a character string type, a bit string type, or
a binary large object type, then the values of SCALE and PRECISION are implementation-
dependent. If TYPE indicates an exact or approximate numeric type, then the values
of LENGTH and OCTET_LENGTH are implementation-dependent. If TYPE indicates a
boolean type, then the values of PRECISION, SCALE, LENGTH, and OCTET_LENGTH are
5) Subclause 15.10, ‘‘<output using clause>’’: When a <describe output statement> is executed, the
values of DATA and INDICATOR are implementation-dependent. If TYPE indicates a charac-
ter string type, a bit string type, or a binary large object type, then the values of SCALE and
PRECISION are implementation-dependent. If TYPE indicates an exact or approximate nu-
meric type, then the values of LENGTH and OCTET_LENGTH are implementation-dependent.
If TYPE indicates a boolean type, then the values of PRECISION, SCALE, LENGTH, and
OCTET_LENGTH are implementation-dependent.
Implementation-dependent elements 221

6) Subclause 16.1, ‘‘<embedded SQL host program>’’: The <module name> of the implied <SQL-
client module definition> derived from an <embedded SQL host program> is implementation-
dependent.
7) Subclause 16.1, ‘‘<embedded SQL host program>’’: If an <embedded SQL host program> does
not contain an <embedded authorization statement>, then the <module authorization identifier>
of the implied <SQL-client module definition> derived from the <embedded SQL host program>
8) Subclause 16.1, ‘‘<embedded SQL host program>’’: In each <declare cursor> in the implied
<SQL-client module definition> derived from an <embedded SQL host program>, each <embed-
ded variable name> has been replaced consistently with a distinct <host parameter name> that
9) Subclause 16.1, ‘‘<embedded SQL host program>’’: The <procedure name> of each <externally-
invoked procedure> in the implied <SQL-client module definition> derived from an <embedded
SQL host program> is implementation-dependent.
10) Subclause 16.1, ‘‘<embedded SQL host program>’’: In each <externally-invoked procedure> in
the implied <SQL-client module definition> derived from an <embedded SQL host program>,
each <embedded variable name> has been replaced consistently with a distinct <host parameter
name> that is implementation-dependent.
11) Subclause 16.1, ‘‘<embedded SQL host program>’’:
a) For <SQL procedure statement>s other than <open statement>s, whether one <externally-
invoked procedure> in the implied <SQL-client module definition> derived from an <embed-
ded SQL host program> can correspond to more than one <SQL procedure statement> in
the <embedded SQL host program> is implementation-dependent.
b) In each <externally-invoked procedure> in the implied <SQL-client module definition> de-

rived from an <embedded SQL host program>, the order of the instances of <host parameter
declaration> is
c) implementation-dependent.
12) Subclause 17.1, ‘‘<direct SQL statement>’’: A <commit statement> or a <rollback statement>
is executed. If an unrecoverable error has occurred, or if the direct invocation of SQL termi-
nated unexpectedly, or if any constraint is not satisfied, then a <rollback statement> is per-
formed. Otherwise, the choice of which of these SQL-statements to perform is implementation-
dependent. The determination of whether a direct invocation of SQL has terminated unexpect-
edly is implementation-dependent.

Annex D
(informative)
Deprecated features
Insert this paragraph It is intended that the following features will be removed at a later date from a
revised version of this part of ISO/IEC 9075:
No additional deprecated items.
Deprecated features 223


Annex E
(informative)
Incompatibilities with ISO/IEC 9075:1992
Insert this paragraph This edition of this part of ISO/IEC 9075 introduces some incompatibilities with
the earlier version of Database Language SQL as specified in ISO/IEC 9075:1992.
Insert this paragraph Except as specified in this Annex, every feature and capability of Database
Language SQL as specified in this edition of this part of ISO/IEC 9075 is compatible with ISO/IEC
9075:1992.
1) In ISO/IEC 9075:1992, if a <row value expression> in the <in value list> of an <in predi-
cate> was a <dynamic parameter>, its data type was either:
a) If the <row value expression> was not itself a <dynamic parameter specification>, then
that of the <row value expression> immediately contained in the <in predicate>.
b) Otherwise, the result of applying aggregation to the other <row value expression>s in
the <in value list>.
In ISO/IEC 9075:1999, this special case is eliminated, so that the data type of a <dynamic
parameter specification>, regardless of its location, is determined by applying aggregation to
all <row value expression>s (and the <table subquery>, if present).
This allows <in predicate>s to be consistent with other predicates in the way they deal with
subfields that are dynamic parameters.
2) A number of additional <reserved word>s have been added to the language. These <reserved
word>s are:
— DYNAMIC
3) In ISO/IEC 9075:1992, <describe input statement> described both input and output <dy-
namic parameter specification>s. In ISO/IEC 9075-5:1999, <describe input statement> only
describes input <dynamic parameter specification>s.
4) The following features that appeared in ISO/IEC 9075:1992 have been deleted from this
version of ISO/IEC 9075:
a) <COBOL computational integer>s in <embedded SQL COBOL program>s.
b) The use of SQLERROR as a <condition> in an <embedded exception declaration>.
Incompatibilities with ISO/IEC 9075:1992 225


Annex F
(informative)
SQL feature and package taxonomy
Insert this paragraph This Annex describes a taxonomy of features and packages defined in this part
of ISO/IEC 9075.
Insert this paragraph Table 12, ‘‘SQL/Bindings feature taxonomy and definition for Core SQL’’, con-
tains a taxonomy of the features of Core SQL language that are specified in this part of ISO/IEC
9075. Table 13, ‘‘SQL/Bindings feature taxonomy for features outside Core SQL’’, contains a taxon-
omy of the features of the SQL language not in Core SQL that are specified in this part of ISO/IEC
9075.
Insert this paragraph In these tables, the first column contains a counter that may be used to quickly
locate rows of the table; these values otherwise have no use and are not stable — that is, they are
subject to change in future editions of or even Technical Corrigenda to ISO/IEC 9075 without notice.
Insert this paragraph The ‘‘Feature ID’’ column of Table 12, ‘‘SQL/Bindings feature taxonomy and
definition for Core SQL’’, and of Table 13, ‘‘SQL/Bindings feature taxonomy for features outside Core
SQL’’, specifies the formal identification of each feature and each subfeature contained in the table.
The Feature ID is stable and can be depended on to remain constant. A Feature ID value comprises
either a letter and three digits or a letter, three digits, a hyphen, and one or two additional digits.
Feature ID values containing a hyphen and additional digits indicate ‘‘subfeatures’’ that help to
define complete features, which are in turn indicated by Feature ID values without a hyphen. Only
entire features are used to specify the contents of Core SQL and various packages.
Insert this paragraph The ‘‘Feature Description’’ column of Table 12, ‘‘SQL/Bindings feature taxonomy
and definition for Core SQL’’, and of Table 13, ‘‘SQL/Bindings feature taxonomy for features outside
Core SQL’’, contains a brief description of the feature or subfeature associated with the Feature ID
value.
Insert this paragraph Table 12, ‘‘SQL/Bindings feature taxonomy and definition for Core SQL’’, pro-
vides the only definition of the features comprising the minimal conformance possibility for ISO/IEC
9075, called Core SQL. The final column of this table, labeled ‘‘Implies’’, contains indications of
specific language elements supported in each feature, subject to the constraints of all Syntax Rules,
Access Rules, and Conformance Rules.
Insert this paragraph In Table 12, ‘‘SQL/Bindings feature taxonomy and definition for Core SQL’’,
unless otherwise stated, a feature or subfeature assumes the support of underlying elements of
ISO/IEC 9075.
SQL feature and package taxonomy 227

Table 12—SQL/Bindings feature taxonomy and definition for Core SQL

Feature
ID Feature Name Feature Description
1 B011 Embedded Ada1 Subclause 16.3, ‘‘<embedded SQL Ada pro-

gram>’’
2 B012 Embedded C1 Subclause 16.4, ‘‘<embedded SQL C program>’’
1
3 B013 Embedded COBOL Subclause 16.5, ‘‘<embedded SQL COBOL
program>’’
4 B014 Embedded Fortran1 Subclause 16.6, ‘‘<embedded SQL Fortran
program>’’
5 B015 Embedded MUMPS1 Subclause 16.7, ‘‘<embedded SQL MUMPS
program>’’
6 B016 Embedded Pascal1 Subclause 16.8, ‘‘<embedded SQL Pascal pro-
gram>’’
7 B017 Embedded PL/I1 Subclause 16.9, ‘‘<embedded SQL PL/I pro-
gram>’’
1Aconforming SQL-implementation is required (by Clause 8, "Conformance", in ISO/IEC 9075-1) to support at least one
embedded language.
Table 13—SQL/Bindings feature taxonomy for features outside Core SQL

Feature
ID Feature Name
1 B021 Direct SQL

2 B031 Basic dynamic SQL
3 B032 Extended dynamic SQL
4 B032-01 <describe input> statement
5 B041 Extensions to embedded SQL exception declarations
6 B051 Enhanced execution rights

Index
Index entries appearing in boldface indicate the page where the word, phrase, or BNF nonterminal was
defined; index entries appearing in italics indicate a page where the BNF nonterminal was used in a Format;
and index entries appearing in roman type indicate a page where the word, phrase, or BNF nonterminal
was used in a heading, Function, Syntax Rule, Access Rule, General Rule, Leveling Rule, Table, or other
descriptive text.
applicable from-sql function • 114

—A— applicable privileges • 39
access mode • 189 applicable to-sql function • 110
active • 27, 189, 219 approximate numeric • 105, 152, 159, 170, 173, 179,
active SQL-transaction • 189 185, 221
Ada • 3, 12, 23, 24, 57, 133, 134, 135, 137, 138, 143, <approximate numeric type> • 105
146, 149, 150, 151, 152, 153, 201, 203, 208, ARD • 31, 72, 74, 75, 76, 83, 84, 86, 87, 105, 115,
209, 210, 211, 212, 213, 214, 228 197
ADA • 138, 197 ARE • 134
<Ada array locator variable> • 149, 150, 152, 153, array • 29, 62, 72, 74, 94, 105, 113, 138, 140, 149,
213 150, 152, 153, 154, 155, 156, 158, 159, 160,
<Ada assignment operator> • 149 161, 162, 163, 164, 166, 167, 170, 171, 172,
<Ada BLOB locator variable> • 149, 150, 151, 153, 173, 175, 176, 179, 180, 181, 182, 183, 184,
214 185, 213
<Ada BLOB variable> • 149, 150, 151, 153, 214 ARRAY • 23, 72, 74, 77, 85, 87, 88, 94, 105, 108,
<Ada CLOB locator variable> • 149, 150, 151, 153, 114, 115, 176, 177, 178, 179, 180, 210
214 <array element> • 94
<Ada CLOB variable> • 149, 150, 151, 153, 214 <array element list> • 94
<Ada derived type specification> • 149, 150, 153, array locator variable • 138, 152, 153, 156, 158, 160,
211, 213, 214 163, 164, 166, 170, 171, 175, 179, 180, 184,
<Ada host identifier> • 134, 149, 150, 151, 152 185, 213
<Ada initial value> • 149, 152 array type • 29, 74, 105, 113, 140, 152, 158, 164,
<Ada qualified type specification> • 149, 150, 153, 170, 175, 179, 184
208, 209 AS • 15, 40, 109, 113, 138, 139, 140, 142, 150, 151,
<Ada REF variable> • 149, 150, 152, 153, 211 152, 155, 156, 157, 158, 162, 164, 167, 169,
<Ada type specification> • 149 170, 172, 173, 174, 175, 176, 177, 178, 179,
<Ada unqualified type specification> • 149 181, 182, 183
<Ada user-defined type locator variable> • 149, 150, ASC • 192
152, 153, 212 ASENSITIVE • 119, 206, 211, 215
<Ada user-defined type variable> • 149, 150, 151, assertion • 8, 51, 147
153, 214 <assertion definition> • 51
<Ada variable definition> • 134, 149, 150, 152, 153, assignable • 43, 45, 139, 141
210 assignment • 7, 45, 46, 61, 84, 87, 149
ALLOCATE • 80, 121 associated array data type • 156, 163
<allocate cursor statement> • 15, 16, 17, 18, 19, 21, associated array type • 74, 140, 152, 158, 164, 170,
22, 24, 35, 59, 99, 100, 121, 122, 124, 131, 175, 179, 184
132, 194, 207, 219 associated SQL data type • 141, 151, 157, 164, 169,
<allocate descriptor statement> • 17, 18, 25, 35, 59, 174, 178, 183
80, 81, 85, 194, 204 associated user-defined type • 74, 136, 139, 140,
ambiguous cursor name • 98 141, 144, 151, 152, 157, 158, 164, 165, 169,
<ampersand> • 133, 135 174, 178, 183
AND • 55, 56, 133, 197, 208 associated value • 108
Index 229
associated with • 5, 24, 27, 29, 38, 55, 60, 76, 77, 78, <case operand> • 95
84, 99, 100, 101, 109, 114, 117, 119, 122, 123, <case specification> • 95
124, 127, 129, 188, 189, 194, 227 CAST • 40, 109, 113, 139, 142
<asterisk> • 93, 167, 169 <cast operand> • 94
ATOMIC • 142 <cast specification> • 23, 94, 109, 113
attempt to assign to non-updatable column • 130, 199 <cast target> • 94
attempt to assign to ordering column • 129, 199 catalog • 6, 8, 15, 17, 26, 28, 29, 34, 59, 65, 66, 97,
attribute • 109, 110, 112, 113, 114, 199 106, 194, 210, 217, 218
ATTRIBUTES • 5, 75, 76, 77, 78, 193, 199, 201, 227, CATALOG • 66, 194
228 <catalog name> • 65, 66, 218
AUTHORIZATION • 25, 26, 55, 133 <catalog name characteristic> • 65, 97
<authorization identifier> • 39 <C bit variable> • 154, 155, 156, 159, 160, 210
<C BLOB locator variable> • 155, 158, 160, 214
—B— <C BLOB variable> • 154, 155, 160, 214
based on • 3, 91, 121 <C character type> • 154, 156, 157
base table • 39, 105, 197 <C character variable> • 154, 156, 159
BEGIN • 134, 142 <C class modifier> • 154
<between predicate> • 96 <C CLOB locator variable> • 155, 158, 160, 214
BINARY • 72, 73, 74, 88, 115, 162, 164, 165, 182, <C CLOB variable> • 154, 155, 156, 159, 160, 214
183, 184, 185 <C derived variable> • 154, 160, 210, 211, 213
binary large object • 29, 105, 112, 138, 140, 151, 158, CHAR • 149, 150, 152, 176, 177, 179, 181
164, 169, 174, 178, 183, 221 character • 15, 23, 26, 29, 33, 35, 38, 45, 59, 62, 65,
binary large object locator variable • 138, 151, 158, 66, 67, 68, 69, 72, 73, 75, 76, 78, 80, 88, 91,
164, 169, 174, 178, 183 92, 93, 97, 99, 104, 105, 113, 115, 118, 121,
<binary large object string type> • 105 134, 135, 136, 138, 140, 143, 144, 149, 150,
BIT • 72, 73, 77, 88, 92, 115, 149, 152, 153, 155, 151, 152, 153, 154, 155, 156, 157, 158, 159,
156, 159, 160, 161, 163, 165, 166, 167, 168, 160, 161, 162, 163, 164, 165, 166, 167, 168,
170, 171, 176, 177, 179, 180, 181, 184, 185, 169, 170, 171, 172, 173, 174, 176, 178, 179,
210 180, 181, 183, 184, 185, 193, 194, 199, 208,
<bit length expression> • 92 209, 210, 211, 218, 219, 221
bit string type • 105, 221 CHARACTER • 23, 72, 73, 74, 77, 88, 92, 93, 97,
<bit string type> • 105 115, 149, 150, 152, 154, 155, 156, 157, 159,
BIT_LENGTH • 159 161, 163, 165, 167, 168, 170, 172, 173, 176,
BLOB • 77, 138, 140, 149, 150, 151, 153, 154, 155, 177, 179, 181, 182, 184
157, 158, 159, 160, 161, 162, 163, 164, 166, character large object • 29, 45, 62, 113, 138, 140,
167, 169, 171, 172, 173, 174, 175, 176, 177, 151, 158, 164, 169, 174, 178, 183
178, 180, 181, 182, 183, 185, 214, 215 character large object locator variable • 62, 151, 158,
boolean • 94, 152, 170, 179, 221 164, 169, 174, 178, 183
BOOLEAN • 23, 72, 73, 77, 94, 149, 152, 159, 165, <character match value> • 97
170, 176, 179, 184 <character pattern> • 97
<boolean primary> • 94 character repertoire • 159
BOTH • 65, 66, 67, 80, 99, 121 <character representation> • 149, 152, 156, 158, 161,
branch • 24, 217 165, 181, 184
BY • 191 character set • 15, 26, 29, 33, 35, 38, 67, 72, 73, 75,
76, 88, 92, 93, 97, 105, 136, 138, 143, 144,
—C— 152, 153, 157, 159, 160, 163, 165, 166, 168,
C • 3, 23, 24, 105, 133, 134, 135, 137, 138, 143, 146, 170, 171, 173, 179, 180, 184, 185, 199, 208,
154, 155, 156, 157, 158, 159, 160, 197, 201, 209, 210, 211, 218, 219
203, 209, 210, 211, 212, 213, 214, 228 <character set name> • 67, 105
<call statement> • 20, 21, 78, 97, 98, 105, 218 <character set name characteristic> • 67, 97
candidate key • 103, 104 <character set specification> • 33, 73, 134, 149, 150,
cardinality • 47, 72, 74, 105, 115, 125 152, 153, 154, 155, 159, 160, 161, 165, 166,
CARDINALITY • 31, 72, 74, 75, 76, 83, 84, 86, 87, 167, 170, 171, 172, 176, 179, 180, 181, 184,
105, 115 185, 208, 209, 210, 219
cardinality violation • 125 <character string literal> • 33, 67
<C array locator variable> • 155, 156, 158 <character string type> • 104
<C array specification> • 154, 155, 156, 159 character type • 156, 157, 162, 163, 165, 166, 209
cascade off • 144 CHARACTER_SET_CATALOG • 72, 73, 75, 83, 87,
<case abbreviation> • 95 88, 89, 105, 218
<case expression> • 47

CHARACTER_SET_NAME • 57, 72, 73, 75, 83, 87, collection type • 71, 152, 156, 158, 163, 164, 170,
88, 89, 105, 218 175, 179, 183, 184
CHARACTER_SET_SCHEMA • 72, 73, 75, 83, 87, <collection type> • 150, 152, 156, 158, 162, 163, 164,
88, 89, 105, 218 167, 170, 173, 175, 177, 179, 182, 183, 184
<char length expression> • 92 <collection value expression> • 47
CHECK • 197 <colon> • 134, 149, 176
check constraint • 49 column • 16, 24, 26, 39, 41, 47, 84, 86, 95, 101, 102,
<check constraint definition> • 49 103, 104, 112, 120, 129, 130, 141, 151, 157,
<C host identifier> • 134, 154, 155, 156, 157, 158, 164, 169, 174, 178, 183, 191, 199, 205, 208,
159 211, 227
<C initial value> • 154, 155, 156, 158 column list • 95
CLASS • 57, 58 <column name> • 130, 141, 191
CLOSE • 126, 194 <column name list> • 120, 130, 205, 208, 211
<close statement> • 19, 21, 22, 144 <column reference> • 39, 191
<C NCHAR variable> • 154, 155, 156, 157, 159 <comma> • 83, 86, 107, 111, 149, 154, 155, 156,
<C NCHAR VARYING variable> • 154, 155, 156, 157, 167, 172, 176, 181
159 <commit statement> • 55, 63, 188, 222
<C NCLOB variable> • 154, 155, 156, 157, 159 <comparison predicate> • 96, 192
<C numeric variable> • 154 compatible • 47, 110, 114, 225
COBOL • 3, 12, 13, 23, 24, 133, 134, 135, 137, 138, compilation unit • 1, 24, 135, 150, 156, 162, 168, 173,
143, 146, 161, 162, 163, 164, 165, 166, 197, 177, 182
201, 203, 209, 210, 211, 212, 213, 214, 215, completion condition • 27, 84, 103, 118, 125, 190,
219, 225, 228 191, 193
<COBOL array locator variable> • 161, 162, 163, 164, <comp op> • 192
166, 213 <concatenation operator> • 93
<COBOL binary integer> • 162, 165 condition • 27, 45, 46, 49, 51, 60, 65, 66, 67, 68, 69,
<COBOL bit type> • 161, 163, 165, 166, 210 73, 80, 82, 84, 85, 87, 88, 89, 92, 97, 98, 99,
<COBOL BLOB locator variable> • 161, 162, 164, 100, 101, 102, 103, 107, 108, 109, 110, 111,
166, 215 112, 113, 114, 116, 118, 121, 122, 123, 125,
<COBOL BLOB variable> • 161, 164, 166, 215 127, 129, 130, 144, 145, 146, 147, 148, 188,
<COBOL character type> • 161, 163, 165, 166, 209 189, 190, 191, 193, 199, 208, 217, 221, 225
<COBOL CLOB locator variable> • 161, 162, 164, <condition> • 145, 146, 225
166, 215 <condition action> • 145, 147
<COBOL CLOB variable> • 161, 163, 164, 166, 215 conforming SQL-implementation • 228
<COBOL derived type specification> • 161, 166, 213, CONNECT • 188
214 CONNECTION • 188
<COBOL host identifier> • 134, 161, 163, 164, 165 connection does not exist • 189
<COBOL integer type> • 161, 162 connection exception • 189
<COBOL national character type> • 161, 162, 163 <connect statement> • 188
<COBOL NCLOB variable> • 161, 163 CONSTRAINT • 145, 146, 147, 148, 208
<COBOL nines> • 162 constraint mode • 189
<COBOL nines specification> • 162 <constraint name> • 145, 147
<COBOL numeric type> • 161, 162, 165 constraint violation • 146
<COBOL REF variable> • 161, 162, 165, 166, 211 contain • 3, 5, 15, 24, 25, 26, 28, 29, 33, 34, 36, 37,
<COBOL type specification> • 161, 166, 210, 211 38, 39, 40, 41, 45, 46, 49, 50, 51, 52, 53, 56,
<COBOL user-defined type locator variable> • 161, 62, 65, 66, 67, 68, 69, 80, 81, 82, 85, 90, 92,
162, 165, 166, 212 93, 94, 95, 96, 97, 98, 99, 100, 101, 105, 106,
<COBOL user-defined type variable> • 161, 162, 164, 107, 110, 111, 115, 116, 117, 118, 119, 121,
166, 214 122, 123, 124, 125, 126, 127, 128, 129, 130,
<COBOL variable definition> • 134, 161, 163, 165, 131, 132, 135, 136, 137, 138, 139, 140, 141,
219 143, 144, 146, 147, 148, 150, 152, 153, 156,
collation • 105 157, 158, 160, 163, 165, 166, 168, 170, 171,
<collation name> • 105 173, 175, 177, 179, 180, 182, 184, 185, 187,
COLLATION_CAT • 75, 83, 86, 105, 218 189, 191, 204, 205, 206, 207, 208, 209, 210,
COLLATION_CATALOG • 75, 83, 86, 105, 218 211, 212, 213, 217, 218, 219, 222, 225, 227
COLLATION_NAME • 75, 83, 86, 105, 218
COLLATION_SCHEM • 75, 83, 86, 105, 218
COLLATION_SCHEMA • 75, 83, 86, 105, 218
collection • 47, 71, 150, 152, 156, 158, 162, 163, 164,
167, 170, 173, 175, 177, 179, 182, 183, 184
Index 231
contained in • 5, 15, 26, 28, 33, 34, 37, 39, 41, 56,
62, 80, 85, 92, 93, 94, 95, 96, 97, 98, 101, 105, —D—
107, 111, 117, 121, 123, 127, 129, 130, 135, Data • 3, 12, 45, 47, 61, 75, 77, 78, 84, 86, 165, 193,
136, 137, 138, 139, 140, 141, 146, 147, 150, 225
152, 153, 156, 158, 160, 163, 165, 166, 168, DATA • 75, 83, 84, 85, 86, 87, 103, 108, 109, 114,
170, 171, 173, 175, 179, 180, 182, 184, 185, 115
191, 212, 213, 217, 218, 225, 227 data exception • 45, 46, 84, 85, 87
containing • 5, 25, 26, 29, 39, 98, 100, 101, 116, 118, data type • 23, 26, 29, 38, 47, 57, 65, 66, 67, 68, 69,
119, 123, 124, 126, 127, 129, 135, 136, 146, 71, 72, 73, 74, 75, 76, 77, 78, 87, 88, 89, 92,
147, 150, 157, 163, 168, 177, 182, 219, 227 94, 95, 105, 108, 109, 110, 112, 113, 114, 137,
containing schema • 39 138, 139, 140, 141, 151, 152, 153, 156, 157,
contains • 15, 24, 25, 26, 28, 33, 38, 40, 46, 66, 85, 158, 159, 160, 163, 164, 165, 166, 169, 170,
92, 94, 98, 106, 116, 118, 122, 123, 136, 137, 171, 173, 174, 175, 178, 179, 180, 183, 184,
138, 139, 140, 143, 146, 147, 148, 150, 156, 185, 199, 210, 214, 215, 218, 225
163, 168, 177, 179, 182, 189, 218, 219, 227 <data type> • 26, 94, 137
<contextually typed row value expression> • 95, 96 data type transform function violation • 110, 114, 199
CONTINUE • 145 DATA_TYPE • 57, 74
<correlation name> • 191 date • 11, 16, 17, 18, 19, 20, 21, 22, 23, 25, 59, 72,
corresponding fields • 92 77, 79, 91, 94, 97, 98, 103, 104, 105, 117, 120,
corresponding subfields • 92 129, 130, 132, 144, 187, 194, 205, 206, 207,
corresponds to • 94, 95, 96, 97, 139, 140, 142 208, 211, 223
COUNT • 31, 57, 75, 83, 84, 86, 102, 107, 112 DATE • 23, 77, 78
created by • 28, 35 datetime type • 72, 105
<C REF variable> • 155, 156, 158, 160, 211 <datetime type> • 72, 105
<C storage class> • 154 DATETIME_INTERVAL_CODE • 57, 72, 75, 83, 87,
current • 3, 15, 16, 18, 19, 27, 28, 29, 34, 35, 37, 39, 89, 105, 199
41, 55, 63, 65, 66, 67, 68, 69, 82, 84, 87, 109, DATETIME_INTERVAL_PRECISION • 72, 75, 83, 87,
114, 122, 124, 144, 162, 163, 188, 189, 217, 88, 89, 105
218 DAY • 78, 89, 94
CURRENT • 127, 129, 131, 132 DEALLOCATE • 55, 82, 99, 100, 118, 188, 194
current authorization identifier • 188 <deallocate descriptor statement> • 17, 18, 25, 55,
current privileges • 39, 41, 144 59, 82, 188, 194, 204
current SQL-session • 28, 29, 34, 35, 65, 66, 67, 68, <deallocate prepared statement> • 16, 17, 18, 24, 26,
69, 109, 114, 122, 188 59, 100, 194, 207
CURRENT_DEFAULT_TRANSFORM_GROUP • 29, DEC • 172, 173, 182
31, 37, 38 DECIMAL • 72, 73, 77, 88, 173, 182, 184
CURRENT_PATH • 28, 191, 194 DECLARE • 119, 133, 134, 142, 181, 184
CURRENT_ROLE • 191 <declare cursor> • 20, 21, 22, 119, 122, 131, 132,
CURRENT_TRANSFORM_GROUP_FOR_TYPE • 133, 136, 138, 143, 222
29, 31, 37, 38 declared dynamic cursor • 15, 98
CURRENT_USER • 191 declared type • 35, 37, 45, 65, 66, 67, 68, 73, 80, 84,
CURSOR • 119, 121 86, 91, 92, 93, 94, 95, 96, 97, 103, 108, 109,
<cursor holdability> • 119 110, 112, 118, 139
<cursor intent> • 121 DEFAULT • 29, 31, 37, 38, 69, 188
<cursor name> • 25, 34, 55, 98, 119, 123, 124, 126, default SQL-session • 188
127, 129, 130, 131, 132, 136 deferred • 27
<cursor returnability> • 119, 120, 205, 215 DEFINED • 57, 72, 74, 76, 77, 84, 87, 89, 90, 105
<cursor scrollability> • 119, 120, 205, 208 defining instance • 177
<cursor sensitivity> • 119, 121 DEGREE • 31, 72, 74, 75, 83, 87, 88, 105
<cursor specification> • 24, 91, 99, 100, 119, 121, DELETE • 127, 131, 194
122, 123, 129, 130, 131, 132 <delete statement: positioned> • 19, 21, 23, 127,
cursor specification cannot be executed • 116, 199 131, 144
<C user-defined type locator variable> • 155, 156, <delete statement: searched> • 19, 20, 22, 91, 187
158, 160, 212 <delimiter token> • 31
<C user-defined type variable> • 155, 157, 160, 214 dependencies • 85, 205, 215
<C VARCHAR variable> • 154, 155, 156, 159 dependent • 15, 26, 28, 61, 85, 88, 89, 99, 103, 104,
<C variable definition> • 134, 154, 156, 157, 158, 114, 138, 139, 140, 141, 142, 147, 188, 191,
159, 160, 209 192, 221, 222
<C variable specification> • 154 depends on • 18
<derived column> • 104

derived table • 39 <dynamic declare cursor> • 15, 16, 19, 20, 21, 22,
describe • 9, 17, 18, 23, 24, 26, 59, 85, 90, 101, 102, 24, 55, 56, 99, 119, 120, 123, 124, 126, 127,
103, 104, 105, 106, 107, 108, 111, 112, 152, 129, 131, 132, 133, 136, 139, 143, 204, 205,
153, 159, 165, 170, 173, 179, 184, 185, 194, 206, 208, 211, 215, 216
205, 207, 218, 221, 225, 227, 228 <dynamic delete statement: positioned> • 16, 17, 18,
DESCRIBE • 101, 194 19, 21, 23, 25, 59, 127, 128, 144, 194, 206
<described object> • 101 <dynamic fetch statement> • 16, 17, 18, 19, 21, 22,
describe input • 17, 18, 24, 26, 101, 102, 103, 106, 24, 25, 59, 90, 111, 112, 124, 144, 194, 206,
108, 207, 221, 225, 228 218
<describe input statement> • 17, 18, 24, 101, 102, <dynamic open statement> • 16, 17, 18, 19, 21, 22,
103, 106, 108, 207, 221, 225 24, 59, 90, 107, 122, 123, 144, 194, 206, 218
describe output • 17, 18, 24, 26, 101, 102, 103, 106, <dynamic parameter specification> • 26, 37, 38, 40,
112, 205, 221 42, 49, 50, 51, 52, 53, 92, 98, 101, 102, 103,
<describe output statement> • 17, 18, 24, 101, 102, 104, 105, 106, 107, 108, 111, 112, 116, 118,
103, 106, 112, 205, 221 123, 187, 204, 218, 221, 225
<describe statement> • 59, 85, 90, 101, 194, 218 dynamic result sets returned • 122
Description • 71, 197, 201, 227, 228 <dynamic select statement> • 17, 19, 20, 22, 23, 24,
descriptor • 9, 17, 18, 25, 26, 29, 34, 35, 36, 55, 59, 60, 91, 92, 102, 103, 107, 111, 116, 118, 194
71, 72, 73, 74, 75, 76, 78, 79, 80, 81, 82, 83, <dynamic single row select statement> • 17, 18, 20,
84, 85, 86, 87, 88, 89, 90, 101, 102, 103, 104, 22, 23, 24, 25, 39, 60, 91, 92, 99, 102, 103,
106, 107, 108, 110, 111, 112, 114, 115, 122, 111, 112, 116, 118, 125, 194, 206
188, 194, 199, 200, 204, 205, 206, 207, 218, dynamic SQL error • 80, 84, 85, 87, 88, 89, 99, 107,
221 108, 109, 110, 111, 112, 113, 114, 116, 122,
DESCRIPTOR • 55, 57, 58, 80, 82, 83, 86, 101, 111, 123, 199
188, 194 <dynamic update statement: positioned> • 16, 17, 18,
descriptor area • 25, 26, 29, 35, 55, 71, 72, 73, 74, 20, 21, 23, 25, 59, 129, 130, 144, 194, 206
75, 76, 80, 82, 83, 84, 85, 86, 87, 88, 89, 102, DYNAMIC_FUNCTION • 31, 75, 78, 83, 86, 102, 193
103, 104, 107, 108, 112, 114, 115, 200, 218, DYNAMIC_FUNCTION_CODE • 31, 75, 78, 83, 86,
221 102, 193
<descriptor item name> • 83, 84, 85, 86, 87
<descriptor name> • 25, 34, 35, 36, 55, 80, 81, 82, —E—
83, 84, 85, 86, 87, 90, 101, 102, 107, 108, 110, **Editor’s Note** • 97, 139
111, 112, 115, 188, 204, 206, 207, 218 effective • 15, 16, 28, 29, 55, 56, 60, 66, 87, 108,
diagnostics area • 118, 188, 189, 190, 193 109, 110, 112, 113, 114, 122, 137, 188, 192,
<digit> • 145 217
DIRECT • 197 effectively • 15, 16, 28, 29, 55, 56, 60, 66, 87, 109,
<direct implementation-defined statement> • 187, 110, 113, 114, 122, 137, 188, 192, 217
188, 189, 219 <element reference> • 92
<directly executable statement> • 187 elements • 31, 43, 89, 217, 221, 227
direct result of executing an SQL-statement • 5 element type • 71, 74
<direct select statement: multiple rows> • 17, 18, 20, embedded • 1, 6, 12, 13, 16, 18, 19, 20, 21, 22, 23,
21, 22, 39, 41, 187, 191, 194 24, 25, 26, 37, 38, 43, 49, 50, 51, 52, 53, 61,
<direct SQL data statement> • 187, 190 107, 133, 134, 135, 136, 137, 138, 139, 140,
<direct SQL statement> • 13, 27, 28, 29, 34, 60, 65, 141, 143, 144, 145, 146, 147, 148, 149, 150,
66, 67, 68, 187, 188, 189, 190, 201, 204, 217 152, 153, 154, 156, 158, 160, 161, 162, 163,
distinct • 96, 138, 140, 143, 192, 222 165, 166, 167, 168, 170, 171, 172, 173, 175,
<distinct predicate> • 96 176, 177, 179, 180, 181, 182, 184, 185, 187,
domain • 94 201, 203, 204, 207, 208, 209, 212, 214, 217,
<domain name> • 94 218, 219, 222, 225, 228
dormant • 60, 188, 189 EMBEDDED • 197
DOUBLE • 72, 73, 77, 149, 152, 159, 167, 170 <embedded authorization clause> • 133, 138
<double period> • 31, 149, 176 <embedded authorization declaration> • 24, 133, 136,
DYNAMIC • 31, 55, 56, 57, 75, 78, 83, 86, 102, 133, 138, 143, 144, 208, 218
193, 194, 208, 225 <embedded authorization identifier> • 133, 134
<dynamic close statement> • 16, 17, 18, 19, 21, 22, <embedded character set declaration> • 134, 136,
24, 59, 126, 144, 194, 206 138, 143, 144, 208, 209, 219
dynamic cursor • 15, 16, 25, 35, 36, 98, 123, 124, <embedded exception declaration> • 18, 133, 137,
126, 127, 129, 130, 131, 132, 204, 219 139, 143, 145, 146, 147, 148, 225
<dynamic cursor name> • 34, 35, 36, 123, 124, 126, <embedded path specification> • 133, 134, 136, 138,
127, 129, 130, 204, 219 144, 212, 219
Index 233
<embedded SQL Ada program> • 24, 133, 135, 137, <execute immediate statement> • 5, 15, 17, 18, 24,
138, 143, 146, 149, 150, 152, 153, 203 25, 26, 27, 28, 29, 34, 56, 59, 65, 66, 67, 68,
<embedded SQL begin declare> • 134, 135, 143, 177 118, 194, 205, 217, 218
<embedded SQL COBOL program> • 24, 133, 135, <execute statement> • 5, 17, 18, 24, 27, 59, 68, 90,
137, 138, 143, 146, 161, 162, 163, 165, 166, 99, 107, 111, 116, 117, 194, 205, 218
203, 225 <extended cursor name> • 25, 34, 35, 36, 98, 101,
<embedded SQL C program> • 24, 133, 135, 137, 102, 121, 122, 123, 127, 129, 206
138, 143, 146, 154, 156, 158, 160, 203 extended dynamic cursor • 15, 16, 98
<embedded SQL declare section> • 24, 134, 135, <extended statement name> • 25, 34, 35, 36, 63, 99,
143, 144, 150, 156, 162, 168, 173, 177, 182, 121, 122, 206, 221
208, 209 externally-invoked procedure • 1, 5, 15, 19, 20, 24,
<embedded SQL end declare> • 134, 135, 143, 177 26, 28, 55, 56, 57, 60, 117, 138, 139, 142, 143,
<embedded SQL Fortran program> • 24, 133, 135, 189, 217, 222
137, 138, 143, 146, 167, 168, 170, 171, 203 <externally-invoked procedure> • 5, 15, 19, 20, 24,
<embedded SQL host program> • 13, 24, 26, 133, 26, 28, 55, 56, 57, 60, 117, 138, 139, 142, 143,
135, 136, 137, 144, 146, 147, 219, 222 189, 217, 222
<embedded SQL MUMPS declare> • 134, 135, 143 external routine • 45
<embedded SQL MUMPS program> • 24, 133, 135,
137, 138, 146, 172, 173, 175, 203 —F—
<embedded SQL Pascal program> • 24, 133, 135, Feature B011 • 153, 203
137, 138, 143, 146, 176, 177, 179, 180, 204 Feature B012 • 160, 203
<embedded SQL PL/I program> • 24, 133, 135, 137, Feature B013 • 166, 203
138, 143, 146, 147, 181, 182, 184, 185, 204 Feature B014 • 171, 203
<embedded SQL statement> • 24, 26, 37, 133, 135, Feature B015 • 175, 203
136, 137, 143, 144, 150, 156, 162, 163, 168, Feature B016 • 180, 204
173, 177, 182 Feature B017 • 185, 204
<embedded transform group specification> • 133, Feature B021 • 190, 204
134, 136, 138, 144, 214 Feature B031 • 36, 38, 56, 60, 81, 82, 85, 90, 99,
<embedded variable name> • 37, 38, 43, 52, 53, 61, 106, 110, 115, 117, 118, 119, 120, 123, 124,
134, 138, 140, 144, 222 125, 126, 128, 130, 204, 205, 206, 208, 211,
<embedded variable specification> • 37, 38, 49, 50, 215
51, 107, 187 Feature B032 • 36, 81, 82, 85, 90, 100, 106, 110,
empty • 124, 125, 191, 192 115, 117, 122, 131, 132, 206, 207
END • 134 Feature B041 • 148, 207, 208
END-EXEC • 133, 135 Feature B051 • 56, 144, 208
<equals operator> • 83, 86, 149, 156 Feature F341 • 120, 205, 208
error in assignment • 84, 87 Feature F361 • 144, 208
<escape character> • 97 Feature F421 • 120, 205, 208
<escape octet> • 97 Feature F451 • 67, 144, 153, 160, 166, 171, 180,
exact numeric • 37, 75, 76, 80, 84, 86, 105, 152, 153, 185, 208, 209, 210, 211
159, 165, 170, 173, 179, 184, 185, 193 Feature F461 • 67, 208, 209, 210, 211
<exact numeric type> • 105, 153 Feature F511 • 153, 160, 166, 171, 180, 185, 210
exception • 16, 18, 19, 20, 21, 22, 27, 45, 46, 60, 65, Feature F611 • 38, 210
66, 67, 68, 69, 80, 82, 84, 85, 87, 88, 89, 92, Feature F651 • 65, 210
97, 98, 99, 100, 101, 102, 107, 108, 109, 110, Feature F761 • 65, 66, 67, 208, 210, 211
111, 112, 113, 114, 116, 118, 121, 122, 123, Feature F791 • 119, 205, 206, 211, 215
125, 127, 129, 130, 133, 137, 139, 143, 144, Feature F831 • 120, 205, 208, 211
145, 146, 147, 148, 188, 189, 190, 193, 207, Feature S024 • 120, 211
208, 221, 225, 228 Feature S041 • 153, 160, 166, 171, 175, 180, 185,
EXCEPTION • 145, 148, 207 211, 212
exception condition • 27, 45, 46, 60, 65, 66, 67, 68, Feature S071 • 68, 144, 212
69, 80, 82, 84, 85, 87, 88, 89, 92, 97, 98, 99, Feature S231 • 153, 160, 166, 171, 175, 180, 185,
100, 101, 102, 107, 108, 109, 110, 111, 112, 212, 213
113, 114, 116, 118, 121, 122, 123, 125, 127, Feature S232 • 153, 160, 166, 171, 175, 180, 185,
129, 144, 188, 189, 190, 221 213
EXEC • 133, 135 Feature S241 • 69, 144, 153, 160, 166, 171, 175,
EXECUTE • 57, 116, 118, 144, 194 180, 185, 213, 214
executed immediately • 22, 26 Feature T041 • 153, 160, 166, 171, 175, 180, 185,
214, 215
Feature T231 • 119, 206, 211, 215

Feature T301 • 85, 205, 215 <group specification> • 136, 139, 141
Feature T471 • 120, 205, 215 GROUP_NAME • 57
Feature T551 • 120, 216
Fetch • 124 —H—
FETCH • 124, 194 handle • 23, 133
<fetch orientation> • 124 <handler declaration> • 133
<fetch statement> • 19, 21, 22, 144 <header item name> • 83, 84, 85, 86, 89
<fetch target list> • 124 HOLD • 119, 121
fields • 25, 71, 80, 88, 92, 103, 116, 199, 225 holdable • 15, 29
final • 227 holdable locator • 15
fixed-length • 159 <hold locator statement> • 23
FLOAT • 72, 73, 77, 89, 182, 185 <host identifier> • 134, 137, 143
FOR • 15, 26, 55, 56, 69, 119, 120, 121, 133, 205, <host label identifier> • 145, 146, 147, 148
208, 211 host language • 1, 23, 135, 137, 139, 140, 143, 146,
Fortran • 3, 12, 13, 23, 24, 133, 134, 135, 137, 138, 147, 148, 219
143, 146, 167, 168, 169, 170, 171, 201, 203, <host parameter data type> • 138, 140
209, 210, 211, 212, 213, 214, 215, 228 <host parameter declaration> • 138, 139, 140, 143,
FORTRAN • 138, 197 222
<Fortran array locator variable> • 167, 170, 171, 213 <host parameter name> • 138, 140, 222
<Fortran BLOB locator variable> • 167, 169, 171, 215 <host parameter specification> • 43, 107
<Fortran BLOB variable> • 167, 169, 171, 215 <host PL/I label variable> • 145, 146, 147, 148
<Fortran CLOB locator variable> • 167, 169, 171, 215 <host variable definition> • 134, 137, 143, 144, 208
<Fortran CLOB variable> • 167, 168, 169, 171, 215 HOUR • 78, 89, 97
<Fortran derived type specification> • 167, 171, 211,
213, 214 —I—
<Fortran host identifier> • 134, 167, 168, 169, 170 identified • 25, 27, 38, 62, 69, 85, 89, 94, 100, 102,
<Fortran REF variable> • 167, 168, 170, 171, 211 108, 109, 112, 113, 121, 122, 123, 124, 126,
<Fortran type specification> • 167, 168, 171, 209, 210 127, 129, 130, 131, 132, 140, 141, 151, 152,
<Fortran user-defined type locator variable> • 167, 157, 158, 164, 165, 169, 170, 174, 175, 178,
169, 171, 212 179, 183, 184, 217
<Fortran user-defined type variable> • 167, 169, 171, identifier • 12, 25, 26, 27, 34, 39, 55, 69, 71, 78, 80,
214 97, 99, 102, 121, 133, 134, 137, 143, 145, 146,
<Fortran variable definition> • 134, 167, 168, 170 147, 148, 149, 150, 151, 152, 154, 155, 156,
FOUND • 145, 148 157, 158, 159, 161, 163, 164, 165, 167, 168,
<free locator statement> • 20, 21, 23, 62 169, 170, 172, 173, 174, 175, 176, 177, 178,
FROM • 65, 66, 67, 68, 69, 80, 91, 93, 99, 118, 121, 179, 181, 182, 183, 184, 188, 193, 194, 222
124, 127, 131 <identifier> • 25, 34, 69, 80, 99, 121, 193
from-sql function • 114 identify • 25, 28, 29, 74, 92, 99, 100, 101, 102, 106,
FS • 114, 141, 142 112, 113, 116, 121, 122, 123, 127, 129, 139,
FUNCTION • 31, 57, 75, 78, 83, 86, 102, 193 153, 160, 166, 171, 175, 180, 185, 212, 213
immediate • 5, 15, 16, 17, 18, 20, 22, 24, 25, 26, 27,
—G— 28, 29, 34, 40, 56, 59, 62, 65, 66, 67, 68, 71,
G • 66, 194 72, 74, 80, 88, 92, 94, 95, 97, 98, 103, 107,
generally contain • 52 108, 117, 118, 121, 137, 156, 163, 182, 189,
<general value specification> • 28, 29, 37, 38, 107, 194, 205, 217, 218, 225
204 IMMEDIATE • 118, 194
GET • 83, 194 immediately contain • 28, 40, 80, 92, 94, 95, 97, 98,
<get descriptor information> • 83, 85 107, 117, 137, 225
<get descriptor statement> • 17, 18, 25, 59, 83, 84, immediately subordinate descriptor areas • 71, 72, 88
85, 194, 204, 221 immediately subordinate descriptors • 71
<get diagnostics statement> • 193 implementation-defined • 15, 21, 24, 27, 28, 29, 35,
<get header information> • 83, 84, 85 38, 72, 73, 74, 80, 88, 89, 90, 91, 92, 94, 97,
<get item information> • 83, 84, 85 104, 105, 109, 112, 113, 118, 136, 138, 152,
GLOBAL • 34, 35, 98 158, 159, 165, 170, 173, 175, 179, 184, 187,
GO • 145, 146, 147, 148 188, 189, 190, 192, 193, 194, 197, 210, 217,
GOTO • 145 218, 219
<go to> • 145, 146, 147, 148 implementation-dependent • 15, 26, 28, 61, 85, 88,
<goto target> • 145, 146 89, 99, 103, 104, 114, 138, 139, 140, 141, 142,
<greater than operator> • 192 147, 188, 191, 192, 221, 222
<group name> • 136, 139, 141 IN • 93, 106, 197
Index 235
include • 25, 39, 41, 98, 105, 143, 144, 156, 159, 182 invalid SQL-invoked procedure reference • 122, 199
Indicator • 38, 210 invalid SQL statement • 144
INDICATOR • 37, 75, 83, 85, 87, 103, 108, 114, 149, invalid SQL statement identifier • 99
153, 221 invalid SQL statement name • 100, 101, 116, 121,
indicator overflow • 45 123, 127, 129
indicator parameter • 38, 45, 46, 85, 210, 218 invalid transaction state • 60, 189, 190
<indicator parameter> • 38, 210, 218 invalid transform group name specification • 69, 200
<indicator variable> • 37, 38, 42, 210, 218 <in value list> • 225
Information Schema • 26 IS • 149, 150, 151, 152, 154, 155, 156, 157, 158,
INOUT • 79, 98 159, 161, 162, 163, 164, 165, 167, 168, 169,
<in predicate> • 96, 225 170, 172, 173, 174, 175, 176, 177, 178, 179,
INPUT • 98, 101 181, 182, 183, 184, 197
input parameter • 114 isolation level • 189
input SQL parameter • 116 ITEM • 58
<input using clause> • 107, 116, 123 <item number> • 83, 84, 85, 86, 87
INSENSITIVE • 119, 121, 205, 211
<insert column list> • 95 —K—
<insert statement> • 19, 20, 22, 91, 95, 187 KEY • 75, 83, 85, 86, 102, 103, 104, 205, 215
instance • 106, 177, 222 <key word> • 75, 84, 86
insufficient item descriptor areas • 103, 200 KEY_MEMBER • 75, 83, 85, 86, 104, 205, 215
INT • 149, 152, 172, 173 KEY_TYPE • 75, 83, 86, 102, 103, 104
INTEGER • 72, 73, 77, 152, 159, 165, 167, 169, 170,
173, 176, 178, 179, 185 —L—
integrity constraint violation • 146 LANGUAGE • 197
interface • 25 <language clause> • 15, 105, 138
INTERVAL • 23, 40, 57, 72, 75, 77, 83, 87, 88, 89, LARGE • 23, 72, 73, 74, 88, 115, 159
92, 94, 97, 105, 199 <large object length> • 150, 151, 155, 156, 157, 161,
<interval fractional seconds precision> • 72, 94, 105 162, 163, 167, 168, 169, 172, 174, 176, 177,
<interval leading field precision> • 72, 94, 105 178, 181, 183
<interval primary> • 40 large object string • 105
<interval qualifier> • 40, 72, 78, 92, 105 leaf underlying table • 127, 129, 131, 132
interval type • 72, 93, 105 <left bracket> • 154, 176
<interval type> • 72, 105 <left paren> • 12, 13, 92, 93, 133, 135, 149, 150,
<interval value expression> • 40, 97 155, 161, 162, 167, 172, 176, 181
<interval value function> • 40 LENGTH • 72, 73, 74, 75, 76, 83, 84, 86, 87, 88, 89,
INTERVAL_PRECISION • 72, 75, 83, 87, 88, 89, 105 104, 105, 115, 151, 159, 164, 169, 174, 178,
INTO • 111 183, 218, 221
<into argument> • 111, 112, 115 <length> • 26, 92, 149, 150, 152, 154, 156, 157, 159,
<into arguments> • 111, 112, 115 161, 162, 163, 165, 167, 168, 170, 172, 173,
<into descriptor> • 111, 112, 114 176, 177, 179, 180, 181, 182, 183, 184, 210
<introducer> • 33 length in positions • 105
invalid • 46, 60, 65, 66, 67, 68, 69, 80, 82, 84, 87, 88, <less than operator> • 192
89, 98, 99, 100, 101, 102, 107, 108, 111, 112, <like predicate> • 97
116, 121, 122, 123, 127, 129, 144, 189, 190, <literal> • 33, 34, 81, 82, 85, 86, 90, 91, 110, 115,
199, 200 191, 206, 207
invalid catalog name • 65 LOB • 153, 160, 166, 171, 175, 180, 185, 214, 215
invalid character set name • 67, 199 LOCAL • 34, 35, 98
invalid cursor name • 98, 99, 102, 121, 123, 127, 129 <local or schema qualified name> • 34
invalid cursor state • 100 local temporary table • 28, 116
invalid DATA target • 87 local time • 97
invalid DATETIME_INTERVAL_CODE • 89 locator • 6, 15, 20, 21, 23, 29, 45, 62, 74, 109, 112,
invalid descriptor count • 108, 112, 199 113, 114, 136, 138, 139, 140, 141, 149, 150,
invalid descriptor index • 80, 84, 87, 199 151, 152, 153, 155, 156, 158, 160, 161, 162,
invalid indicator parameter value • 46 163, 164, 165, 166, 167, 169, 170, 171, 172,
invalid LEVEL value • 87, 88 173, 174, 175, 176, 178, 179, 180, 181, 182,
invalid schema name • 66, 68, 200 183, 184, 185, 212, 213, 214, 215
invalid schema name list specification • 68, 200 Locator • 15
invalid SQL descriptor name • 80, 82, 84, 87, 102,
107, 111

LOCATOR • 72, 74, 77, 85, 87, 88, 108, 114, 115, <MUMPS variable definition> • 134, 172, 173, 175
138, 139, 140, 150, 151, 152, 155, 156, 157, <mutated set clause> • 97
158, 159, 162, 164, 167, 169, 170, 172, 173,
174, 175, 176, 177, 178, 179, 181, 182, 183 —N—
<locator reference> • 62 Name • 34, 67, 144, 153, 160, 166, 171, 180, 185,
208, 209, 210, 211, 228
—M— NAME • 57, 67, 72, 73, 74, 75, 76, 83, 84, 86, 87, 88,
<major category> • 145, 146, 148, 207 89, 90, 103, 104, 105, 106, 134, 194, 218, 221
match • 73, 74, 75, 84, 87, 96, 97, 107, 108, 111, NAMES • 67, 134, 194
112, 199 NATIONAL • 159, 170
MATCH • 57 NCHAR • 154, 155, 156, 157, 159
<match predicate> • 96 NESTING • 31, 101, 102, 103
MAX • 80, 218 <nesting option> • 101
meets • 92, 96 NEXT • 124
method • 27, 110, 190, 192, 217 NO • 119
<minus sign> • 94 no additional dynamic result sets returned • 122
MINUTE • 78, 89, 97 no data • 84, 122, 125, 190, 191
modified • 150, 152, 156, 158, 163, 165, 168, 170, nonholdable • 29
173, 175, 177, 179, 182, 184 <non-reserved word> • 31
module • 6, 8, 15, 16, 19, 20, 24, 25, 26, 28, 29, 33, no subclass • 199, 200
35, 55, 56, 98, 100, 101, 116, 118, 119, 123, NOT • 145, 148, 197
124, 126, 127, 129, 134, 135, 137, 138, 143, null • 33, 38, 42, 45, 46, 85, 104, 105, 108, 109, 113,
144, 204, 217, 218, 219, 222 114, 159, 187, 192, 219
MODULE • 197 NULL • 197
<module authorization clause> • 15, 24, 25, 26, 28, NULLABLE • 75, 83, 86, 103, 104
55, 138, 218 null value • 33, 45, 46, 85, 104, 108, 109, 113, 114,
<module authorization identifier> • 25, 26, 55, 134, 187, 192, 219
222 null value, no indicator parameter • 45, 85
<module character set specification> • 15, 138 NUMERIC • 72, 73, 77, 88, 92, 93, 165
<module contents> • 55, 56, 204 <numeric value expression> • 92
<module name> • 15, 24, 26, 138, 222 <numeric value expression dividend> • 93
<module name clause> • 138 <numeric value expression divisor> • 93
<module path specification> • 138, 219
<module transform group specification> • 138 —O—
<modulus expression> • 93 object • 6, 12, 13, 29, 45, 62, 101, 105, 112, 113,
MONTH • 78, 89, 94 129, 130, 138, 140, 150, 151, 152, 155, 156,
most specific type • 87 157, 158, 161, 162, 163, 164, 167, 168, 169,
<multiple group specification> • 136 172, 174, 176, 177, 178, 181, 183, 221
MUMPS • 3, 12, 13, 24, 133, 134, 135, 137, 138, OBJECT • 23, 72, 73, 74, 88, 115, 159
143, 146, 172, 173, 174, 175, 197, 201, 203, object column • 129, 130
211, 212, 213, 214, 215, 228 <occurrences> • 80, 81, 84, 87, 102, 108, 112, 206,
<MUMPS array locator variable> • 172, 173, 175, 213 218
<MUMPS BLOB locator variable> • 172, 174, 175, <octet length expression> • 92
215 <octet match value> • 97
<MUMPS BLOB variable> • 172, 174, 175, 215 <octet pattern> • 97
<MUMPS character variable> • 172, 173 OCTET_LENGTH • 75, 76, 83, 84, 86, 104, 105, 115,
<MUMPS CLOB locator variable> • 172, 174, 175, 218, 221
215 OF • 127, 129, 131, 132, 176, 177, 179, 180, 210
<MUMPS CLOB variable> • 172, 173, 174, 175, 215 OLD • 119, 121
<MUMPS derived type specification> • 172, 173, 175, ONLY • 15, 26, 55, 56, 127, 129, 131, 132, 133, 208
211, 213, 214 OPEN • 123, 194
<MUMPS host identifier> • 134, 172, 173, 174, 175 <open statement> • 19, 21, 22, 122, 138, 139, 143,
<MUMPS length specification> • 172, 173 144, 222
<MUMPS numeric variable> • 172 Option • 120, 216
<MUMPS REF variable> • 172, 173, 175, 211 OR • 197
<MUMPS type specification> • 172 order • 16, 61, 71, 76, 87, 103, 121, 122, 129, 139,
<MUMPS user-defined type locator variable> • 172, 140, 143, 191, 192, 199, 203, 222
173, 174, 175, 212 ORDER • 191
<MUMPS user-defined type variable> • 172, 174, <order by clause> • 129, 191, 192
175, 214 <ordinal element specification> • 92
Index 237
ORDINAL_POSITION • 76, 83, 86, 103, 106, 218 <Pascal derived type specification> • 176, 180, 212,
outermost • 114 213, 214
OUTPUT • 98, 101 <Pascal host identifier> • 134, 176, 177, 178, 179
output SQL parameter • 78 <Pascal REF variable> • 176, 177, 179, 180, 212
<output using clause> • 111, 112, 115, 116, 124, 205 <Pascal type specification> • 176, 177, 180, 209, 210
overlaps • 96 <Pascal user-defined type locator variable> • 176,
<overlaps predicate> • 96 178, 180, 213
OVERLAY • 93 <Pascal user-defined type variable> • 176, 178, 180,
214
—P— <Pascal variable definition> • 134, 176, 177, 179
package • 57, 227 <path specification> • 134
parameter • 24, 25, 26, 37, 38, 40, 42, 43, 45, 46, 49, period • 31, 149, 161, 176
50, 51, 52, 53, 57, 78, 85, 92, 97, 98, 101, 102, <period> • 149, 161
103, 104, 105, 106, 107, 108, 109, 110, 111, permitted • 27, 217
112, 114, 116, 117, 118, 123, 138, 139, 140, PL/I • 3, 12, 13, 23, 24, 133, 134, 135, 137, 138, 143,
141, 142, 143, 153, 187, 199, 204, 210, 218, 145, 146, 147, 148, 181, 182, 183, 184, 185,
221, 222, 225 201, 204, 209, 210, 212, 213, 214, 215, 219,
PARAMETERS • 57 228
<parameter using clause> • 107, 116, 117 <PL/I array locator variable> • 181, 182, 184, 185,
PARAMETER_MODE • 75, 78, 79, 83, 86, 106, 218 213
PARAMETER_ORDINAL_POSITION • 76, 83, 86, <PL/I BLOB locator variable> • 181, 183, 185, 215
103, 106, 218 <PL/I BLOB variable> • 181, 183, 185, 215
PARAMETER_SPECIFIC_CATALOG • 76, 83, 86, <PL/I CLOB locator variable> • 181, 183, 185, 215
103, 106, 218 <PL/I CLOB variable> • 181, 182, 183, 185, 215
PARAMETER_SPECIFIC_NAME • 76, 83, 86, 103, <PL/I derived type specification> • 181, 185, 212,
106, 218 213, 214
PARAMETER_SPECIFIC_SCHEMA • 76, 83, 86, <PL/I host identifier> • 134, 181, 182, 183, 184
103, 106, 218 <PL/I REF variable> • 181, 182, 184, 185, 212
Part 1 • 3 <PL/I type fixed binary> • 181, 182
Part 2 • 3 <PL/I type fixed decimal> • 181, 182
Part 3 • 3 <PL/I type float binary> • 181, 182
Part 4 • 3 <PL/I type specification> • 181, 182, 185, 209, 210,
Part 5 • 12, 13 219
<Part 5 conformance> • 12 <PL/I user-defined type locator variable> • 181, 183,
<Part 5 direct> • 12 185, 213
<Part 5 direct no> • 12, 13 <PL/I user-defined type variable> • 181, 183, 185,
<Part 5 direct yes> • 12, 13 214
<Part 5 embedded> • 12 <PL/I variable definition> • 134, 181, 182, 184, 219
<Part 5 embedded Ada> • 12 PLACING • 93
<Part 5 embedded C> • 12 PLI • 13, 138, 197
<Part 5 embedded COBOL> • 12, 13 <plus sign> • 94
<Part 5 embedded Fortran> • 12, 13 POSITION • 76, 83, 86, 93, 103, 106, 218
<Part 5 embedded languages> • 12 <position expression> • 93
<Part 5 embedded MUMPS> • 12, 13 possibly nullable • 104
<Part 5 embedded no> • 12, 13 potentially referenced cursors • 98, 99
<Part 5 embedded Pascal> • 12, 13 precede • 55, 71, 136, 137, 156, 163, 168, 182, 192
<Part 5 embedded PL/I> • 12, 13 precedes • 71, 136, 137, 168, 192
<Part 5 yes> • 12 precision • 26, 72, 88, 89, 92, 94, 105, 165, 172, 173,
part of • 1, 3, 5, 6, 7, 8, 9, 10, 11, 12, 13, 23, 66, 123, 181, 184, 185
162, 163, 201, 217, 221, 223, 225, 227 PRECISION • 72, 73, 75, 76, 77, 83, 87, 88, 89, 105,
Pascal • 3, 12, 13, 23, 24, 133, 134, 135, 137, 138, 149, 152, 159, 167, 170, 221
143, 146, 176, 177, 178, 179, 180, 201, 204, <precision> • 26, 92, 172, 173, 181, 184, 185
209, 210, 212, 213, 214, 215, 228 predefined • 69, 109, 113, 150, 155, 162, 167, 172,
PASCAL • 138, 179, 197 176, 181
<Pascal array locator variable> • 176, 179, 180, 213 predefined data types • 69, 109, 113
<Pascal BLOB locator variable> • 176, 178, 180, 215 <predefined type> • 150, 155, 162, 167, 172, 176,
<Pascal BLOB variable> • 176, 178, 180, 215 181
<Pascal CLOB locator variable> • 176, 178, 180, 215 preferred candidate key • 103
<Pascal CLOB variable> • 176, 177, 178, 180, 215

<preparable dynamic delete statement: positioned> • RESULT • 57

17, 18, 20, 21, 23, 25, 91, 98, 117, 131, 194, result data type • 47, 141
207 <result expression> • 95
<preparable dynamic update statement: positioned> • result set • 101, 121, 122
17, 18, 20, 21, 23, 25, 91, 98, 117, 132, 194, result set cursor • 121, 122
207 <result set cursor> • 121, 122
<preparable implementation-defined statement> • 21, <result using clause> • 111, 116, 117, 207
91, 218 Retrieval assignment • 45
<preparable SQL control statement> • 91, 92 RETURN • 119, 121
<preparable SQL data statement> • 91 returned value • 26
<preparable SQL schema statement> • 91 RETURNED_CARDINALITY • 31, 76, 84, 86, 115
<preparable SQL session statement> • 91 RETURNED_LENGTH • 76, 84, 86, 115
<preparable SQL transaction statement> • 91 RETURNED_OCTET_LENGTH • 76, 84, 86, 115
<preparable statement> • 15, 27, 28, 29, 34, 37, 65, <returns data type> • 114
66, 67, 68, 91, 92, 117, 217, 218 <return value> • 110, 114
Prepare • 91 <right bracket> • 154, 176
PREPARE • 57, 91, 99, 100, 118, 194 <right paren> • 12, 13, 92, 93, 133, 135, 149, 150,
prepared • 15, 16, 17, 18, 24, 25, 26, 27, 28, 29, 34, 155, 161, 162, 167, 172, 176, 181
35, 37, 38, 56, 59, 65, 66, 67, 68, 69, 78, 92, role • 27, 97
99, 100, 101, 102, 105, 107, 111, 112, 116, <role specification> • 97
119, 121, 122, 123, 127, 129, 193, 194, 199, <rollback statement> • 55, 188, 222
207, 217, 218, 219, 221 <routine body> • 15
prepared statement not a cursor specification • 99, <routine invocation> • 28, 43, 68, 97, 98, 105
122, 199 <routine name> • 28, 68, 141
<prepare statement> • 5, 15, 17, 18, 24, 25, 26, 27, row • 8, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 39,
28, 29, 34, 35, 37, 56, 59, 65, 66, 67, 68, 69, 41, 60, 61, 71, 72, 74, 84, 86, 91, 92, 95, 96,
91, 99, 100, 101, 116, 119, 194, 205, 217, 218 97, 99, 102, 103, 104, 105, 108, 111, 112, 116,
primary key • 102, 104 118, 122, 124, 125, 127, 129, 131, 132, 151,
privilege • 7, 27, 39, 41, 144, 188 157, 164, 169, 174, 178, 183, 187, 191, 192,
PROCEDURE • 57, 85, 121 194, 197, 206, 225, 227
<procedure name> • 24, 138, 139, 222 ROW • 72, 74, 77, 85, 87, 88, 105, 108, 114
row type • 71, 72, 74, 92, 95, 96, 105
—Q— <row value constructor> • 96
<quantified comparison predicate> • 96 <row value constructor element> • 96, 97
query • 39, 42, 47, 95, 96, 123, 125, 191, 225 <row value expression 1> • 96
<query expression> • 39, 47, 95, 123, 191 <row value expression 2> • 96
<query specification> • 39, 42, 125 <row value expression> • 95, 96, 225
<question mark> • 26, 37
—S—
—R— SCALE • 72, 73, 76, 84, 87, 88, 89, 105, 218, 221
read-only • 189 <scale> • 26, 172, 173, 181, 184
read-only SQL-transaction • 189 schema • 8, 15, 17, 19, 20, 22, 26, 27, 28, 29, 34,
read-write • 189 39, 55, 59, 60, 65, 66, 68, 91, 97, 106, 133,
REAL • 72, 73, 77, 149, 152, 159, 167, 170, 172, 138, 187, 189, 190, 194, 200, 210, 217, 218
173, 176, 179 SCHEMA • 15, 26, 28, 55, 57, 66, 72, 73, 74, 75, 76,
REF • 72, 74, 77, 159 83, 84, 86, 87, 88, 89, 90, 103, 105, 106, 133,
referenced type • 105, 152, 158, 165, 170, 175, 179, 138, 194, 218
184 schema and data statement mixing not supported •
reference type • 74, 105, 152, 153, 158, 160, 165, 60, 190
166, 170, 171, 175, 179, 180, 184, 185, 211, <schema definition> • 34
212 <schema name> • 15, 26, 28, 55, 65, 66, 133, 138,
<reference type> • 105, 150, 152, 156, 158, 162, 165, 217, 218
168, 170, 173, 175, 177, 179, 182, 184 <schema name characteristic> • 66, 97
released • 26 <schema name list> • 68
repertoire • 159 <schema qualified name> • 28, 34, 66, 217, 218
represented • 26, 29, 62, 74, 75, 76, 84, 108, 112 SCHEMA_NAME • 57
<reserved word> • 31, 225 scope • 1, 5, 25, 34, 35, 74, 80, 82, 98, 99, 100, 101,
RESTRICT • 57 102, 107, 111, 116, 121, 122, 123, 127, 129,
restricted data type attribute violation • 109, 110, 112, 131, 132, 137, 152
113, 114, 199 Scope • 1
Index 239
SCOPE • 72, 74, 76, 84, 87, 90, 105 shall • 24, 33, 34, 35, 36, 37, 38, 39, 40, 41, 43, 45,
<scope option> • 34, 35, 80, 82, 98, 99, 102, 107, 49, 50, 51, 52, 53, 55, 56, 57, 60, 61, 62, 65,
111, 131, 132 66, 67, 68, 69, 80, 81, 82, 84, 85, 86, 90, 91,
SCOPE_CATALOG • 72, 74, 76, 84, 87, 90, 105 92, 99, 100, 101, 102, 106, 107, 110, 111, 115,
SCOPE_NAME • 72, 74, 76, 84, 87, 90, 105 116, 117, 118, 119, 120, 121, 122, 123, 124,
SCOPE_SCHEMA • 72, 74, 76, 84, 87, 90, 105 125, 126, 127, 128, 129, 130, 131, 132, 135,
SCROLL • 119, 121, 124 136, 137, 138, 139, 141, 144, 146, 148, 150,
scrollability • 119, 120, 205, 208 151, 152, 153, 156, 157, 158, 159, 160, 162,
search condition • 49, 51 163, 164, 165, 166, 168, 169, 170, 171, 173,
<search condition> • 49, 51 174, 175, 177, 178, 179, 180, 182, 183, 184,
SECOND • 78, 89, 94 185, 187, 190, 191, 192, 201, 203, 204, 205,
SECTION • 134 206, 207, 208, 209, 210, 211, 212, 213, 214,
SELECT • 39, 41, 194 215, 216, 218
<select list> • 61, 101, 102, 112 <signed integer> • 191
<select statement: single row> • 19, 21, 23, 61 significant • 168, 179
<select target list> • 61 <similar pattern> • 97
<semicolon> • 133, 135, 154, 172, 176, 181, 187 <similar predicate> • 97
sensitive • 119, 205, 206, 211, 215 SIMPLE • 3, 40, 55, 65, 66, 67, 68, 69, 80, 99, 109,
sensitivity • 119, 121 110, 113, 118, 121, 131, 132, 139, 142, 146,
<separator> • 31, 33, 135, 146, 168 150, 151, 152, 157, 158, 163, 164, 165, 168,
sequence • 28, 146, 152, 158, 165, 184 169, 170, 173, 174, 175, 177, 178, 179, 182,
SERIALIZABLE • 189 183, 184, 188
SESSION • 191 <simple case> • 95
SESSION_USER • 191 <simple comment> • 92
SET • 65, 66, 67, 68, 69, 86, 129, 132, 142, 149, <simple Latin upper case letter> • 145
150, 154, 155, 156, 157, 159, 161, 163, 167, <simple target specification 1> • 83, 84, 85, 221
168, 172, 173, 176, 177, 179, 181, 182, 188, <simple target specification 2> • 83, 84, 85, 221
194 <simple target specification 3> • 221
<set catalog statement> • 15, 17, 26, 28, 59, 65, 194, <simple target specification> • 37, 73, 74, 83, 84, 99,
210 193
<set clause> • 97 <simple value specification 1> • 86, 89
<set clause list> • 129, 132 <simple value specification 2> • 86, 87
<set connection statement> • 188 <simple value specification> • 25, 34, 35, 37, 73, 74,
<set descriptor information> • 86 80, 82, 83, 86, 91, 102, 107, 111, 121
<set descriptor statement> • 17, 18, 25, 59, 85, 86, simply contain • 39, 92, 93, 94, 95, 96, 97, 105, 123,
87, 89, 90, 194, 205, 221 153, 160, 166, 171, 175, 180, 185, 191, 212,
<set function specification> • 191 213, 218
<set header information> • 86, 89 simply contained in • 39, 93, 94, 95, 96, 97, 105, 123,
<set item information> • 86, 87 153, 160, 166, 171, 175, 180, 185, 212, 213,
<set local time zone statement> • 97 218
<set names statement> • 17, 26, 29, 59, 67, 194, simply underlying table • 127, 129
208, 211 <single group specification> • 136
<set path statement> • 17, 26, 28, 59, 68, 194, 212, SMALLINT • 72, 73, 77, 149, 152, 159, 165, 185
218 <solidus> • 93
<set schema statement> • 17, 26, 28, 59, 66, 194, <sort key> • 120, 211
210 <sort specification> • 191, 192
<set session characteristics statement> • 59 <sort specification list> • 39
<set transaction statement> • 189 source • 95, 97
<set transform group statement> • 17, 28, 59, 69, 92, SOURCE • 197
194, 213 <space> • 25, 135, 168
shadow module • 15, 26, 56 specific name • 106
<specific routine designator> • 121, 122
SPECIFIC_CATALOG • 76, 83, 86, 103, 106, 218
SPECIFIC_NAME • 76, 83, 86, 103, 106, 218
SPECIFIC_SCHEMA • 76, 83, 86, 103, 106, 218
specified by • 15, 33, 38, 73, 74, 80, 82, 85, 87, 102,
107, 111, 122, 123, 143, 152, 156, 159, 163,
165, 170, 179, 184, 191, 221

specify • 15, 25, 40, 51, 56, 85, 119, 120, 124, 127, SQL-session • 15, 16, 17, 19, 20, 22, 25, 26, 27, 28,
129, 137, 144, 146, 147, 148, 152, 153, 156, 29, 33, 34, 35, 37, 38, 55, 60, 65, 66, 67, 68,
157, 158, 163, 165, 171, 180, 184, 185, 205, 69, 88, 109, 114, 122, 188, 189, 217, 218
206, 207, 208, 210, 211, 215, 216, 227 SQL-session module • 15, 25, 26, 28, 29, 33
SQL • 80, 82, 83, 86, 101, 111, 133, 134, 150, 151, <SQL session statement> • 59, 91, 187
152, 155, 156, 157, 158, 161, 162, 163, 164, SQL-session user identifier • 27, 188
165, 167, 168, 169, 170, 172, 173, 174, 175, SQLSTATE • 57, 58, 137, 139, 140, 143, 145, 146,
176, 177, 178, 179, 181, 182, 183, 184 147, 148, 149, 153, 199, 208
SQL-agent • 55, 60, 188, 189 <SQLSTATE char> • 145, 146
SQL argument • 97, 98, 105 <SQLSTATE class value> • 145, 146, 147, 148
<SQL argument> • 97, 98 SQL-statement • 1, 5, 15, 16, 18, 19, 20, 21, 22, 24,
<SQL argument list> • 98 26, 27, 28, 52, 56, 59, 78, 100, 136, 137, 145,
SQL-client • 15, 16, 19, 20, 24, 25, 26, 28, 29, 33, 188, 193, 194, 222
35, 55, 56, 100, 101, 116, 118, 119, 123, 124, <SQL statement name> • 5, 34, 36, 91, 99, 100, 101,
126, 127, 129, 137, 143, 144, 217, 222 116, 204
SQL-client module • 15, 16, 19, 20, 24, 25, 26, 28, <SQL statement variable> • 5, 18, 91, 92, 118
33, 35, 55, 56, 100, 101, 116, 118, 119, 123, <SQLSTATE subclass value> • 145, 146, 147
124, 126, 127, 129, 137, 143, 144, 217, 222 <SQL terminator> • 133, 134, 135
<SQL-client module definition> • 15, 16, 19, 20, 24, SQL-transaction • 16, 19, 20, 22, 27, 60, 63, 99, 144,
25, 26, 28, 35, 55, 56, 100, 101, 116, 118, 119, 189, 190, 217, 221
123, 124, 126, 127, 129, 137, 143, 144, 217, <SQL transaction statement> • 91, 187
222 <SQL variable name> • 141
<SQL condition> • 145, 148, 208 SQL variable reference • 187
SQL-connection • 19, 21, 22, 27 SQLWARNING • 145, 148, 207
<SQL connection statement> • 29, 187, 188 SQL_ERROR • 57
<SQL control statement> • 91, 92 SQL_IDENTIFIER • 38, 75, 76
SQL-data • 16, 17, 19, 20, 21, 22, 45, 46, 49, 190 SQL_LANGUAGES • 197
<SQL data statement> • 60 SQL_LANGUAGE_BINDING_STYLE • 197
<SQL diagnostics statement> • 29 SQL_LANGUAGE_PROGRAMMING_LANGUAGE •
<SQL dynamic data statement> • 27, 59, 60, 217 197
<SQL dynamic statement> • 15, 35, 52, 53, 59, 60, SQL_LANGUAGE_SOURCE • 197
107, 111, 204 SQL_LANGUAGE_YEAR • 197
SQL-environment • 28 <start transaction statement> • 189
SQLEXCEPTION • 145, 148, 207 STATE • 57, 58, 137, 139, 140, 143, 145, 146, 147,
<SQL executable statement> • 59 148, 149, 153, 199, 208
SQL-implementation • 27, 60, 190, 228 STATEMENT • 57
SQL-invoked method • 110 <statement cursor> • 121
SQL-invoked procedure • 121, 122, 199 <statement information item> • 193
SQL-invoked routine • 15, 43, 53, 121, 143 <statement information item name> • 193
<SQL-invoked routine> • 53, 133, 143 <statement name> • 25, 34, 35, 63, 99, 100, 101,
<SQL language character> • 136 116, 118, 119, 123, 127, 129, 221
SQL parameter • 37, 78, 98, 106, 110, 116, 139, 141, <statement or declaration> • 133, 143, 144
187 STATIC • 15, 26, 55, 56, 133, 208
SQL parameter name • 141 Store assignment • 46
<SQL parameter name> • 141 strings • 23, 158
SQL parameter reference • 187 <string value expression> • 92
SQL parameters • 37, 116 <string value function> • 93
SQL-path • 15, 28, 29, 68, 97, 218 STRUCTURE • 31, 101
<SQL-path characteristic> • 68, 97 structured type • 120, 153, 160, 166, 171, 175, 180,
<SQL prefix> • 133, 134, 135 185, 211, 212, 213
<SQL procedure statement> • 15, 19, 20, 26, 59, 60, STYLE • 197
92, 133, 139, 140, 141, 142, 143, 146, 147, subfield • 92, 94, 95, 96, 97, 225
187, 204, 222 subject routine • 68, 97, 98, 105
SQL routine • 53 subject table • 127, 129
<SQL routine body> • 53 subordinate descriptor areas • 71, 72, 88, 114
SQL-schema • 19, 20, 22, 27, 60, 190, 217 subordinate descriptors • 71, 102, 103
<SQL schema statement> • 39, 91, 187, 189 <subquery> • 191
SQL-server • 26, 29 SUBSTRING • 93
subtype • 69
Index 241
successful completion • 147, 190 type • 11, 23, 25, 26, 28, 29, 35, 37, 38, 45, 47, 57,
syntax error or access rule violation • 92, 97, 116, 62, 65, 66, 67, 68, 69, 71, 72, 73, 74, 75, 76,
118, 188 77, 78, 80, 84, 86, 87, 88, 89, 91, 92, 93, 94,
<system descriptor statement> • 59 95, 96, 97, 103, 104, 105, 108, 109, 110, 112,
SYSTEM_USER • 191 113, 114, 118, 120, 136, 137, 138, 139, 140,
141, 144, 149, 150, 151, 152, 153, 154, 155,
—T— 156, 157, 158, 159, 160, 161, 162, 163, 164,
table • 5, 10, 11, 12, 20, 21, 22, 26, 28, 39, 41, 42, 165, 166, 167, 168, 169, 170, 171, 172, 173,
50, 59, 61, 72, 95, 96, 102, 105, 111, 116, 122, 174, 175, 176, 177, 178, 179, 180, 181, 182,
123, 125, 127, 129, 130, 131, 132, 133, 136, 183, 184, 185, 193, 199, 208, 209, 210, 211,
139, 143, 146, 168, 187, 191, 192, 197, 199, 212, 213, 214, 215, 218, 219, 221, 225
200, 225, 227, 228 Type • 75, 77, 78, 84, 86, 193
table constraint • 197 TYPE • 69, 71, 72, 73, 74, 76, 77, 84, 85, 87, 88, 89,
<table expression> • 42 103, 104, 105, 108, 114, 115, 150, 151, 152,
<table name> • 116, 127, 129, 136 155, 156, 157, 158, 161, 162, 163, 164, 165,
<table or query name> • 191 167, 168, 169, 170, 172, 173, 174, 175, 176,
<table reference> • 41, 127, 129, 131, 132 177, 178, 179, 181, 182, 183, 184
<table subquery> • 96, 225 typed table • 95
<table value constructor> • 95 types • 11, 23, 25, 29, 38, 47, 69, 71, 74, 75, 76, 77,
target • 25, 37, 38, 45, 46, 61, 73, 74, 83, 84, 85, 87, 78, 84, 86, 88, 92, 94, 95, 96, 97, 103, 109,
94, 97, 98, 99, 111, 112, 113, 114, 116, 124, 113, 120, 141, 152, 153, 160, 166, 171, 175,
127, 129, 131, 132, 143, 145, 146, 193, 199, 180, 185, 210, 211, 212
200, 221 TYPE_NAME • 72, 74, 76, 84, 87, 90, 105
<target specification> • 25, 37, 38, 61, 98, 111, 112,
113, 114 —U—
<target table> • 127, 129, 131, 132 undefined • 47, 80, 85, 87, 92, 94, 97, 199, 221
target table disagrees with cursor specification • 127, undefined DATA value • 85, 199
129, 200 underlying table • 127, 129, 131, 132
temporary • 20, 21, 22, 28, 116, 133, 136, 139, 143, UNNAMED • 76, 84, 86, 103, 104, 221
187 <unqualified schema name> • 34, 66
temporary table • 20, 21, 22, 28, 116, 136, 139, 143 <unsigned integer> • 145, 146, 147, 148
<temporary table declaration> • 20, 21, 22, 28, 133, <updatability clause> • 120, 130, 205, 208, 211
136, 139, 143, 187 updatable • 123, 127, 129, 130, 199
TIME • 23, 77, 78, 89, 96 updatable column • 130, 199
<time precision> • 72, 105 updatable cursor • 123, 127, 129
TIMESTAMP • 23, 77, 78, 89, 96 UPDATE • 120, 129, 132, 194, 205, 208, 211
<timestamp precision> • 72, 105 <update source> • 97
TM • 118, 147 <update statement: positioned> • 20, 21, 23, 130,
TO • 78, 89, 94, 97, 145, 146, 147, 148, 188 132, 144
<token> • 31, 135 <update statement: searched> • 19, 21, 22, 91, 187
TOP_LEVEL_COUNT • 31, 75, 83, 86, 102 <update target> • 97
to-sql function • 110, 144 USAGE • 161, 162, 163, 164, 165, 219
transaction • 6, 16, 18, 19, 20, 22, 27, 60, 63, 91, 99, USER • 72, 74, 76, 77, 84, 87, 89, 90, 105, 191
144, 187, 188, 189, 190, 217, 219, 221 user-defined • 23, 28, 29, 37, 38, 62, 69, 72, 74, 92,
transaction-initiating • 18, 19, 27, 187, 188, 189 105, 109, 113, 114, 136, 139, 140, 141, 144,
transaction-initiating statement • 18 149, 150, 151, 152, 153, 155, 156, 157, 158,
transaction state • 18, 19, 20, 22, 60, 189, 190 160, 161, 162, 164, 165, 166, 167, 169, 171,
transform functions • 28, 69, 92 172, 173, 174, 175, 176, 178, 180, 181, 183,
<transform group characteristic> • 69, 97 185, 212, 213, 214
<transform group specification> • 134 user-defined type • 28, 29, 38, 62, 69, 72, 74, 92,
transforms • 23 105, 109, 113, 114, 136, 139, 140, 141, 144,
trigger • 8, 52 151, 152, 153, 157, 158, 160, 164, 165, 166,
<trigger definition> • 52 169, 171, 174, 175, 178, 180, 183, 185, 212,
triggered action • 52 213, 214
<triggered action> • 52 <user-defined type> • 29, 37, 38, 69, 136, 150, 151,
<triggered SQL statement> • 52 152, 155, 156, 158, 162, 164, 165, 167, 169,
TRIM • 65, 66, 67, 68, 69, 80, 99, 121 172, 174, 176, 178, 181, 183
user-defined type locator variable • 62, 139, 141, 152,
153, 158, 160, 165, 166, 169, 171, 174, 175,
178, 180, 183, 185, 212, 213

<user-defined type name> • 74, 105, 136, 139, 141, VALUE • 83, 86, 165, 219
150, 153, 160, 162, 166, 167, 171, 173, 175, <value expression> • 92, 93, 94, 95, 97, 106, 120,
176, 180, 181, 185, 212, 213 191, 211
user-defined types • 141 <value expression primary> • 40, 94
user identifier • 27, 188 <value specification> • 37, 65, 66, 67, 68, 69, 97, 98,
USER_DEFINED_TYPE_CATALOG • 72, 74, 76, 84, 187, 191, 219
87, 89, 105 VARCHAR • 154, 155, 156, 159, 172, 174, 175
USER_DEFINED_TYPE_NAME • 72, 74, 76, 84, 87, variable-length • 159, 173
90, 105 VARYING • 23, 72, 73, 77, 88, 92, 93, 97, 115, 154,
USER_DEFINED_TYPE_SCHEMA • 72, 74, 76, 84, 155, 156, 157, 159, 173, 181, 182, 184, 185,
87, 89, 105 210
USING • 57, 101, 107 view • 8, 39, 50, 79, 123
<using argument> • 107, 109 view definition • 50
<using arguments> • 107, 109 <view definition> • 50
using clause does not match dynamic parameter viewed table • 50
specifications • 107, 108, 199
using clause does not match target specifications • —W—
111, 112, 199 warning • 27, 103, 190, 200
using clause required for dynamic parameters • 116, WHENEVER • 145
123, 199 <when operand> • 95
using clause required for result fields • 116, 199 WHERE • 127, 129, 131, 132
<using descriptor> • 101, 107 WITH • 77, 78, 80, 89, 96, 101, 102, 103, 121, 218
<using input descriptor> • 107, 108 WITHOUT • 77, 78, 101, 119, 120, 216
without an intervening • 34
—V—
valid • 3, 25, 46, 60, 63, 65, 66, 67, 68, 69, 71, 72, —Y—
73, 80, 82, 84, 87, 88, 89, 98, 99, 100, 101, YEAR • 78, 89, 94, 197
102, 107, 108, 111, 112, 116, 121, 122, 123,
127, 129, 137, 143, 144, 146, 150, 152, 156,
—Z—
ZONE • 77, 78, 89, 96
158, 163, 165, 168, 170, 173, 175, 179, 182,
184, 189, 190, 199, 200, 221
Index 243

Iso-Iec 9075-5

Uploaded by

Copyright:

Available Formats

Iso-Iec 9075-5

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Iso-Iec 9075-5

Uploaded by

Copyright:

Available Formats

ANSI/ISO/IEC International Standard (IS)

Database Language SQL — Part 5: Host Language Bindings (SQL/Bindings)

3 Definitions, notations, and conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

ii Host Language Bindings (SQL/Bindings)

8 Additional common elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

9 Data assignment rules and routine determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

10 Schema definition and manipulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

16 Embedded SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

17 Direct invocation of SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

iv Host Language Bindings (SQL/Bindings)

18 Diagnostics management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

19 Definition Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

20 Status codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

Annex A SQL Conformance Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

Annex B Implementation-defined elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

Annex C Implementation-dependent elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

Annex D Deprecated features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

Annex E Incompatibilities with ISO/IEC 9075:1992 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

Annex F SQL feature and package taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227

1 Clause, Subclause, and Table relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

vi Host Language Bindings (SQL/Bindings)

(This foreword is not a part of American National Standard ANSI/ISO/IEC 9075-5:1999.)

— Part 1: Framework (SQL/Framework)

— Part 2: Foundation (SQL/Foundation)

— Part 3: Call-Level Interface (SQL/CLI)

— Part 4: Persistent Stored Modules (SQL/PSM)

— Part 5: Host Language Bindings (SQL/Bindings)

— Annex A (informative): SQL Conformance Summary.

— Annex B (informative): Implementation-defined elements.

— Annex C (informative): Implementation-dependent elements.

— Annex D (informative): Deprecated features.

— Annex E (informative): Incompatibilities with ISO/IEC 9075:1992.

— Annex F (informative): SQL feature and package taxonomy.

NCITS Chairman NCITS Vice Chair NCITS Secretary

viii Host Language Bindings (SQL/Bindings)

Ms. Wendy Fong [A]

Mr. Tom Rutt [A]

x Host Language Bindings (SQL/Bindings)

Sun Microsystems Inc.

xii Host Language Bindings (SQL/Bindings)

Bruce M. Horowitz, Vice-Chair

Krishna Kulkarni, International Representative

Barry D. Vickers, Treasurer

Michael M. Gorman, Secretary

Jim Melton, Editor

Chuck Campbell Andrew Eisenberg Chris Farrar

xiv Host Language Bindings (SQL/Bindings)

The organization of this part of ISO/IEC 9075 is as follows:

1) Clause 1, ‘‘Scope’’, specifies the scope of this part of ISO/IEC 9075.

5) Clause 5, ‘‘Lexical elements’’, defines the lexical elements of the language.

11) Clause 11, ‘‘SQL-client modules’’, defines modules and procedures.

23) Annex B, ‘‘Implementation-defined elements’’, is an informative Annex. It lists those features

24) Annex C, ‘‘Implementation-dependent elements’’, is an informative Annex. It lists those features

xviii Host Language Bindings (SQL/Bindings)

Information technology — Database languages — SQL —

This part of ISO/IEC 9075 specifies:

— Syntax for direct invocation of SQL-statements.

— SQL language to support dynamic preparation and execution of SQL-statements.