Application Programming Guide and Reference for Java

Application Programming Guide and Reference for Java
DB2 10 for z/OS
Application Programming
Guide and Reference
for Java
SC19-2970-02
DB2 10 for z/OS
Application Programming
Guide and Reference
for Java
SC19-2970-02
Note
Before using this information and the product it supports, be sure to read the general information under “Notices” at the
end of this information.
Third edition (March 2011)
This edition applies to DB2 10 for z/OS (product number 5605-DB2), DB2 10 for z/OS Value Unit Edition (product
number 5697-P31), and to any subsequent releases until otherwise indicated in new editions. Make sure you are
using the correct edition for the level of the product.
Specific changes are indicated by a vertical bar to the left of a change. A vertical bar to the left of a figure caption
indicates that the figure has changed. Editorial changes that have no technical significance are not noted.
© Copyright IBM Corporation 1998, 2011.
US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract
with IBM Corp.
Contents
About this information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Who should read this information .
DB2 Utilities Suite . . . . . .
Terminology and citations. . . .
Accessibility features for DB2 10 for
How to send your comments . .
How to read syntax diagrams . .
. .
. .
. .
z/OS
. .
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. ix
. ix
. ix
. . . . . . . . . . . . . . . . . . . . . . . . . x
. . . . . . . . . . . . . . . . . . . . . . . . . xi
. . . . . . . . . . . . . . . . . . . . . . . . . xi
Chapter 1. Java application development for IBM data servers . . . . . . . . . . . . 1
Chapter 2. Supported drivers for JDBC and SQLJ. . . . . . . . . . . . . . . . . . 3
JDBC driver and database version compatibility . . . . . . . . . . . . . . .
DB2 for z/OS and IBM Data Server Driver for JDBC and SQLJ levels . . . . . . . .
DB2 for Linux, UNIX, and Windows and IBM Data Server Driver for JDBC and SQLJ levels.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 4
. 5
. 6
Chapter 3. JDBC application programming. . . . . . . . . . . . . . . . . . . . . 9
Example of a simple JDBC application . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
How JDBC applications connect to a data source . . . . . . . . . . . . . . . . . . . . . . . 11
Connecting to a data source using the DriverManager interface with the IBM Data Server Driver for JDBC and
SQLJ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Connecting to a data source using the DataSource interface . . . . . . . . . . . . . . . . . . 17
How to determine which type of IBM Data Server Driver for JDBC and SQLJ connectivity to use . . . . . 19
JDBC connection objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Creating and deploying DataSource objects . . . . . . . . . . . . . . . . . . . . . . . . 20
Java packages for JDBC support . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Learning about a data source using DatabaseMetaData methods. . . . . . . . . . . . . . . . . . 22
DatabaseMetaData methods for identifying the type of data source . . . . . . . . . . . . . . . . 23
Variables in JDBC applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
JDBC interfaces for executing SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Creating and modifying database objects using the Statement.executeUpdate method . . . . . . . . . 25
Updating data in tables using the PreparedStatement.executeUpdate method . . . . . . . . . . . . 26
JDBC executeUpdate methods against a DB2 for z/OS server. . . . . . . . . . . . . . . . . . 28
Making batch updates in JDBC applications . . . . . . . . . . . . . . . . . . . . . . . 28
Learning about parameters in a PreparedStatement using ParameterMetaData methods . . . . . . . . . 32
Data retrieval in JDBC applications . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Calling stored procedures in JDBC applications . . . . . . . . . . . . . . . . . . . . . . 46
LOBs in JDBC applications with the IBM Data Server Driver for JDBC and SQLJ . . . . . . . . . . . 51
ROWIDs in JDBC with the IBM Data Server Driver for JDBC and SQLJ . . . . . . . . . . . . . . 57
Update and retrieval of timestamps with time zone information in JDBC applications . . . . . . . . . 58
Distinct types in JDBC applications . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Savepoints in JDBC applications . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Retrieval of automatically generated keys in JDBC applications . . . . . . . . . . . . . . . . . 69
Using named parameter markers in JDBC applications . . . . . . . . . . . . . . . . . . . . 73
Providing extended client information to the data source with IBM Data Server Driver for JDBC and SQLJ-only
methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Providing extended client information to the data source with client info properties . . . . . . . . . . 77
Extended parameter information with the IBM Data Server Driver for JDBC and SQLJ . . . . . . . . . . 80
Using DB2PreparedStatement methods or constants to provide extended parameter information . . . . . . 81
Using DB2ResultSet methods or DB2PreparedStatement constants to provide extended parameter information 83
XML data in JDBC applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
XML column updates in JDBC applications . . . . . . . . . . . . . . . . . . . . . . . . 85
XML data retrieval in JDBC applications. . . . . . . . . . . . . . . . . . . . . . . . . 87
Invocation of routines with XML parameters in Java applications . . . . . . . . . . . . . . . . 91
Binary XML format in Java applications . . . . . . . . . . . . . . . . . . . . . . . . . 92
Java support for XML schema registration and removal. . . . . . . . . . . . . . . . . . . . 94
© Copyright IBM Corp. 1998, 2011
iii
Inserting data from file reference variables into tables in JDBC applications . . . . .
Transaction control in JDBC applications. . . . . . . . . . . . . . . . .
IBM Data Server Driver for JDBC and SQLJ isolation levels . . . . . . . . .
Committing or rolling back JDBC transactions . . . . . . . . . . . . . .
Default JDBC autocommit modes . . . . . . . . . . . . . . . . . .
Exceptions and warnings under the IBM Data Server Driver for JDBC and SQLJ . . .
Handling an SQLException under the IBM Data Server Driver for JDBC and SQLJ .
Handling an SQLWarning under the IBM Data Server Driver for JDBC and SQLJ. .
Retrieving information from a BatchUpdateException . . . . . . . . . . .
Memory use for IBM Data Server Driver for IBM Data Server Driver for JDBC and SQLJ
DB2 for z/OS . . . . . . . . . . . . . . . . . . . . . . . . .
Disconnecting from data sources in JDBC applications. . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
. .
. .
. .
. .
type
. .
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . .
. . . .
. . . .
. . . .
2 connectivity
. . . . .
. . . . .
.
.
.
.
.
. 96
. 98
. 98
. 99
. 99
. 100
. 102
. 106
. 107
.
.
.
.
on
. . 109
. . 110
Chapter 4. SQLJ application programming . . . . . . . . . . . . . . . . . . . . 111
Example of a simple SQLJ application . . . . . . . . . . . . . . . .
Connecting to a data source using SQLJ . . . . . . . . . . . . . . .
SQLJ connection technique 1: JDBC DriverManager interface . . . . . . .
SQLJ connection technique 2: JDBC DriverManager interface . . . . . . .
SQLJ connection technique 3: JDBC DataSource interface . . . . . . . . .
SQLJ connection technique 4: JDBC DataSource interface . . . . . . . . .
SQLJ connection technique 5: Use a previously created connection context . . .
SQLJ connection technique 6: Use the default connection . . . . . . . . .
Java packages for SQLJ support . . . . . . . . . . . . . . . . . .
Variables in SQLJ applications . . . . . . . . . . . . . . . . . . .
Indicator variables in SQLJ applications . . . . . . . . . . . . . . .
Comments in an SQLJ application . . . . . . . . . . . . . . . . .
SQL statement execution in SQLJ applications . . . . . . . . . . . . .
Creating and modifying database objects in an SQLJ application . . . . . .
Performing positioned UPDATE and DELETE operations in an SQLJ application .
Data retrieval in SQLJ applications . . . . . . . . . . . . . . . .
Calling stored procedures in SQLJ applications . . . . . . . . . . . .
LOBs in SQLJ applications with the IBM Data Server Driver for JDBC and SQLJ .
SQLJ and JDBC in the same application . . . . . . . . . . . . . .
Controlling the execution of SQL statements in SQLJ . . . . . . . . . .
ROWIDs in SQLJ with the IBM Data Server Driver for JDBC and SQLJ . . . .
TIMESTAMP WITH TIME ZONE values in SQLJ applications . . . . . . .
Distinct types in SQLJ applications . . . . . . . . . . . . . . . .
Savepoints in SQLJ applications . . . . . . . . . . . . . . . . .
XML data in SQLJ applications . . . . . . . . . . . . . . . . . .
XML column updates in SQLJ applications . . . . . . . . . . . . .
XML data retrieval in SQLJ applications . . . . . . . . . . . . . .
XMLCAST in SQLJ applications . . . . . . . . . . . . . . . . .
Inserting data from file reference variables into tables in SQLJ applications . . . .
SQLJ utilization of SDK for Java Version 5 function. . . . . . . . . . . .
Transaction control in SQLJ applications . . . . . . . . . . . . . . .
Setting the isolation level for an SQLJ transaction . . . . . . . . . . .
Committing or rolling back SQLJ transactions . . . . . . . . . . . .
Handling SQL errors and warnings in SQLJ applications . . . . . . . . . .
Handling SQL errors in an SQLJ application . . . . . . . . . . . . .
Handling SQL warnings in an SQLJ application . . . . . . . . . . . .
Closing the connection to a data source in an SQLJ application . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
111
113
113
115
116
118
119
119
120
120
122
126
126
126
127
137
147
149
152
155
155
157
158
159
160
161
163
164
165
166
168
168
169
169
169
170
170
Chapter 5. Java stored procedures and user-defined functions . . . . . . . . . . . 173
Setting up the environment for Java routines . . .
Setting up the WLM application environment for
Runtime environment for Java routines . . . .
Defining Java routines and JAR files to DB2 . . .
Definition of a Java routine to DB2 . . . . .
Definition of a JAR file for a Java routine to DB2
Java routine programming . . . . . . . . .
iv
. . . . .
Java routines.
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
Application Programming Guide and Reference for Java
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
173
174
176
180
180
185
194
Differences between Java routines and stand-alone Java
Differences between Java routines and other routines .
Static and non-final variables in a Java routine . . .
Writing a Java stored procedure to return result sets .
Techniques for testing a Java routine . . . . . . .
programs .
. . . .
. . . .
. . . .
. . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
194
195
196
196
198
Chapter 6. Preparing and running JDBC and SQLJ programs. . . . . . . . . . . . 201
Program preparation for JDBC programs . . . . . . .
Program preparation for SQLJ programs . . . . . . .
Binding SQLJ applications to access multiple database servers
Program preparation for Java routines . . . . . . . .
Preparation of Java routines with no SQLJ clauses . . .
Preparation of Java routines with SQLJ clauses . . . .
Creating JAR files for Java routines . . . . . . . .
Running JDBC and SQLJ programs . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
201
201
202
204
204
205
208
209
Chapter 7. JDBC and SQLJ reference information. . . . . . . . . . . . . . . . . 211
Data types that map to database data types in Java applications . . . . . . . . . . . . . . .
Date, time, and timestamp values that can cause problems in JDBC and SQLJ applications . . . . .
Data loss for timestamp data in JDBC and SQLJ applications . . . . . . . . . . . . . . .
Properties for the IBM Data Server Driver for JDBC and SQLJ . . . . . . . . . . . . . . . .
Common IBM Data Server Driver for JDBC and SQLJ properties for all supported database products . .
Common IBM Data Server Driver for JDBC and SQLJ properties for DB2 servers. . . . . . . . .
Common IBM Data Server Driver for JDBC and SQLJ properties for DB2 for z/OS and IBM Informix. .
Common IBM Data Server Driver for JDBC and SQLJ properties for IBM Informix and DB2 Database for
Linux, UNIX, and Windows . . . . . . . . . . . . . . . . . . . . . . . . . .
IBM Data Server Driver for JDBC and SQLJ properties for DB2 Database for Linux, UNIX, and Windows
IBM Data Server Driver for JDBC and SQLJ properties for DB2 for z/OS . . . . . . . . . . .
IBM Data Server Driver for JDBC and SQLJ properties for IBM Informix . . . . . . . . . . .
IBM Data Server Driver for JDBC and SQLJ configuration properties . . . . . . . . . . . . . .
Driver support for JDBC APIs . . . . . . . . . . . . . . . . . . . . . . . . . . .
IBM Data Server Driver for JDBC and SQLJ support for SQL escape syntax . . . . . . . . . . .
SQLJ statement reference information . . . . . . . . . . . . . . . . . . . . . . . .
SQLJ clause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SQLJ host-expression . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SQLJ implements-clause . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SQLJ with-clause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SQLJ connection-declaration-clause . . . . . . . . . . . . . . . . . . . . . . . .
SQLJ iterator-declaration-clause . . . . . . . . . . . . . . . . . . . . . . . . .
SQLJ executable-clause . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SQLJ context-clause . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SQLJ statement-clause . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SQLJ SET-TRANSACTION-clause . . . . . . . . . . . . . . . . . . . . . . . .
SQLJ assignment-clause . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SQLJ iterator-conversion-clause . . . . . . . . . . . . . . . . . . . . . . . . .
Interfaces and classes in the sqlj.runtime package . . . . . . . . . . . . . . . . . . . .
sqlj.runtime.ConnectionContext interface . . . . . . . . . . . . . . . . . . . . . .
sqlj.runtime.ForUpdate interface . . . . . . . . . . . . . . . . . . . . . . . . .
sqlj.runtime.NamedIterator interface. . . . . . . . . . . . . . . . . . . . . . . .
sqlj.runtime.PositionedIterator interface. . . . . . . . . . . . . . . . . . . . . . .
sqlj.runtime.ResultSetIterator interface . . . . . . . . . . . . . . . . . . . . . . .
sqlj.runtime.Scrollable interface . . . . . . . . . . . . . . . . . . . . . . . . .
sqlj.runtime.AsciiStream class . . . . . . . . . . . . . . . . . . . . . . . . . .
sqlj.runtime.BinaryStream class . . . . . . . . . . . . . . . . . . . . . . . . .
sqlj.runtime.CharacterStream class . . . . . . . . . . . . . . . . . . . . . . . .
sqlj.runtime.ExecutionContext class . . . . . . . . . . . . . . . . . . . . . . . .
sqlj.runtime.SQLNullException class . . . . . . . . . . . . . . . . . . . . . . . .
sqlj.runtime.StreamWrapper class . . . . . . . . . . . . . . . . . . . . . . . . .
sqlj.runtime.UnicodeStream class . . . . . . . . . . . . . . . . . . . . . . . . .
IBM Data Server Driver for JDBC and SQLJ extensions to JDBC . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
211
217
220
221
222
242
253
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
254
254
256
262
268
283
310
311
311
311
313
313
315
316
317
318
318
321
322
322
323
324
329
329
329
330
332
335
335
336
337
345
345
346
347
Contents
v
DBBatchUpdateException interface . . . . . . . . . . . . . . . . . . . .
DB2BaseDataSource class . . . . . . . . . . . . . . . . . . . . . . .
DB2BlobFileReference class . . . . . . . . . . . . . . . . . . . . . . .
DB2CallableStatement interface . . . . . . . . . . . . . . . . . . . . .
DB2ClientRerouteServerList class . . . . . . . . . . . . . . . . . . . . .
DB2ClobFileReference class. . . . . . . . . . . . . . . . . . . . . . .
DB2Connection interface . . . . . . . . . . . . . . . . . . . . . . .
DB2ConnectionPoolDataSource class . . . . . . . . . . . . . . . . . . .
DB2DatabaseMetaData interface . . . . . . . . . . . . . . . . . . . . .
DB2Diagnosable interface . . . . . . . . . . . . . . . . . . . . . . .
DB2ExceptionFormatter class . . . . . . . . . . . . . . . . . . . . . .
DB2FileReference class . . . . . . . . . . . . . . . . . . . . . . . .
DB2JCCPlugin class . . . . . . . . . . . . . . . . . . . . . . . . .
DB2ParameterMetaData interface . . . . . . . . . . . . . . . . . . . . .
DB2PooledConnection class . . . . . . . . . . . . . . . . . . . . . .
DB2PoolMonitor class . . . . . . . . . . . . . . . . . . . . . . . .
DB2PreparedStatement interface . . . . . . . . . . . . . . . . . . . . .
DB2ResultSet interface . . . . . . . . . . . . . . . . . . . . . . . .
DB2ResultSetMetaData interface . . . . . . . . . . . . . . . . . . . . .
DB2RowID interface . . . . . . . . . . . . . . . . . . . . . . . . .
DB2SimpleDataSource class . . . . . . . . . . . . . . . . . . . . . .
DB2Sqlca class . . . . . . . . . . . . . . . . . . . . . . . . . . .
DB2Statement interface . . . . . . . . . . . . . . . . . . . . . . . .
DB2SystemMonitor interface . . . . . . . . . . . . . . . . . . . . . .
DB2TraceManager class . . . . . . . . . . . . . . . . . . . . . . . .
DB2TraceManagerMXBean interface . . . . . . . . . . . . . . . . . . . .
DB2Types class . . . . . . . . . . . . . . . . . . . . . . . . . . .
DB2XADataSource class . . . . . . . . . . . . . . . . . . . . . . . .
DB2Xml interface . . . . . . . . . . . . . . . . . . . . . . . . . .
DB2XmlAsBlobFileReference class . . . . . . . . . . . . . . . . . . . .
DB2XmlAsClobFileReference class . . . . . . . . . . . . . . . . . . . .
DBTimestamp class . . . . . . . . . . . . . . . . . . . . . . . . .
JDBC differences between versions of the IBM Data Server Driver for JDBC and SQLJ . . . .
Examples of ResultSetMetaData.getColumnName and ResultSetMetaData.getColumnLabel values
Error codes issued by the IBM Data Server Driver for JDBC and SQLJ . . . . . . . . .
SQLSTATEs issued by the IBM Data Server Driver for JDBC and SQLJ . . . . . . . . .
How to find IBM Data Server Driver for JDBC and SQLJ version and environment information .
Commands for SQLJ program preparation. . . . . . . . . . . . . . . . . . .
sqlj - SQLJ translator . . . . . . . . . . . . . . . . . . . . . . . . .
db2sqljcustomize - SQLJ profile customizer . . . . . . . . . . . . . . . . .
db2sqljbind - SQLJ profile binder . . . . . . . . . . . . . . . . . . . . .
db2sqljprint - SQLJ profile printer . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
349
350
357
358
364
366
366
385
387
388
389
389
390
391
391
394
397
411
413
414
414
415
416
418
421
424
428
428
430
432
433
433
435
439
441
447
449
451
451
454
466
472
Chapter 8. Installing the IBM Data Server Driver for JDBC and SQLJ . . . . . . . . 473
Installing the IBM Data Server Driver for JDBC and SQLJ as part of a DB2 installation . . . . .
Jobs for loading the IBM Data Server Driver for JDBC and SQLJ libraries . . . . . . . .
Environment variables for the IBM Data Server Driver for JDBC and SQLJ . . . . . . . .
Customization of IBM Data Server Driver for JDBC and SQLJ configuration properties . . . .
Enabling the DB2-supplied stored procedures used by the IBM Data Server Driver for JDBC and
DB2Binder utility . . . . . . . . . . . . . . . . . . . . . . . . . . .
DB2LobTableCreator utility . . . . . . . . . . . . . . . . . . . . . . . .
Verify the installation of the IBM Data Server Driver for JDBC and SQLJ . . . . . . . .
Upgrading the IBM Data Server Driver for JDBC and SQLJ to a new version . . . . . . . .
Installing the z/OS Application Connectivity to DB2 for z/OS feature . . . . . . . . . .
Jobs for loading the z/OS Application Connectivity to DB2 for z/OS libraries . . . . . . .
Environment variables for the z/OS Application Connectivity to DB2 for z/OS feature. . . .
. .
. .
. .
. .
SQLJ
. .
. .
. .
. .
. .
. .
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
473
474
475
476
478
480
487
488
490
491
493
494
Chapter 9. Security under the IBM Data Server Driver for JDBC and SQLJ . . . . . . 495
User ID and password security under the IBM Data Server Driver for JDBC and SQLJ .
User ID-only security under the IBM Data Server Driver for JDBC and SQLJ . . . .
vi
Application Programming Guide and Reference for Java
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 496
. 498
Encrypted password, user ID, or user ID and password security under the IBM Data Server Driver for
SQLJ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Kerberos security under the IBM Data Server Driver for JDBC and SQLJ . . . . . . . . . .
IBM Data Server Driver for JDBC and SQLJ trusted context support . . . . . . . . . . . .
IBM Data Server Driver for JDBC and SQLJ support for SSL . . . . . . . . . . . . . .
Configuring connections under the IBM Data Server Driver for JDBC and SQLJ to use SSL . . .
Configuring the Java Runtime Environment to use SSL . . . . . . . . . . . . . . .
Security for preparing SQLJ applications with the IBM Data Server Driver for JDBC and SQLJ . . .
JDBC
. .
. .
. .
. .
. .
. .
. .
and
. .
. .
. .
. .
. .
. .
. .
499
501
505
507
507
508
511
Chapter 10. Java client support for high availability on IBM data servers. . . . . . . 513
Java client support for high availability for connections to DB2 Database for Linux, UNIX, and Windows servers
Configuration of DB2 Database for Linux, UNIX, and Windows automatic client reroute support for Java
clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example of enabling DB2 Database for Linux, UNIX, and Windows automatic client reroute support in Java
applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration of DB2 Database for Linux, UNIX, and Windows workload balancing support for Java clients
Example of enabling DB2 Database for Linux, UNIX, and Windows workload balancing support in Java
applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Operation of automatic client reroute for connections to DB2 Database for Linux, UNIX, and Windows from
Java clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Operation of workload balancing for connections to DB2 Database for Linux, UNIX, and Windows . . . .
Application programming requirements for high availability for connections to DB2 Database for Linux,
UNIX, and Windows servers . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Client affinities for DB2 Database for Linux, UNIX, and Windows . . . . . . . . . . . . . . . .
Java client support for high availability for connections to IBM Informix servers . . . . . . . . . . . .
Configuration of IBM Informix high-availability support for Java clients. . . . . . . . . . . . . .
Example of enabling IBM Informix high availability support in Java applications . . . . . . . . . . .
Operation of automatic client reroute for connections to IBM Informix from Java clients . . . . . . . .
Operation of workload balancing for connections to IBM Informix from Java clients. . . . . . . . . .
Application programming requirements for high availability for connections from Java clients to IBM Informix
servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Client affinities for connections to IBM Informix from Java clients . . . . . . . . . . . . . . . .
Java client support for high availability for connections to DB2 for z/OS servers . . . . . . . . . . . .
Configuration of Sysplex workload balancing at a Java client . . . . . . . . . . . . . . . . .
Example of enabling DB2 for z/OS Sysplex workload balancing in Java applications . . . . . . . . .
Operation of Sysplex workload balancing for connections from Java clients to DB2 for z/OS servers . . . .
Operation of automatic client reroute for connections from Java clients to DB2 for z/OS . . . . . . . .
Application programming requirements for high availability for connections from Java clients to DB2 for
z/OS servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Failover support with IBM Data Server Driver for JDBC and SQLJ type 2 connectivity on DB2 for z/OS . . . .
514
515
518
519
520
521
526
527
528
531
532
536
537
541
542
542
546
548
550
553
553
555
555
Chapter 11. JDBC and SQLJ connection pooling support . . . . . . . . . . . . . 557
Chapter 12. IBM Data Server Driver for JDBC and SQLJ type 4 connectivity JDBC and
SQLJ distributed transaction support . . . . . . . . . . . . . . . . . . . . . . 559
Example of a distributed transaction that uses JTA methods .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 560
Chapter 13. JDBC and SQLJ global transaction support . . . . . . . . . . . . . . 565
Chapter 14. Problem diagnosis with the IBM Data Server Driver for JDBC and SQLJ
Example of using configuration properties to start a JDBC trace . . . . . . . . .
Example of a trace program under the IBM Data Server Driver for JDBC and SQLJ . . .
Techniques for monitoring IBM Data Server Driver for JDBC and SQLJ Sysplex support .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
567
.
.
.
. 569
. 569
. 573
Chapter 15. Tracing IBM Data Server Driver for JDBC and SQLJ C/C++ native driver
code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577
db2jcctrace - Format IBM Data Server Driver for JDBC and SQLJ trace data for C/C++ native driver code .
.
Chapter 16. System monitoring for the IBM Data Server Driver for JDBC and SQLJ
Contents
. 577
579
vii
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583
Programming Interface Information . . . . . . . . . . . . . . .
General-use Programming Interface and Associated Guidance Information .
Trademarks . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 584
. 585
. 585
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589
viii
Application Programming Guide and Reference for Java
About this information
This information describes DB2® for z/OS® support for Java. This support lets you
access relational databases from Java application programs.
This information assumes that your DB2 subsystem is running in Version 10
new-function mode. Generally, new functions that are described, including changes
to existing functions, statements, and limits, are available only in new-function
mode, unless explicitly stated otherwise. Exceptions to this general statement
include optimization and virtual storage enhancements, which are also available in
conversion mode unless stated otherwise. In Versions 8 and 9, most utility
functions were available in conversion mode. However, for Version 10, most utility
functions work only in new-function mode.
Who should read this information
This information is for the following users:
v DB2 for z/OS application developers who are familiar with Structured Query
Language (SQL) and who know the Java programming language.
v DB2 for z/OS system programmers who are installing JDBC and SQLJ support.
DB2 Utilities Suite
Important: In this version of DB2 for z/OS, the DB2 Utilities Suite is available as
an optional product. You must separately order and purchase a license to such
utilities, and discussion of those utility functions in this publication is not intended
to otherwise imply that you have a license to them.
The DB2 Utilities Suite can work with DB2 Sort and the DFSORT program, which
you are licensed to use in support of the DB2 utilities even if you do not otherwise
license DFSORT for general use. If your primary sort product is not DFSORT,
consider the following informational APARs mandatory reading:
v II14047/II14213: USE OF DFSORT BY DB2 UTILITIES
v II13495: HOW DFSORT TAKES ADVANTAGE OF 64-BIT REAL
ARCHITECTURE
These informational APARs are periodically updated.
Related information
DB2 utilities packaging (Utility Guide)
Terminology and citations
When referring to a DB2 product other than DB2 for z/OS, this information uses
the product's full name to avoid ambiguity.
The following terms are used as indicated:
DB2
Represents either the DB2 licensed program or a particular DB2 subsystem.
OMEGAMON®
Refers to any of the following products:
v IBM® Tivoli® OMEGAMON XE for DB2 Performance Expert on z/OS
© Copyright IBM Corp. 1998, 2011
ix
v IBM Tivoli OMEGAMON XE for DB2 Performance Monitor on z/OS
v IBM DB2 Performance Expert for Multiplatforms and Workgroups
v IBM DB2 Buffer Pool Analyzer for z/OS
C, C++, and C language
Represent the C or C++ programming language.
CICS® Represents CICS Transaction Server for z/OS.
IMS™ Represents the IMS Database Manager or IMS Transaction Manager.
MVS™ Represents the MVS element of the z/OS operating system, which is
equivalent to the Base Control Program (BCP) component of the z/OS
operating system.
RACF®
Represents the functions that are provided by the RACF component of the
z/OS Security Server.
Accessibility features for DB2 10 for z/OS
Accessibility features help a user who has a physical disability, such as restricted
mobility or limited vision, to use information technology products successfully.
Accessibility features
The following list includes the major accessibility features in z/OS products,
including DB2 10 for z/OS. These features support:
v Keyboard-only operation.
v Interfaces that are commonly used by screen readers and screen magnifiers.
v Customization of display attributes such as color, contrast, and font size
Tip: The Information Management Software for z/OS Solutions Information
Center (which includes information for DB2 10 for z/OS) and its related
publications are accessibility-enabled for the IBM Home Page Reader. You can
operate all features using the keyboard instead of the mouse.
Keyboard navigation
You can access DB2 10 for z/OS ISPF panel functions by using a keyboard or
keyboard shortcut keys.
For information about navigating the DB2 10 for z/OS ISPF panels using TSO/E or
ISPF, refer to the z/OS TSO/E Primer, the z/OS TSO/E User's Guide, and the z/OS
ISPF User's Guide. These guides describe how to navigate each interface, including
the use of keyboard shortcuts or function keys (PF keys). Each guide includes the
default settings for the PF keys and explains how to modify their functions.
Related accessibility information
Online documentation for DB2 10 for z/OS is available in the Information
Management Software for z/OS Solutions Information Center, which is available at
the following website: http://publib.boulder.ibm.com/infocenter/imzic
IBM and accessibility
See the IBM Accessibility Center at http://www.ibm.com/able for more information
about the commitment that IBM has to accessibility.
x
Application Programming Guide and Reference for Java
How to send your comments
Your feedback helps IBM to provide quality information. Please send any
comments that you have about this book or other DB2 for z/OS documentation.
You can use the following methods to provide comments:
v Send your comments by email to [email protected] and include the name of
the product, the version number of the product, and the number of the book. If
you are commenting on specific text, please list the location of the text (for
example, a chapter and section title or a help topic title).
v You can send comments from the web. Visit the DB2 for z/OS - Technical
Resources website at:
http://www.ibm.com/support/docview.wss?rs=64&uid=swg27011656
This website has an online reader comment form that you can use to send
comments.
v You can also send comments by using the Feedback link at the footer of each
page in the Information Management Software for z/OS Solutions Information
Center at http://publib.boulder.ibm.com/infocenter/imzic.
How to read syntax diagrams
Certain conventions apply to the syntax diagrams that are used in IBM
documentation.
Apply the following rules when reading the syntax diagrams that are used in DB2
for z/OS documentation:
v Read the syntax diagrams from left to right, from top to bottom, following the
path of the line.
The ─── symbol indicates the beginning of a statement.
The ─── symbol indicates that the statement syntax is continued on the next
line.
The ─── symbol indicates that a statement is continued from the previous line.
The ─── symbol indicates the end of a statement.
v Required items appear on the horizontal line (the main path).
required_item
v Optional items appear below the main path.
required_item
optional_item
If an optional item appears above the main path, that item has no effect on the
execution of the statement and is used only for readability.
optional_item
required_item
v If you can choose from two or more items, they appear vertically, in a stack.
If you must choose one of the items, one item of the stack appears on the main
path.
About this information
xi
required_item
required_choice1
required_choice2
If choosing one of the items is optional, the entire stack appears below the main
path.
required_item
optional_choice1
optional_choice2
If one of the items is the default, it appears above the main path and the
remaining choices are shown below.
default_choice
required_item
optional_choice
optional_choice
v An arrow returning to the left, above the main line, indicates an item that can be
repeated.
required_item repeatable_item
If the repeat arrow contains a comma, you must separate repeated items with a
comma.
,
required_item repeatable_item
A repeat arrow above a stack indicates that you can repeat the items in the
stack.
v Sometimes a diagram must be split into fragments. The syntax fragment is
shown separately from the main syntax diagram, but the contents of the
fragment should be read as if they are on the main path of the diagram.
required_item
fragment-name
fragment-name:
required_item
optional_name
v With the exception of XPath keywords, keywords appear in uppercase (for
example, FROM). Keywords must be spelled exactly as shown. XPath keywords
are defined as lowercase names, and must be spelled exactly as shown. Variables
appear in all lowercase letters (for example, column-name). They represent
user-supplied names or values.
v If punctuation marks, parentheses, arithmetic operators, or other such symbols
are shown, you must enter them as part of the syntax.
xii
Application Programming Guide and Reference for Java
Chapter 1. Java application development for IBM data servers
The DB2 and IBM Informix® database systems provide driver support for client
applications and applets that are written in Java.
You can access data in DB2 and IBM Informix database systems using JDBC, SQL,
or pureQuery.
JDBC
JDBC is an application programming interface (API) that Java applications use to
access relational databases. IBM data server support for JDBC lets you write Java
applications that access local DB2 or IBM Informix data or remote relational data
on a server that supports DRDA®.
SQLJ
SQLJ provides support for embedded static SQL in Java applications. SQLJ was
initially developed by IBM, Oracle, and Tandem to complement the dynamic SQL
JDBC model with a static SQL model.
For connections to DB2, in general, Java applications use JDBC for dynamic SQL
and SQLJ for static SQL.
For connections to IBM Informix, SQL statements in JDBC or SQLJ applications run
dynamically.
Because SQLJ can inter-operate with JDBC, an application program can use JDBC
and SQLJ within the same unit of work.
pureQuery
pureQuery is a high-performance data access platform that makes it easier to
develop, optimize, secure, and manage data access. It consists of:
v Application programming interfaces that are built for ease of use and for
simplifying the use of best practices
v Development tools, which are delivered in IBM Optim™ Development Studio, for
Java and SQL development
v A runtime, which is delivered in IBM Optim pureQuery Runtime, for optimizing
and securing database access and simplifying management tasks
With pureQuery, you can write Java applications that treat relational data as
objects, whether that data is in databases or JDBC DataSource objects. Your
applications can also treat objects that are stored in in-memory Java collections as
though those objects are relational data. To query or update your relational data or
Java objects, you use SQL.
For more information on pureQuery, see the Integrated Data Management
Information Center.
© Copyright IBM Corp. 1998, 2011
1
Related concepts
Chapter 2, “Supported drivers for JDBC and SQLJ,” on page 3
Related reference
Integrated Data Management Information Center (IBM Data Studio, IBM
Optim Database Administrator, IBM InfoSphere Data Architect, IBM Optim
Development Studio)
2
Application Programming Guide and Reference for Java
Chapter 2. Supported drivers for JDBC and SQLJ
The DB2 product includes support for two types of JDBC driver architecture.
According to the JDBC specification, there are four types of JDBC driver
architectures:
Type 1
Drivers that implement the JDBC API as a mapping to another data access API,
such as Open Database Connectivity (ODBC). Drivers of this type are generally
dependent on a native library, which limits their portability. The DB2 database
system does not provide a type 1 driver.
Type 2
Drivers that are written partly in the Java programming language and partly in
native code. The drivers use a native client library specific to the data source to
which they connect. Because of the native code, their portability is limited.
Type 3
Drivers that use a pure Java client and communicate with a data server using a
data-server-independent protocol. The data server then communicates the
client's requests to the data source. The DB2 database system does not provide
a type 3 driver.
Type 4
Drivers that are pure Java and implement the network protocol for a specific
data source. The client connects directly to the data source.
DB2 for z/OS supports the IBM Data Server Driver for JDBC and SQLJ, which
combines type 2 and type 4 JDBC implementations. The driver is packaged in the
following way:
v db2jcc.jar and sqlj.zip for JDBC 3.0 and earlier support
v db2jcc4.jar and sqlj4.zip for JDBC 4.0 and later, and JDBC 3.0 and earlier support
You control the level of JDBC support that you want by specifying the appropriate
set of files in the CLASSPATH.
IBM Data Server Driver for JDBC and SQLJ (type 2 and type 4)
The IBM Data Server Driver for JDBC and SQLJ is a single driver that includes
JDBC type 2 and JDBC type 4 behavior. When an application loads the IBM Data
Server Driver for JDBC and SQLJ, a single driver instance is loaded for type 2 and
type 4 implementations. The application can make type 2 and type 4 connections
using this single driver instance. The type 2 and type 4 connections can be made
concurrently. IBM Data Server Driver for JDBC and SQLJ type 2 driver behavior is
referred to as IBM Data Server Driver for JDBC and SQLJ type 2 connectivity. IBM
Data Server Driver for JDBC and SQLJ type 4 driver behavior is referred to as IBM
Data Server Driver for JDBC and SQLJ type 4 connectivity.
Two versions of the IBM Data Server Driver for JDBC and SQLJ are available. IBM
Data Server Driver for JDBC and SQLJ version 3.5x is JDBC 3.0-compliant. IBM
Data Server Driver for JDBC and SQLJ version 4.x is JDBC 4.0-compliant.
The IBM Data Server Driver for JDBC and SQLJ supports these JDBC and SQLJ
functions:
© Copyright IBM Corp. 1998, 2011
3
v Version 3.5x supports all of the methods that are described in the JDBC 3.0
specifications.
v Version 4.x supports all of the methods that are described in the JDBC 4.0
specifications.
v SQLJ application programming interfaces, as defined by the SQLJ standards, for
simplified data access from Java applications.
v Connections that are enabled for connection pooling. WebSphere® Application
Server or another application server does the connection pooling.
v Connections to a data server from Java user-defined functions and stored
procedures use IBM Data Server Driver for JDBC and SQLJ type 2 connectivity
only. Applications that call user-defined functions or stored procedures can use
IBM Data Server Driver for JDBC and SQLJ type 2 connectivity or IBM Data
Server Driver for JDBC and SQLJ type 4 connectivity to connect to a data server.
v Support for distributed transaction management. This support implements the
Java 2 Platform, Enterprise Edition (J2EE) Java Transaction Service (JTS) and Java
Transaction API (JTA) specifications, which conform to the X/Open standard for
distributed transactions (Distributed Transaction Processing: The XA Specification,
available from http://www.opengroup.org) (IBM Data Server Driver for JDBC
and SQLJ type 4 connectivity to DB2 for z/OS environment, Version 7 or later,
or to DB2 Database for Linux, UNIX, and Windows).
In general, you should use IBM Data Server Driver for JDBC and SQLJ type 2
connectivity for Java programs that run on the same z/OS system or zSeries®
logical partition (LPAR) as the target DB2 subsystem. Use IBM Data Server Driver
for JDBC and SQLJ type 4 connectivity for Java programs that run on a different
z/OS system or LPAR from the target DB2 subsystem.
For z/OS systems or LPARs that do not have DB2 for z/OS, the z/OS Application
Connectivity to DB2 for z/OS optional feature can be installed to provide IBM
Data Server Driver for JDBC and SQLJ type 4 connectivity to a DB2 Database for
Linux, UNIX, and Windows data server.
To use the IBM Data Server Driver for JDBC and SQLJ, you need Java 2
Technology Edition, SDK 1.4.2 or higher.
Related concepts
“Environment variables for the z/OS Application Connectivity to DB2 for z/OS
feature” on page 494
“Environment variables for the IBM Data Server Driver for JDBC and SQLJ” on
page 475
JDBC driver and database version compatibility
The compatibility of a particular version of the IBM Data Server Driver for JDBC
and SQLJ with a database version depends on the type of driver connectivity that
you are using and the type of data source to which you are connecting.
Compatibility for IBM Data Server Driver for JDBC and SQLJ type
4 connectivity
The IBM Data Server Driver for JDBC and SQLJ is always downward compatible
with DB2 databases at the previous release level. For example, IBM Data Server
Driver for JDBC and SQLJ type 4 connectivity from the IBM Data Server Driver for
JDBC and SQLJ version 3.61, which is shipped with DB2 Database for Linux,
UNIX, and Windows Version 9.7 Fix Pack 3, to a DB2 Database for Linux, UNIX,
and Windows Version 8 database is supported.
4
Application Programming Guide and Reference for Java
The IBM Data Server Driver for JDBC and SQLJ is upward compatible with the
next version of a DB2 database if the applications under which the driver runs use
no new features. For example, IBM Data Server Driver for JDBC and SQLJ type 4
connectivity from the IBM Data Server Driver for JDBC and SQLJ version 2.x,
which is shipped with DB2 for z/OS Version 8, to a DB2 for z/OS Version 9.1
database is supported, if the applications under which the driver runs contain no
DB2 for z/OS Version 9.1 features.
IBM Data Server Driver for JDBC and SQLJ type 4 connectivity to IBM Informix is
supported only for IBM Informix Version 11 and later.
Compatibility for IBM Data Server Driver for JDBC and SQLJ type
2 connectivity
In general, IBM Data Server Driver for JDBC and SQLJ type 2 connectivity is
intended for connections to the local database system, using the driver version that
is shipped with that database version. For example, version 3.6x of the IBM Data
Server Driver for JDBC and SQLJ is shipped with DB2 Database for Linux, UNIX,
and Windows Version 9.5 and Version 9.7, and DB2 for z/OS Version 8 and later.
However, for IBM Data Server Driver for JDBC and SQLJ type 2 connectivity to a
local DB2 Database for Linux, UNIX, and Windows database, the database version
can be one version earlier or one version later than the DB2 Database for Linux,
UNIX, and Windows version with which the driver was shipped. For IBM Data
Server Driver for JDBC and SQLJ type 2 connectivity to a local DB2 for z/OS
subsystem, the subsystem version can be one version later than the DB2 for z/OS
version with which the driver was shipped.
If the database version to which your applications are connecting is later than the
database version with which the driver was shipped, the applications cannot use
features of the later database version.
Related concepts
Chapter 2, “Supported drivers for JDBC and SQLJ,” on page 3
DB2 for z/OS and IBM Data Server Driver for JDBC and SQLJ levels
Each version of the IBM Data Server Driver for JDBC and SQLJ is shipped as a
DB2 for z/OS APAR.
The following table lists the major 4.x versions of the IBM Data Server Driver for
JDBC and SQLJ and the DB2 for z/OS Version 9 APAR that delivered the initial
release of each version.
Table 1. IBM Data Server Driver for JDBC and SQLJ 4.x versions and corresponding DB2 for
z/OS Version 9 APARs
IBM Data Server Driver for JDBC and SQLJ
version
DB2 for z/OS Version 9 APAR/PTF
4.8
PM02862/UK52963
4.7
PK87569/UK48782
4.3
PK75093/UK43777
The following table lists the major 3.x versions of the IBM Data Server Driver for
JDBC and SQLJ and the DB2 for z/OS Version 9 APAR that delivered the initial
release of each version.
Chapter 2. Supported drivers for JDBC and SQLJ
5
Table 2. IBM Data Server Driver for JDBC and SQLJ 3.x versions and corresponding DB2 for
z/OS Version 9 APARs
IBM Data Server Driver for JDBC and SQLJ
version
DB2 for z/OS Version 9 APAR/PTF
3.58
PK93123/UK52962
3.57
PK87567/UK48236
3.53
PK71020/UK42554
3.52
PK65069/UK39205
3.51
PK68428/UK38507
3.6
PK49868/UK32181
3.4
PK46324/UK29044
3.3
PK36170/UK22777
The following table lists the major 3.x versions of the IBM Data Server Driver for
JDBC and SQLJ and the DB2 for z/OS Version 8 APAR that delivered the initial
release of each version.
Table 3. IBM Data Server Driver for JDBC and SQLJ 3.x versions and corresponding DB2 for
z/OS Version 8 APARs
IBM Data Server Driver for JDBC and SQLJ
version
DB2 for z/OS Version 8 APAR/PTF
3.58
PK93123/UK52961
3.57
PK87567/UK48235
3.53
PK71020/UK42553
3.52
PK65069/UK39204
The following table lists the major 2.x versions of the IBM Data Server Driver for
JDBC and SQLJ and theDB2 for z/OS Version 8 APAR APAR that delivered the
initial release of each version.
Table 4. IBM Data Server Driver for JDBC and SQLJ 2.x versions and corresponding DB2 for
z/OS Version 8 APARs
IBM Data Server Driver for JDBC and SQLJ
version
DB2 for z/OS Version 8 APAR/PTF
2.11
PK54969/UK35429
2.10
PK25139/UK18527
2.9
PK19585/UK14851
2.8
PK18158/UK12333
2.7
PK13108/UK11330
DB2 for Linux, UNIX, and Windows and IBM Data Server Driver for
JDBC and SQLJ levels
Each version of DB2 for Linux, UNIX, and Windows is shipped with a different
version of the IBM Data Server Driver for JDBC and SQLJ.
6
Application Programming Guide and Reference for Java
The following table lists the IBM Data Server Driver for JDBC and SQLJ versions
and corresponding DB2 for Linux, UNIX, and Windows versions. You can use this
information to determine the level of DB2 for Linux, UNIX, and Windows or DB2
Connect™ that is associated with the IBM Data Server Driver for JDBC and SQLJ
instance under which a client program is running.
Table 5. Versions of IBM Data Server Driver for JDBC and SQLJ and DB2 for Linux, UNIX,
and Windows
IBM Data Server Driver for JDBC and SQLJ DB2 for Linux, UNIX, and Windows version
version
and fix pack level
3.5x.xx1, 4.x.xx1
Version 9.7
3.8.xx
1
Version 9.1 Fix Pack 6 and later
3.7.xx
1
Version 9.1 Fix Pack 5
3.6.xx
1
Version 9.1 Fix Pack 4
3.4.xx
1
Version 9.1 Fix Pack 3
3.3.xx
1
Version 9.1 Fix Pack 2
3.2.xx
1
Version 9.1 Fix Pack 1
3.1.xx
1
Version 9.1
2.10.52
Version 8.1 Fix Pack 14 (Version 8.2 Fix Pack
7)
2.10.27
Version 8.1 Fix Pack 13 (Version 8.2 Fix Pack
6)
2.9.31
Version 8.1 Fix Pack 12 (Version 8.2 Fix Pack
5)
2.8.46
Version 8.1 Fix Pack 11 (Version 8.2 Fix Pack
4)
2.7.58
Version 8.1 Fix Pack 10 (Version 8.2 Fix Pack
3)
2.6.80
Version 8.1 Fix Pack 9 (Version 8.2 Fix Pack
2)
2.5.33
Version 8.1 Fix Pack 8 (Version 8.2 Fix Pack
1)
2.3.63
Version 8.1 Fix Pack 7 (Version 8.2)
2.2.49
Version 8.1 Fix Pack 6
1.9.23
Version 8.1 Fix Pack 5
1.5.54
Version 8.1 Fix Pack 4a
1.3.70
Version 8.1 Fix Pack 3
1.2.117
Version 8.1 Fix Pack 2
1.1.67
Version 8.1 Fix Pack 1
1.0.581
Version 8.1
Note:
1. xx is different for each new version of the IBM Data Server Driver for JDBC and SQLJ
that is introduced through an APAR.
Chapter 2. Supported drivers for JDBC and SQLJ
7
8
Application Programming Guide and Reference for Java
Chapter 3. JDBC application programming
Writing a JDBC application has much in common with writing an SQL application
in any other language.
In general, you need to do the following things:
v Access the Java packages that contain JDBC methods.
v Declare variables for sending data to or retrieving data from DB2 tables.
v Connect to a data source.
v Execute SQL statements.
v Handle SQL errors and warnings.
v Disconnect from the data source.
Although the tasks that you need to perform are similar to those in other
languages, the way that you execute those tasks is somewhat different.
Example of a simple JDBC application
A simple JDBC application demonstrates the basic elements that JDBC applications
need to include.
Figure 1. Simple JDBC application
import java.sql.*;
public class EzJava
{
public static void main(String[] args)
{
String urlPrefix = "jdbc:db2:";
String url;
String user;
String password;
String empNo;
Connection con;
Statement stmt;
ResultSet rs;
1
2
System.out.println ("**** Enter class EzJava");
//
//
//
//
//
//
//
//
//
//
Check the that first argument has the correct form for the portion
of the URL that follows jdbc:db2:,
as described
in the Connecting to a data source using the DriverManager
interface with the IBM Data Server Driver for JDBC and SQLJ topic.
For example, for IBM Data Server Driver for
JDBC and SQLJ type 2 connectivity,
args[0] might be MVS1DB2M. For
type 4 connectivity, args[0] might
be //stlmvs1:10110/MVS1DB2M.
if (args.length!=3)
{
System.err.println ("Invalid value. First argument appended to "+
"jdbc:db2: must specify a valid URL.");
System.err.println ("Second argument must be a valid user ID.");
System.err.println ("Third argument must be the password for the user ID.");
© Copyright IBM Corp. 1998, 2011
9
System.exit(1);
}
url = urlPrefix + args[0];
user = args[1];
password = args[2];
try
{
// Load the driver
Class.forName("com.ibm.db2.jcc.DB2Driver");
System.out.println("**** Loaded the JDBC driver");
3a
// Create the connection using the IBM Data Server Driver for JDBC and SQLJ
con = DriverManager.getConnection (url, user, password);
3b
// Commit changes manually
con.setAutoCommit(false);
System.out.println("**** Created a JDBC connection to the data source");
// Create the Statement
stmt = con.createStatement();
System.out.println("**** Created JDBC Statement object");
4a
// Execute a query and generate a ResultSet instance
rs = stmt.executeQuery("SELECT EMPNO FROM EMPLOYEE");
System.out.println("**** Created JDBC ResultSet object");
4b
// Print all of the employee numbers to standard output device
while (rs.next()) {
empNo = rs.getString(1);
System.out.println("Employee number = " + empNo);
}
System.out.println("**** Fetched all rows from JDBC ResultSet");
// Close the ResultSet
rs.close();
System.out.println("**** Closed JDBC ResultSet");
// Close the Statement
stmt.close();
System.out.println("**** Closed JDBC Statement");
// Connection must be on a unit-of-work boundary to allow close
con.commit();
System.out.println ( "**** Transaction committed" );
// Close the connection
con.close();
System.out.println("**** Disconnected from data source");
6
System.out.println("**** JDBC Exit from class EzJava - no errors");
}
catch (ClassNotFoundException e)
{
System.err.println("Could not load JDBC driver");
System.out.println("Exception: " + e);
e.printStackTrace();
}
catch(SQLException ex)
5
{
System.err.println("SQLException information");
while(ex!=null) {
System.err.println ("Error msg: " + ex.getMessage());
System.err.println ("SQLSTATE: " + ex.getSQLState());
System.err.println ("Error code: " + ex.getErrorCode());
ex.printStackTrace();
ex = ex.getNextException(); // For drivers that support chained exceptions
10
Application Programming Guide and Reference for Java
}
}
}
}
// End main
// End EzJava
Notes to Figure 1 on page 9:
Note
1
2
3a and 3b
4a and 4b
5
6
Description
This statement imports the java.sql package, which contains the JDBC core API.
For information on other Java packages that you might need to access, see "Java
packages for JDBC support".
String variable empNo performs the function of a host variable. That is, it is
used to hold data retrieved from an SQL query. See "Variables in JDBC
applications" for more information.
These two sets of statements demonstrate how to connect to a data source using
one of two available interfaces. See "How JDBC applications connect to a data
source" for more details.
Step 3a (loading the JDBC driver) is not necessary if you use JDBC 4.0.
These two sets of statements demonstrate how to perform a SELECT in JDBC.
For information on how to perform other SQL operations, see "JDBC interfaces
for executing SQL".
This try/catch block demonstrates the use of the SQLException class for SQL
error handling. For more information on handling SQL errors, see "Handling an
SQLException under the IBM Data Server Driver for JDBC and SQLJ". For
information on handling SQL warnings, see "Handling an SQLWarning under
the IBM Data Server Driver for JDBC and SQLJ".
This statement disconnects the application from the data source. See
"Disconnecting from data sources in JDBC applications".
Related concepts
“Java packages for JDBC support” on page 21
“How JDBC applications connect to a data source”
“Variables in JDBC applications” on page 24
“JDBC interfaces for executing SQL” on page 24
Related tasks
“Handling an SQLWarning under the IBM Data Server Driver for JDBC and SQLJ”
on page 106
“Disconnecting from data sources in JDBC applications” on page 110
How JDBC applications connect to a data source
Before you can execute SQL statements in any SQL program, you must be
connected to a data source.
The IBM Data Server Driver for JDBC and SQLJ supports type 2 and type 4
connectivity. Connections to DB2 databases can use type 2 or type 4 connectivity.
Connections to IBM Informix databases can use type 4 connectivity.
The following figure shows how a Java application connects to a data source using
IBM Data Server Driver for JDBC and SQLJ type 2 connectivity.
Chapter 3. JDBC application programming
11
Java application
DriverManager
or
DataSource
JDBC driver*
Local database
or DB2
subsystem
Database
server
*Java byte code executed under JVM,
and native code
Figure 2. Java application flow for IBM Data Server Driver for JDBC and SQLJ type 2
connectivity
The following figure shows how a Java application connects to a data source using
IBM Data Server Driver for JDBC and SQLJ type 4 connectivity.
Java application
DriverManager
or
DataSource
JDBC driver*
DRDA
Database
server
*Java byte code executed under JVM
Figure 3. Java application flow for IBM Data Server Driver for JDBC and SQLJ type 4
connectivity
12
Application Programming Guide and Reference for Java
Related tasks
“Connecting to a data source using SQLJ” on page 113
“Connecting to a data source using the DriverManager interface with the IBM Data
Server Driver for JDBC and SQLJ”
Connecting to a data source using the DriverManager
interface with the IBM Data Server Driver for JDBC and SQLJ
A JDBC application can establish a connection to a data source using the JDBC
DriverManager interface, which is part of the java.sql package.
The steps for establishing a connection are:
1. Load the JDBC driver by invoking the Class.forName method.
If you are using JDBC 4.0, you do not need to explicitly load the JDBC driver.
For the IBM Data Server Driver for JDBC and SQLJ, you load the driver by
invoking the Class.forName method with the following argument:
com.ibm.db2.jcc.DB2Driver
For compatibility with previous JDBC drivers, you can use the following
argument instead:
COM.ibm.db2os390.sqlj.jdbc.DB2SQLJDriver
The following code demonstrates loading the IBM Data Server Driver for JDBC
and SQLJ:
try {
// Load the IBM Data Server Driver for JDBC and SQLJ with DriverManager
Class.forName("com.ibm.db2.jcc.DB2Driver");
} catch (ClassNotFoundException e) {
e.printStackTrace();
}
The catch block is used to print an error if the driver is not found.
2. Connect to a data source by invoking the DriverManager.getConnection
method.
You can use one of the following forms of getConnection:
getConnection(String url);
getConnection(String url, user, password);
getConnection(String url, java.util.Properties info);
For IBM Data Server Driver for JDBC and SQLJ type 4 connectivity, the
getConnection method must specify a user ID and password, through
parameters or through property values.
The url argument represents a data source, and indicates what type of JDBC
connectivity you are using.
The info argument is an object of type java.util.Properties that contains a set
of driver properties for the connection. Specifying the info argument is an
alternative to specifying property=value; strings in the URL. See "Properties for
the IBM Data Server Driver for JDBC and SQLJ" for the properties that you can
specify.
There are several ways to specify a user ID and password for a connection:
v Use the form of the getConnection method that specifies url with
property=value; clauses, and include the user and password properties in the
URL.
v Use the form of the getConnection method that specifies user and password.
Chapter 3. JDBC application programming
13
v Use the form of the getConnection method that specifies info, after setting the
user and password properties in a java.util.Properties object.
Example: Establishing a connection and setting the user ID and password in a URL:
String url = "jdbc:db2://myhost:5021/mydb:" +
"user=dbadm;password=dbadm;";
// Set URL for data source
Connection con = DriverManager.getConnection(url);
// Create connection
Example: Establishing a connection and setting the user ID and password in user and
password parameters:
String url = "jdbc:db2://myhost:5021/mydb";
// Set URL for data source
String user = "dbadm";
String password = "dbadm";
Connection con = DriverManager.getConnection(url, user, password);
// Create connection
Example: Establishing a connection and setting the user ID and password in a
java.util.Properties object:
Properties properties = new Properties(); // Create Properties object
properties.put("user", "dbadm");
// Set user ID for connection
properties.put("password", "dbadm");
// Set password for connection
String url = "jdbc:db2://myhost:5021/mydb";
// Set URL for data source
Connection con = DriverManager.getConnection(url, properties);
// Create connection
Related tasks
“Connecting to a data source using the DriverManager interface with the IBM Data
Server Driver for JDBC and SQLJ” on page 13
URL format for IBM Data Server Driver for JDBC and SQLJ type
4 connectivity
If you are using type 4 connectivity in your JDBC application, and you are making
a connection using the DriverManager interface, you need to specify a URL in the
DriverManager.getConnection call that indicates type 4 connectivity.
IBM Data Server Driver for JDBC and SQLJ type 4 connectivity URL
syntax
jdbc:db2:
jdbc:db2j:net:
jdbc:ids:
//
server
/
:
database
port
:
property
=
value
;
IBM Data Server Driver for JDBC and SQLJ type 4 connectivity URL
option descriptions
The parts of the URL have the following meanings:
jdbc:db2: or jdbc:db2j:net:
The meanings of the initial portion of the URL are:
jdbc:db2:
Indicates that the connection is to a DB2 for z/OS, DB2 Database for
Linux, UNIX, and Windows.
14
Application Programming Guide and Reference for Java
jdbc:db2: can also be used for a connection to an IBM Informix
database, for application portability.
jdbc:db2j:net:
Indicates that the connection is to a remote IBM Cloudscape server.
jdbc:ids:
Indicates that the connection is to an IBM Informix data source.
jdbc:informix-sqli: also indicates that the connection is to an IBM
Informix data source, but jdbc:ids: should be used.
server
The domain name or IP address of the data source.
port
The TCP/IP server port number that is assigned to the data source. This is an
integer between 0 and 65535. The default is 446.
database
A name for the data source.
v If the connection is to a DB2 for z/OS server, database is the DB2 location
name that is defined during installation. All characters in the DB2 location
name must be uppercase characters. The IBM Data Server Driver for JDBC
and SQLJ does not convert lowercase characters in the database value to
uppercase for IBM Data Server Driver for JDBC and SQLJ type 4
connectivity.
You can determine the location name by executing the following SQL
statement on the server:
SELECT CURRENT SERVER FROM SYSIBM.SYSDUMMY1;
v If the connection is to a DB2 for z/OS server or a DB2 for i server, all
characters in database must be uppercase characters.
v If the connection is to a DB2 Database for Linux, UNIX, and Windows
server, database is the database name that is defined during installation.
v If the connection is to an IBM Informix server, database is the database name.
The name is case-insensitive. The server converts the name to lowercase.
v If the connection is to an IBM Cloudscape server, the database is the
fully-qualified name of the file that contains the database. This name must
be enclosed in double quotation marks ("). For example:
"c:/databases/testdb"
property=value;
A property and its value for the JDBC connection. You can specify one or more
property and value pairs. Each property and value pair, including the last one,
must end with a semicolon (;). Do not include spaces or other white space
characters anywhere within the list of property and value strings.
Some properties with an int data type have predefined constant field values.
You must resolve constant field values to their integer values before you can
use those values in the url parameter. For example, you cannot use
com.ibm.db2.jcc.DB2BaseDataSource.TRACE_ALL in a url parameter. However,
you can build a URL string that includes
com.ibm.db2.jcc.DB2BaseDataSource.TRACE_ALL, and assign the URL string
to a String variable. Then you can use the String variable in the url parameter:
String url =
"jdbc:db2://sysmvs1.stl.ibm.com:5021/STLEC1" +
":user=dbadm;password=dbadm;" +
"traceLevel=" +
Chapter 3. JDBC application programming
15
(com.ibm.db2.jcc.DB2BaseDataSource.TRACE_ALL) + ";";
Connection con =
java.sql.DriverManager.getConnection(url);
URL format for IBM Data Server Driver for JDBC and SQLJ type
2 connectivity
If you are using type 2 connectivity in your JDBC application, and you are making
a connection using the DriverManager interface, you need to specify a URL in the
DriverManager.getConnection call that indicates type 2 connectivity.
IBM Data Server Driver for JDBC and SQLJ type 2 connectivity URL
syntax
jdbc
jdbc
jdbc
jdbc
jdbc
jdbc
:
:
:
:
:
:
db2 : database
db2os390 : database
db2os390sqlj : database
default : connection
db2os390 :
db2os390sqlj :
property
:
property
=
value
=
value
;
;
IBM Data Server Driver for JDBC and SQLJ type 2 connectivity URL
options descriptions
The parts of the URL have the following meanings:
jdbc:db2: or jdbc:db2os390: or jdbc:db2os390sqlj: or jdbc:default:connection
The meanings of the initial portion of the URL are:
jdbc:db2: or jdbc:db2os390: or jdbc:db2os390sqlj:
Indicates that the connection is to a DB2 for z/OS or DB2 Database for
Linux, UNIX, and Windows server. jdbc:db2os390: and
jdbc:db2os390sqlj: are for compatibility of programs that were written
for older drivers, and apply to IBM Data Server Driver for JDBC and
SQLJ type 2 connectivity to DB2 for z/OS only.
jdbc:default:connection
Indicates that the URL is for a connection to the local subsystem
through a DB2 thread that is controlled by CICS, IMS, or the Java
stored procedure environment.
database
A name for the database server.
v database is a location name that is defined in the SYSIBM.LOCATIONS
catalog table.
All characters in the DB2 location name must be uppercase characters.
However, for a connection to a DB2 for z/OS server, the IBM Data Server
Driver for JDBC and SQLJ converts lowercase characters in the database
value to uppercase.
property=value;
A property and its value for the JDBC connection. You can specify one or more
property and value pairs. Each property and value pair, including the last one,
must end with a semicolon (;). Do not include spaces or other white space
characters anywhere within the list of property and value strings.
16
Application Programming Guide and Reference for Java
Some properties with an int data type have predefined constant field values.
You must resolve constant field values to their integer values before you can
use those values in the url parameter. For example, you cannot use
com.ibm.db2.jcc.DB2BaseDataSource.TRACE_ALL in a url parameter. However,
you can build a URL string that includes
com.ibm.db2.jcc.DB2BaseDataSource.TRACE_ALL, and assign the URL string
to a String variable. Then you can use the String variable in the url parameter:
String url =
"jdbc:db2:STLEC1" +
":user=dbadm;password=dbadm;" +
"traceLevel=" +
(com.ibm.db2.jcc.DB2BaseDataSource.TRACE_ALL) + ";";
Connection con =
java.sql.DriverManager.getConnection(url);
Connecting to a data source using the DataSource interface
If your applications need to be portable among data sources, you should use the
DataSource interface.
Using DriverManager to connect to a data source reduces portability because the
application must identify a specific JDBC driver class name and driver URL. The
driver class name and driver URL are specific to a JDBC vendor, driver
implementation, and data source.
When you connect to a data source using the DataSource interface, you use a
DataSource object.
The simplest way to use a DataSource object is to create and use the object in the
same application, as you do with the DriverManager interface. However, this
method does not provide portability.
The best way to use a DataSource object is for your system administrator to create
and manage it separately, using WebSphere Application Server or some other tool.
The program that creates and manages a DataSource object also uses the Java
Naming and Directory Interface (JNDI) to assign a logical name to the DataSource
object. The JDBC application that uses the DataSource object can then refer to the
object by its logical name, and does not need any information about the underlying
data source. In addition, your system administrator can modify the data source
attributes, and you do not need to change your application program.
To learn more about using WebSphere to deploy DataSource objects, go to this
URL on the web:
http://www.ibm.com/software/webservers/appserv/
To learn about deploying DataSource objects yourself, see "Creating and deploying
DataSource objects".
You can use the DataSource interface and the DriverManager interface in the same
application, but for maximum portability, it is recommended that you use only the
DataSource interface to obtain connections.
To obtain a connection using a DataSource object that the system administrator has
already created and assigned a logical name to, follow these steps:
1. From your system administrator, obtain the logical name of the data source to
which you need to connect.
Chapter 3. JDBC application programming
17
2. Create a Context object to use in the next step. The Context interface is part of
the Java Naming and Directory Interface (JNDI), not JDBC.
3. In your application program, use JNDI to get the DataSource object that is
associated with the logical data source name.
4. Use the DataSource.getConnection method to obtain the connection.
You can use one of the following forms of the getConnection method:
getConnection();
getConnection(String user, String password);
Use the second form if you need to specify a user ID and password for the
connection that are different from the ones that were specified when the
DataSource was deployed.
Example of obtaining a connection using a DataSource object that was created by the
system administrator: In this example, the logical name of the data source that you
need to connect to is jdbc/sampledb. The numbers to the right of selected
statements correspond to the previously-described steps.
import java.sql.*;
import javax.naming.*;
import javax.sql.*;
...
Context ctx=new InitialContext();
2
DataSource ds=(DataSource)ctx.lookup("jdbc/sampledb"); 3
Connection con=ds.getConnection();
4
Figure 4. Obtaining a connection using a DataSource object
Example of creating and using a DataSource object in the same application:
Figure 5. Creating and using a DataSource object in the same application
import java.sql.*;
// JDBC base
import javax.sql.*;
// Addtional methods for JDBC
import com.ibm.db2.jcc.*; // IBM Data Server Driver for JDBC and SQLJ
// interfaces
DB2SimpleDataSource dbds=new DB2SimpleDataSource();
2
dbds.setDatabaseName("dbloc1");
3
// Assign the location name
dbds.setDescription("Our Sample Database");
// Description for documentation
dbds.setUser("john");
// Assign the user ID
dbds.setPassword("dbadm");
// Assign the password
Connection con=dbds.getConnection();
4
// Create a Connection object
Note
1
2
3
18
1
Description
Import the package that contains the implementation of the DataSource interface.
Creates a DB2SimpleDataSource object. DB2SimpleDataSource is one of the IBM Data
Server Driver for JDBC and SQLJ implementations of the DataSource interface. See
"Creating and deploying DataSource objects" for information on DB2's DataSource
implementations.
The setDatabaseName, setDescription, setUser, and setPassword methods assign
attributes to the DB2SimpleDataSource object. See "Properties for the IBM Data
Server Driver for JDBC and SQLJ" for information about the attributes that you
can set for a DB2SimpleDataSource object under the IBM Data Server Driver for
JDBC and SQLJ.
Application Programming Guide and Reference for Java
Note
4
Description
Establishes a connection to the data source that DB2SimpleDataSource object dbds
represents.
Related tasks
“Connecting to a data source using SQLJ” on page 113
How to determine which type of IBM Data Server Driver for
JDBC and SQLJ connectivity to use
The IBM Data Server Driver for JDBC and SQLJ supports two types of
connectivity: type 2 connectivity and type 4 connectivity.
For the DriverManager interface, you specify the type of connectivity through the
URL in the DriverManager.getConnection method. For the DataSource interface,
you specify the type of connectivity through the driverType property.
The following table summarizes the differences between type 2 connectivity and
type 4 connectivity:
Table 6. Comparison of IBM Data Server Driver for JDBC and SQLJ type 2 connectivity and IBM Data Server Driver
for JDBC and SQLJ type 4 connectivity
IBM Data Server Driver for JDBC
and SQLJ type 2 connectivity
support
Function
IBM Data Server Driver for JDBC
and SQLJ type 4 connectivity
support
Performance
Better for accessing a local DB2 server Better for accessing a remote DB2
server
Installation
Requires installation of native
libraries in addition to Java classes
Requires installation of Java classes
only
Stored procedures
Can be used to call or execute stored
procedures
Can be used only to call stored
procedures
Distributed transaction processing
(XA)
Not supported
Supported
J2EE 1.4 compliance
Compliant
Compliant
CICS environment
Supported
Not supported
IMS environment
Supported
Not supported
The following points can help you determine which type of connectivity to use.
Use IBM Data Server Driver for JDBC and SQLJ type 2 connectivity under these
circumstances:
v Your JDBC or SQLJ application runs locally most of the time.
Local applications have better performance with type 2 connectivity.
v You are running a Java stored procedure.
A stored procedure environment consists of two parts: a client program, from
which you call a stored procedure, and a server program, which is the stored
procedure. You can call a stored procedure in a JDBC or SQLJ program that uses
type 2 or type 4 connectivity, but you must run a Java stored procedure using
type 2 connectivity.
v Your application runs in the CICS environment or IMS environment.
Chapter 3. JDBC application programming
19
Use IBM Data Server Driver for JDBC and SQLJ type 4 connectivity under these
circumstances:
v Your JDBC or SQLJ application runs remotely most of the time.
Remote applications have better performance with type 4 connectivity.
v You are using IBM Data Server Driver for JDBC and SQLJ connection
concentrator and Sysplex workload balancing support.
JDBC connection objects
When you connect to a data source by either connection method, you create a
Connection object, which represents the connection to the data source.
You use this Connection object to do the following things:
v Create Statement, PreparedStatement, and CallableStatement objects for
executing SQL statements. These are discussed in "Executing SQL statements in
JDBC applications".
v Gather information about the data source to which you are connected. This
process is discussed in "Learning about a data source using DatabaseMetaData
methods".
v Commit or roll back transactions. You can commit transactions manually or
automatically. These operations are discussed in "Commit or roll back a JDBC
transaction".
v Close the connection to the data source. This operation is discussed in
"Disconnecting from data sources in JDBC applications".
Related concepts
“JDBC interfaces for executing SQL” on page 24
Related tasks
“Disconnecting from data sources in JDBC applications” on page 110
“Committing or rolling back JDBC transactions” on page 99
“Learning about a data source using DatabaseMetaData methods” on page 22
Creating and deploying DataSource objects
JDBC versions starting with version 2.0 provide the DataSource interface for
connecting to a data source. Using the DataSource interface is the preferred way to
connect to a data source.
Using the DataSource interface involves two parts:
v Creating and deploying DataSource objects. This is usually done by a system
administrator, using a tool such as WebSphere Application Server.
v Using the DataSource objects to create a connection. This is done in the
application program.
This topic contains information that you need if you create and deploy the
DataSource objects yourself.
The IBM Data Server Driver for JDBC and SQLJ provides the following DataSource
implementations:
v com.ibm.db2.jcc.DB2SimpleDataSource, which does not support connection
pooling. You can use this implementation with IBM Data Server Driver for JDBC
and SQLJ type 2 connectivity or IBM Data Server Driver for JDBC and SQLJ
type 4 connectivity.
20
Application Programming Guide and Reference for Java
v com.ibm.db2.jcc.DB2ConnectionPoolDataSource, which supports connection
pooling. You can use this implementation with IBM Data Server Driver for JDBC
and SQLJ type 2 connectivity or IBM Data Server Driver for JDBC and SQLJ
type 4 connectivity.
v com.ibm.db2.jcc.DB2XADataSource, which supports connection pooling and
distributed transactions. The connection pooling is provided by WebSphere
Application Server or another application server. You can use this
implementation only with IBM Data Server Driver for JDBC and SQLJ type 4
connectivity.
When you create and deploy a DataSource object, you need to perform these tasks:
1. Create an instance of the appropriate DataSource implementation.
2. Set the properties of the DataSource object.
3. Register the object with the Java Naming and Directory Interface (JNDI)
naming service.
The following example shows how to perform these tasks.
import
import
import
import
java.sql.*;
javax.naming.*;
javax.sql.*;
com.ibm.db2.jcc.*;
//
//
//
//
//
//
//
JDBC base
JNDI Naming Services
Additional methods for JDBC
IBM Data Server Driver for
JDBC and SQLJ
implementation of JDBC
standard extension APIs
DB2SimpleDataSource dbds = new com.ibm.db2.jcc.DB2SimpleDataSource();
1
dbds.setDatabaseName("db2loc1");
dbds.setDescription("Our Sample Database");
dbds.setUser("john");
dbds.setPassword("mypw");
...
Context ctx=new InitialContext();
Ctx.bind("jdbc/sampledb",dbds);
2
3
4
Figure 6. Example of creating and deploying a DataSource object
Note
1
2
3
4
Description
Creates an instance of the DB2SimpleDataSource class.
This statement and the next three statements set values for properties of this
DB2SimpleDataSource object.
Creates a context for use by JNDI.
Associates DBSimple2DataSource object dbds with the logical name jdbc/sampledb.
An application that uses this object can refer to it by the name jdbc/sampledb.
Related tasks
“Connecting to a data source using the DataSource interface” on page 17
Related reference
“Properties for the IBM Data Server Driver for JDBC and SQLJ” on page 221
Java packages for JDBC support
Before you can invoke JDBC methods, you need to be able to access all or parts of
various Java packages that contain those methods.
Chapter 3. JDBC application programming
21
You can do that either by importing the packages or specific classes, or by using
the fully-qualified class names. You might need the following packages or classes
for your JDBC program:
java.sql
Contains the core JDBC API.
javax.naming
Contains classes and interfaces for Java Naming and Directory Interface
(JNDI), which is often used for implementing a DataSource.
javax.sql
Contains methods for producing server-side applications using Java
com.ibm.db2.jcc
Contains the implementation of JDBC for the IBM Data Server Driver for
JDBC and SQLJ.
Related concepts
“Example of a simple JDBC application” on page 9
Learning about a data source using DatabaseMetaData methods
The DatabaseMetaData interface contains methods that retrieve information about a
data source. These methods are useful when you write generic applications that
can access various data sources.
In generic applications that can access various data sources, you need to test
whether a data source can handle various database operations before you execute
them. For example, you need to determine whether the driver at a data source is at
the JDBC 3.0 level before you invoke JDBC 3.0 methods against that driver.
DatabaseMetaData methods provide the following types of information:
v Features that the data source supports, such as the ANSI SQL level
v Specific information about the JDBC driver, such as the driver level
v Limits, such as the maximum number of columns that an index can have
v Whether the data source supports data definition statements (CREATE, ALTER,
DROP, GRANT, REVOKE)
v Lists of objects at the data source, such as tables, indexes, or procedures
v Whether the data source supports various JDBC functions, such as batch updates
or scrollable ResultSets
v A list of scalar functions that the driver supports
To invoke DatabaseMetaData methods, you need to perform these basic steps:
1. Create a DatabaseMetaData object by invoking the getMetaData method on the
connection.
2. Invoke DatabaseMetaData methods to get information about the data source.
3. If the method returns a ResultSet:
a. In a loop, position the cursor using the next method, and retrieve data from
each column of the current row of the ResultSet object using getXXX
methods.
b. Invoke the close method to close the ResultSet object.
Example: The following code demonstrates how to use DatabaseMetaData methods
to determine the driver version, to get a list of the stored procedures that are
available at the data source, and to get a list of datetime functions that the driver
supports. The numbers to the right of selected statements correspond to the
22
Application Programming Guide and Reference for Java
previously-described steps.
Figure 7. Using DatabaseMetaData methods to get information about a data source
Connection con;
DatabaseMetaData dbmtadta;
ResultSet rs;
int mtadtaint;
String procSchema;
String procName;
String dtfnList;
...
dbmtadta = con.getMetaData();
// Create the DatabaseMetaData object 1
mtadtaint = dmtadta.getDriverVersion();
2
// Check the driver version
System.out.println("Driver version: " + mtadtaint);
rs = dbmtadta.getProcedures(null, null, "%");
// Get information for all procedures
while (rs.next()) {
// Position the cursor
3a
procSchema = rs.getString("PROCEDURE_SCHEM");
// Get procedure schema
procName = rs.getString("PROCEDURE_NAME");
// Get procedure name
System.out.println(procSchema + "." + procName);
// Print the qualified procedure name
}
dtfnList = dbmtadta.getTimeDateFunctions();
// Get list of supported datetime functions
System.out.println("Supported datetime functions:");
System.out.println(dtfnList);
// Print the list of datetime functions
rs.close();
// Close the ResultSet
3b
Related reference
“Driver support for JDBC APIs” on page 283
DatabaseMetaData methods for identifying the type of data
source
You can use the DatabaseMetaData.getDatabaseProductName and
DatabaseMetaData.getProductVersion methods to identify the type and level of the
database manager to which you are connected, and the operating system on which
the database manager is running.
DatabaseMetaData.getDatabaseProductName returns a string that identifies the
database manager and the operating system. The string has one of the following
formats:
database-product
database-product/operating-system
The following table shows examples of values that are returned by
DatabaseMetaData.getDatabaseProductName.
Table 7. Examples of DatabaseMetaData.getDatabaseProductName values
getDatabaseProductName value
Database product
DB2
DB2 for z/OS
DB2/LINUXX8664
DB2 Database for Linux, UNIX, and Windows on Linux
on x86
IBM Informix/UNIX64
IBM Informix on UNIX
Chapter 3. JDBC application programming
23
DatabaseMetaData.getDatabaseVersionName returns a string that contains the
database product indicator and the version number, release number, and
maintenance level of the data source.
The following table shows examples of values that are returned by
DatabaseMetaData.getDatabaseProductVersion.
Table 8. Examples of DatabaseMetaData.getDatabaseProductVersion values
getDatabaseProductVersion value
Database product version
DSN09015
DB2 for z/OS Version 9.1 in new-function mode
SQL09010
DB2 Database for Linux, UNIX, and Windows Version 9.1
IFX11100
IBM Informix Version 11.10
Variables in JDBC applications
As in any other Java application, when you write JDBC applications, you declare
variables. In Java applications, those variables are known as Java identifiers.
Some of those identifiers have the same function as host variables in other
languages: they hold data that you pass to or retrieve from database tables.
Identifier empNo in the following code holds data that you retrieve from the
EMPNO table column, which has the CHAR data type.
String empNo;
// Execute a query and generate a ResultSet instance
rs = stmt.executeQuery("SELECT EMPNO FROM EMPLOYEE");
while (rs.next()) {
String empNo = rs.getString(1);
System.out.println("Employee number = " + empNo);
}
Your choice of Java data types can affect performance because DB2 picks better
access paths when the data types of your Java variables map closely to the DB2
data types.
Related concepts
“Example of a simple JDBC application” on page 9
Related reference
“Data types that map to database data types in Java applications” on page 211
JDBC interfaces for executing SQL
You execute SQL statements in a traditional SQL program to update data in tables,
retrieve data from the tables, or call stored procedures. To perform the same
functions in a JDBC program, you invoke methods.
Those methods are defined in the following interfaces:
v The Statement interface supports all SQL statement execution. The following
interfaces inherit methods from the Statement interface:
– The PreparedStatement interface supports any SQL statement containing
input parameter markers. Parameter markers represent input variables. The
PreparedStatement interface can also be used for SQL statements with no
parameter markers.
With the IBM Data Server Driver for JDBC and SQLJ, the PreparedStatement
interface can be used to call stored procedures that have input parameters
24
Application Programming Guide and Reference for Java
and no output parameters, and that return no result sets. However, the
preferred interface is CallableStatement.
– The CallableStatement interface supports the invocation of a stored
procedure.
The CallableStatement interface can be used to call stored procedures with
input parameters, output parameters, or input and output parameters, or no
parameters. With the IBM Data Server Driver for JDBC and SQLJ, you can
also use the Statement interface to call stored procedures, but those stored
procedures must have no parameters.
v The ResultSet interface provides access to the results that a query generates.
The ResultSet interface has the same purpose as the cursor that is used in SQL
applications in other languages.
Related tasks
“Retrieving data from tables using the PreparedStatement.executeQuery method”
on page 34
“Updating data in tables using the PreparedStatement.executeUpdate method” on
page 26
“Retrieving data from tables using the Statement.executeQuery method” on page
33
“Creating and modifying database objects using the Statement.executeUpdate
method”
Related reference
“Driver support for JDBC APIs” on page 283
Creating and modifying database objects using the
Statement.executeUpdate method
The Statement.executeUpdate is one of the JDBC methods that you can use to
update tables and call stored procedures.
You can use the Statement.executeUpdate method to do the following things:
v Execute data definition statements, such as CREATE, ALTER, DROP, GRANT,
REVOKE
v Execute INSERT, UPDATE, DELETE, and MERGE statements that do not contain
parameter markers.
v With the IBM Data Server Driver for JDBC and SQLJ, execute the CALL
statement to call stored procedures that have no parameters and that return no
result sets.
To
1.
2.
3.
execute these SQL statements, you need to perform these steps:
Invoke the Connection.createStatement method to create a Statement object.
Invoke the Statement.executeUpdate method to perform the SQL operation.
Invoke the Statement.close method to close the Statement object.
Suppose that you want to execute this SQL statement:
UPDATE EMPLOYEE SET PHONENO=’4657’ WHERE EMPNO=’000010’
The following code creates Statement object stmt, executes the UPDATE statement,
and returns the number of rows that were updated in numUpd. The numbers to the
right of selected statements correspond to the previously-described steps.
Chapter 3. JDBC application programming
25
Connection con;
Statement stmt;
int numUpd;
...
stmt = con.createStatement();
// Create a Statement object 1
numUpd = stmt.executeUpdate(
"UPDATE EMPLOYEE SET PHONENO=’4657’ WHERE EMPNO=’000010’");
2
// Perform the update
stmt.close();
// Close Statement object
3
Figure 8. Using Statement.executeUpdate
Related reference
“Driver support for JDBC APIs” on page 283
Updating data in tables using the
PreparedStatement.executeUpdate method
The Statement.executeUpdate method works if you update DB2 tables with
constant values. However, updates often need to involve passing values in
variables to DB2 tables. To do that, you use the PreparedStatement.executeUpdate
method.
With the IBM Data Server Driver for JDBC and SQLJ, you can also use
PreparedStatement.executeUpdate to call stored procedures that have input
parameters and no output parameters, and that return no result sets.
DB2 for z/OS does not support dynamic execution of the CALL statement. For
calls to stored procedures that are on DB2 for z/OS data sources, the parameters
can be parameter markers or literals, but not expressions. The following types of
literals are supported:
v Integer
v Double
v Decimal
v Character
v Hexadecimal
v Graphic
For calls to stored procedures that are on IBM Informix data sources, the
PreparedStatement object can be a CALL statement or an EXECUTE PROCEDURE
statement.
When you execute an SQL statement many times, you can get better performance
by creating the SQL statement as a PreparedStatement.
For example, the following UPDATE statement lets you update the employee table
for only one phone number and one employee number:
UPDATE EMPLOYEE SET PHONENO=’4657’ WHERE EMPNO=’000010’
Suppose that you want to generalize the operation to update the employee table
for any set of phone numbers and employee numbers. You need to replace the
constant phone number and employee number with variables:
UPDATE EMPLOYEE SET PHONENO=? WHERE EMPNO=?
Variables of this form are called parameter markers. To execute an SQL statement
with parameter markers, you need to perform these steps:
26
Application Programming Guide and Reference for Java
1. Invoke the Connection.prepareStatement method to create a PreparedStatement
object.
2. Invoke the PreparedStatement.setXXX methods to pass values to the input
variables.
This step assumes that you use standard parameter markers. Alternatively, if
you use named parameter markers, you useIBM Data Server Driver for JDBC
and SQLJ-only methods to pass values to the input parameters.
3. Invoke the PreparedStatement.executeUpdate method to update the table with
the variable values.
4. Invoke the PreparedStatement.close method to close the PreparedStatement
object when you have finished using that object.
The following code performs the previous steps to update the phone number to
'4657' for the employee with employee number '000010'. The numbers to the right
of selected statements correspond to the previously-described steps.
Connection con;
PreparedStatement pstmt;
int numUpd;
...
pstmt = con.prepareStatement(
"UPDATE EMPLOYEE SET PHONENO=? WHERE EMPNO=?");
// Create a PreparedStatement object
pstmt.setString(1,"4657");
// Assign first value to first parameter
pstmt.setString(2,"000010");
// Assign first value to second parameter
numUpd = pstmt.executeUpdate();
// Perform first update
pstmt.setString(1,"4658");
// Assign second value to first parameter
pstmt.setString(2,"000020");
// Assign second value to second parameter
numUpd = pstmt.executeUpdate();
// Perform second update
pstmt.close();
// Close the PreparedStatement object
1
2
3
4
Figure 9. Using PreparedStatement.executeUpdate for an SQL statement with parameter
markers
You can also use the PreparedStatement.executeUpdate method for statements that
have no parameter markers. The steps for executing a PreparedStatement object
with no parameter markers are similar to executing a PreparedStatement object
with parameter markers, except you skip step 2. The following example
demonstrates these steps.
Connection con;
PreparedStatement pstmt;
int numUpd;
...
pstmt = con.prepareStatement(
"UPDATE EMPLOYEE SET PHONENO=’4657’ WHERE EMPNO=’000010’");
// Create a PreparedStatement object 1
numUpd = pstmt.executeUpdate();
// Perform the update
3
pstmt.close();
// Close the PreparedStatement object 4
Figure 10. Using PreparedStatement.executeUpdate for an SQL statement without parameter
markers
Chapter 3. JDBC application programming
27
Related tasks
“Using named parameter markers with PreparedStatement objects” on page 73
Related reference
“Driver support for JDBC APIs” on page 283
JDBC executeUpdate methods against a DB2 for z/OS server
The JDBC standard states that the executeUpdate method returns a row count or 0.
However, if the executeUpdate method is executed against a DB2 for z/OS server,
it can return a value of -1.
For executeUpdate statements against a DB2 for z/OS server, the value that is
returned depends on the type of SQL statement that is being executed:
v For an SQL statement that can have an update count, such as an INSERT,
UPDATE, DELETE, or MERGE statement, the returned value is the number of
affected rows. It can be:
– A positive number, if a positive number of rows are affected by the operation,
and the operation is not a mass delete on a segmented table space.
– 0, if no rows are affected by the operation.
– -1, if the operation is a mass delete on a segmented table space.
v For an SQL CALL statement, a value of -1 is returned, because the data source
cannot determine the number of affected rows. Calls to getUpdateCount or
getMoreResults for a CALL statement also return -1.
v For any other SQL statement, a value of -1 is returned.
Related tasks
“Creating and modifying database objects using the Statement.executeUpdate
method” on page 25
“Updating data in tables using the PreparedStatement.executeUpdate method” on
page 26
Making batch updates in JDBC applications
With batch updates, instead of updating rows of a table one at a time, you can
direct JDBC to execute a group of updates at the same time. Statements that can be
included in the same batch of updates are known as batchable statements.
If a statement has input parameters or host expressions, you can include that
statement only in a batch that has other instances of the same statement. This type
of batch is known as a homogeneous batch. If a statement has no input parameters,
you can include that statement in a batch only if the other statements in the batch
have no input parameters or host expressions. This type of batch is known as a
heterogeneous batch. Two statements that can be included in the same batch are
known as batch compatible.
Use the following Statement methods for creating, executing, and removing a
batch of SQL updates:
v addBatch
v executeBatch
v clearBatch
Use the following PreparedStatement and CallableStatement method for creating a
batch of parameters so that a single statement can be executed multiple times in a
batch, with a different set of parameters for each execution.
v addBatch
28
Application Programming Guide and Reference for Java
Restrictions on executing statements in a batch:
v If you try to execute a SELECT statement in a batch, a BatchUpdateException is
thrown.
v A CallableStatement object that you execute in a batch can contain output
parameters. However, you cannot retrieve the values of the output parameters. If
you try to do so, a BatchUpdateException is thrown.
v You cannot retrieve ResultSet objects from a CallableStatement object that you
execute in a batch. A BatchUpdateException is not thrown, but the getResultSet
method invocation returns a null value.
To make batch updates using several statements with no input parameters, follow
these basic steps:
1. For each SQL statement that you want to execute in the batch, invoke the
addBatch method.
2. Invoke the executeBatch method to execute the batch of statements.
3. Check for errors. If no errors occurred:
a. Get the number of rows that were affect by each SQL statement from the
array that the executeBatch invocation returns. This number does not
include rows that were affected by triggers or by referential integrity
enforcement.
b. If AutoCommit is disabled for the Connection object, invoke the commit
method to commit the changes.
If AutoCommit is enabled for the Connection object, the IBM Data Server
Driver for JDBC and SQLJ adds a commit method at the end of the batch.
To make batch updates using a single statement with several sets of input
parameters, follow these basic steps:
1. If the batched statement is a searched UDPATE, searched DELETE, or MERGE
statement, set the autocommit mode for the connection to false.
2. Invoke the prepareStatement method to create a PreparedStatement object.
3. For each set of input parameter values:
a. Execute setXXX methods to assign values to the input parameters.
b. Invoke the addBatch method to add the set of input parameters to the batch.
4. Invoke the executeBatch method to execute the statements with all sets of
parameters.
5. If no errors occurred:
a. Get the number of rows that were updated by each execution of the SQL
statement from the array that the executeBatch invocation returns. The
number of affected rows does not include rows that were affected by
triggers or by referential integrity enforcement.
If the following conditions are true, the IBM Data Server Driver for JDBC
and SQLJ returns Statement.SUCCESS_NO_INFO (-2), instead of the number of
rows that were affected by each SQL statement:
v The application is connected to a subsystem that is in DB2 for z/OS
Version 8 new-function mode, or later.
v The application is using Version 3.1 or later of the IBM Data Server
Driver for JDBC and SQLJ.
v The IBM Data Server Driver for JDBC and SQLJ uses multi-row INSERT
operations to execute batch updates.
This occurs because with multi-row INSERT, the database server executes
the entire batch as a single operation, so it does not return results for
individual SQL statements.
Chapter 3. JDBC application programming
29
b. If AutoCommit is disabled for the Connection object, invoke the commit
method to commit the changes.
If AutoCommit is enabled for the Connection object, the IBM Data Server
Driver for JDBC and SQLJ adds a commit method at the end of the batch.
c. If the PreparedStatement object returns automatically generated keys, call
DB2PreparedStatement.getDBGeneratedKeys to retrieve an array of ResultSet
objects that contains the automatically generated keys.
Check the length of the returned array. If the length of the returned array is
0, an error occurred during retrieval of the automatically generated keys.
6. If errors occurred, process the BatchUpdateException.
In the following code fragment, two sets of parameters are batched. An UPDATE
statement that takes two input parameters is then executed twice, once with each
set of parameters. The numbers to the right of selected statements correspond to
the previously-described steps.
try {
...
PreparedStatement preps = conn.prepareStatement(
"UPDATE DEPT SET MGRNO=? WHERE DEPTNO=?");
ps.setString(1,mgrnum1);
ps.setString(2,deptnum1);
ps.addBatch();
2
3a
3b
ps.setString(1,mgrnum2);
ps.setString(2,deptnum2);
ps.addBatch();
int [] numUpdates=ps.executeBatch();
4
for (int i=0; i < numUpdates.length; i++) {
5a
if (numUpdates[i] == SUCCESS_NO_INFO)
System.out.println("Execution " + i +
": unknown number of rows updated");
else
System.out.println("Execution " + i +
"successful: " numUpdates[i] + " rows updated");
}
conn.commit();
5b
} catch(BatchUpdateException b) {
6
// process BatchUpdateException
}
In the following code fragment, a batched INSERT statement returns automatically
generated keys.
import java.sql.*;
import com.ibm.db2.jcc.*;
...
Connection conn;
...
try {
...
PreparedStatement ps = conn.prepareStatement(
"INSERT INTO DEPT (DEPTNO, DEPTNAME, ADMRDEPT) " +
"VALUES (?,?,?)",
Statement.RETURN_GENERATED_KEYS);
ps.setString(1,"X01");
ps.setString(2,"Finance");
ps.setString(3,"A00");
ps.addBatch();
ps.setString(1,"Y01");
ps.setString(2,"Accounting");
ps.setString(3,"A00");
ps.addBatch();
30
Application Programming Guide and Reference for Java
2
3a
3b
4
int [] numUpdates=preps.executeBatch();
for (int i=0; i < numUpdates.length; i++) {
5a
if (numUpdates[i] == SUCCESS_NO_INFO)
System.out.println("Execution " + i +
": unknown number of rows updated");
else
System.out.println("Execution " + i +
"successful: " numUpdates[i] + " rows updated");
}
conn.commit();
5b
ResultSet[] resultList =
((DB2PreparedStatement)ps).getDBGeneratedKeys();
5c
if (resultList.length != 0) {
for (i = 0; i < resultList.length; i++) {
while (resultList[i].next()) {
java.math.BigDecimal idColVar = rs.getBigDecimal(1);
// Get automatically generated key
// value
System.out.println("Automatically generated key value = "
+ idColVar);
}
}
}
else {
System.out.println("Error retrieving automatically generated keys");
}
} catch(BatchUpdateException b) {
6
// process BatchUpdateException
}
In the following code fragment, a batched UPDATE statement returns
automatically generated keys. The code names the DEPTNO column as an
automatically generated key, updates two rows in the DEPT table in a batch, and
retrieves the values of DEPTNO for the updated rows. The numbers to the right of
selected statements correspond to the previously described steps.
import java.sql.*;
import com.ibm.db2.jcc.*;
...
Connection conn;
...
String[] agkNames = {"DEPTNO"};
try {
...
conn.setAutoCommit(false);
PreparedStatement ps = conn.prepareStatement(
"UPDATE DEPT SET DEPTNAME=? " +
"WHERE DEPTNO=?",agkNames);
ps.setString(1,"X01");
ps.setString(2,"Planning");
ps.addBatch();
ps.setString(1,"Y01");
ps.setString(2,"Bookkeeping");
ps.addBatch();
int [] numUpdates=ps.executeBatch();
1
2
3a
3b
4
for (int i=0; i < numUpdates.length; i++) {
5a
if (numUpdates[i] == SUCCESS_NO_INFO)
System.out.println("Execution " + i +
": unknown number of rows updated");
else
System.out.println("Execution " + i +
"successful: " numUpdates[i] + " rows updated");
}
conn.commit();
5b
Chapter 3. JDBC application programming
31
ResultSet[] resultList =
((DB2PreparedStatement)ps).getDBGeneratedKeys();
5c
if (resultList.length != 0) {
for (i = 0; i < resultList.length; i++) {
while (resultList[i].next()) {
String deptNoKey = rs.getString(1);
// Get automatically generated key
// value
System.out.println("Automatically generated key value = "
+ deptNoKey);
}
}
}
else {
System.out.println("Error retrieving automatically generated keys");
}
}
catch(BatchUpdateException b) {
// process BatchUpdateException
}
6
Related tasks
“Retrieving information from a BatchUpdateException” on page 107
“Making batch updates in SQLJ applications” on page 132
“Making batch queries in JDBC applications” on page 35
“Committing or rolling back JDBC transactions” on page 99
Learning about parameters in a PreparedStatement using
ParameterMetaData methods
The IBM Data Server Driver for JDBC and SQLJ includes support for the
ParameterMetaData interface. The ParameterMetaData interface contains methods
that retrieve information about the parameter markers in a PreparedStatement
object.
ParameterMetaData methods provide the following types of information:
v The data types of parameters, including the precision and scale of decimal
parameters.
v The parameters' database-specific type names. For parameters that correspond to
table columns that are defined with distinct types, these names are the distinct
type names.
v Whether parameters are nullable.
v Whether parameters are input or output parameters.
v Whether the values of a numeric parameter can be signed.
v The fully-qualified Java class name that PreparedStatement.setObject uses
when it sets a parameter value.
To invoke ParameterMetaData methods, you need to perform these basic steps:
1. Invoke the Connection.prepareStatement method to create a PreparedStatement
object.
2. Invoke the PreparedStatement.getParameterMetaData method to retrieve a
ParameterMetaData object.
3. Invoke ParameterMetaData.getParameterCount to determine the number of
parameters in the PreparedStatement.
4. Invoke ParameterMetaData methods on individual parameters.
The following code demonstrates how to use ParameterMetaData methods to
determine the number and data types of parameters in an SQL UPDATE statement.
32
Application Programming Guide and Reference for Java
The numbers to the right of selected statements correspond to the
previously-described steps.
Connection con;
ParameterMetaData pmtadta;
int mtadtacnt;
String sqlType;
...
pstmt = con.prepareStatement(
"UPDATE EMPLOYEE SET PHONENO=? WHERE EMPNO=?");
// Create a PreparedStatement object
pmtadta = pstmt.getParameterMetaData();
// Create a ParameterMetaData object
mtadtacnt = pmtadta.getParameterCount();
// Determine the number of parameters
System.out.println("Number of statement parameters: " + mtadtacnt);
for (int i = 1; i <= mtadtacnt; i++) {
sqlType = pmtadta.getParameterTypeName(i);
// Get SQL type for each parameter
System.out.println("SQL type of parameter " + i " is " + sqlType);
}
...
pstmt.close();
// Close the PreparedStatement
1
2
3
4
Figure 11. Using ParameterMetaData methods to get information about a PreparedStatement
Related reference
“Driver support for JDBC APIs” on page 283
Data retrieval in JDBC applications
In JDBC applications, you retrieve data using ResultSet objects. A ResultSet
represents the result set of a query.
Retrieving data from tables using the Statement.executeQuery
method
To retrieve data from a table using a SELECT statement with no parameter
markers, you can use the Statement.executeQuery method.
This method returns a result table in a ResultSet object. After you obtain the result
table, you need to use ResultSet methods to move through the result table and
obtain the individual column values from each row.
With the IBM Data Server Driver for JDBC and SQLJ, you can also use the
Statement.executeQuery method to retrieve a result set from a stored procedure
call, if that stored procedure returns only one result set. If the stored procedure
returns multiple result sets, you need to use the Statement.execute method.
This topic discusses the simplest kind of ResultSet, which is a read-only ResultSet
in which you can only move forward, one row at a time. The IBM Data Server
Driver for JDBC and SQLJ also supports updatable and scrollable ResultSets.
To retrieve rows from a table using a SELECT statement with no parameter
markers, you need to perform these steps:
1. Invoke the Connection.createStatement method to create a Statement object.
2. Invoke the Statement.executeQuery method to obtain the result table from the
SELECT statement in a ResultSet object.
Chapter 3. JDBC application programming
33
3. In a loop, position the cursor using the next method, and retrieve data from
each column of the current row of the ResultSet object using getXXX methods.
XXX represents a data type.
4. Invoke the ResultSet.close method to close the ResultSet object.
5. Invoke the Statement.close method to close the Statement object when you
have finished using that object.
The following code demonstrates how to retrieve all rows from the employee table.
The numbers to the right of selected statements correspond to the
previously-described steps.
String empNo;
Connection con;
Statement stmt;
ResultSet rs;
...
stmt = con.createStatement();
//
rs = stmt.executeQuery("SELECT EMPNO
//
while (rs.next()) {
//
empNo = rs.getString(1);
System.out.println("Employee number
//
}
rs.close();
//
stmt.close();
//
Create a Statement object
1
FROM EMPLOYEE");
2
Get the result table from the query
Position the cursor
3
// Retrieve only the first column value
= " + empNo);
Print the column value
Close the ResultSet
Close the Statement
4
5
Figure 12. Using Statement.executeQuery
Related reference
“Driver support for JDBC APIs” on page 283
Retrieving data from tables using the
PreparedStatement.executeQuery method
To retrieve data from a table using a SELECT statement with parameter markers,
you use the PreparedStatement.executeQuery method.
This method returns a result table in a ResultSet object. After you obtain the result
table, you need to use ResultSet methods to move through the result table and
obtain the individual column values from each row.
With the IBM Data Server Driver for JDBC and SQLJ, you can also use the
PreparedStatement.executeQuery method to retrieve a result set from a stored
procedure call, if that stored procedure returns only one result set and has only
input parameters. If the stored procedure returns multiple result sets, you need to
use the PreparedStatement.execute method.
You can also use the PreparedStatement.executeQuery method for statements that
have no parameter markers. When you execute a query many times, you can get
better performance by creating the SQL statement as a PreparedStatement.
To retrieve rows from a table using a SELECT statement with parameter markers,
you need to perform these steps:
1. Invoke the Connection.prepareStatement method to create a PreparedStatement
object.
2. Invoke PreparedStatement.setXXX methods to pass values to the input
parameters.
34
Application Programming Guide and Reference for Java
3. Invoke the PreparedStatement.executeQuery method to obtain the result table
from the SELECT statement in a ResultSet object.
4. In a loop, position the cursor using the ResultSet.next method, and retrieve
data from each column of the current row of the ResultSet object using getXXX
methods.
5. Invoke the ResultSet.close method to close the ResultSet object.
6. Invoke the PreparedStatement.close method to close the PreparedStatement
object when you have finished using that object.
The following code demonstrates how to retrieve rows from the employee table for
a specific employee. The numbers to the right of selected statements correspond to
the previously-described steps.
String empnum, phonenum;
Connection con;
PreparedStatement pstmt;
ResultSet rs;
...
pstmt = con.prepareStatement(
"SELECT EMPNO, PHONENO FROM EMPLOYEE WHERE EMPNO=?");
// Create a PreparedStatement object
pstmt.setString(1,"000010");
// Assign value to input parameter
rs = pstmt.executeQuery();
//
while (rs.next()) {
//
empnum = rs.getString(1);
//
phonenum = rs.getString(2);
//
System.out.println("Employee number
"Phone number = " + phonenum);
//
}
rs.close();
//
pstmt.close();
//
1
2
Get the result table from the query 3
Position the cursor
4
Retrieve the first column value
Retrieve the first column value
= " + empnum +
Print the column values
Close the ResultSet
Close the PreparedStatement
5
6
Figure 13. Example of using PreparedStatement.executeQuery
Related reference
“Driver support for JDBC APIs” on page 283
Making batch queries in JDBC applications
The IBM Data Server Driver for JDBC and SQLJ provides a IBM Data Server
Driver for JDBC and SQLJ-only DB2PreparedStatement interface that lets you
perform batch queries on a homogeneous batch.
To make batch queries using a single statement with several sets of input
parameters, follow these basic steps:
1. Invoke the prepareStatement method to create a PreparedStatement object for
the SQL statement with input parameters.
2. For each set of input parameter values:
a. Execute PreparedStatement.setXXX methods to assign values to the input
parameters.
b. Invoke the PreparedStatement.addBatch method to add the set of input
parameters to the batch.
3. Cast the PreparedStatement object to a DB2PreparedStatement object, and
invoke the DB2PreparedStatement.executeDB2QueryBatch method to execute the
statement with all sets of parameters.
4. In a loop, retrieve the ResultSet objects:
Chapter 3. JDBC application programming
35
a. Retrieve each ResultSet object.
b. Retrieve all the rows from each ResultSet object.
Example: In the following code fragment, two sets of parameters are batched. A
SELECT statement that takes one input parameter is then executed twice, once
with each parameter value. The numbers to the right of selected statements
correspond to the previously described steps.
java.sql.Connection con = java.sql.DriverManager.getConnection(url, properties);
java.sql.Statement s = con.createStatement();
// Clean up from previous executions
try {
s.executeUpdate ("drop table TestQBatch");
}
catch (Exception e) {
}
// Create and populate a
s.executeUpdate ("create
s.executeUpdate ("insert
s.executeUpdate ("insert
s.executeUpdate ("insert
s.executeUpdate ("insert
s.executeUpdate ("insert
s.executeUpdate ("insert
test table
table TestQBatch (col1
into TestQBatch values
into TestQBatch values
into TestQBatch values
into TestQBatch values
into TestQBatch values
into TestQBatch values
int, col2 char(10))");
(1, ’test1’)");
(2, ’test2’)");
(3, ’test3’)");
(4, ’test4’)");
(1, ’test5’)");
(2, ’test6’)");
try {
PreparedStatement pstmt =
1
con.prepareStatement("Select * from TestQBatch where col1 = ?");
pstmt.setInt(1,1);
2a
pstmt.addBatch();
2b
// Add some more values to the batch
pstmt.setInt(1,2);
pstmt.addBatch();
pstmt.setInt(1,3);
pstmt.addBatch();
pstmt.setInt(1,4);
pstmt.addBatch();
((com.ibm.db2.jcc.DB2PreparedStatement)pstmt).executeDB2QueryBatch();
3
} catch(BatchUpdateException b) {
// process BatchUpdateException
}
ResultSet rs;
while(pstmt.getMoreResults()) {
4
rs = pstmt.getResultSet();
4a
while (rs.next()) {
4b
System.out.print (rs.getInt (1) + " ");
System.out.println (rs.getString (2));
}
System.out.println();
rs.close ();
}
// Clean up
s.close ();
pstmt.close ();
con.close ();
Related tasks
“Making batch updates in JDBC applications” on page 28
Learning about a ResultSet using ResultSetMetaData methods
You cannot always know the number of columns and data types of the columns in
a table or result set. This is true especially when you are retrieving data from a
remote data source.
36
Application Programming Guide and Reference for Java
When you write programs that retrieve unknown ResultSets, you need to use
ResultSetMetaData methods to determine the characteristics of the ResultSets
before you can retrieve data from them.
ResultSetMetaData methods provide the following types of information:
v The number of columns in a ResultSet
v The qualifier for the underlying table of the ResultSet
v Information about a column, such as the data type, length, precision, scale, and
nullability
v Whether a column is read-only
After you invoke the executeQuery method to generate a ResultSet for a query on
a table, follow these basic steps to determine the contents of the ResultSet:
1. Invoke the getMetaData method on the ResultSet object to create a
ResultSetMetaData object.
2. Invoke the getColumnCount method to determine how many columns are in the
ResultSet.
3. For each column in the ResultSet, execute ResultSetMetaData methods to
determine column characteristics.
The results of ResultSetMetaData.getColumnName call reflects the column name
information that is stored in the DB2 catalog for that data source.
The following code demonstrates how to determine the data types of all the
columns in the employee table. The numbers to the right of selected statements
correspond to the previously-described steps.
String s;
Connection con;
Statement stmt;
ResultSet rs;
ResultSetMetaData rsmtadta;
int colCount
int mtadtaint;
int i;
String colName;
String colType;
...
stmt = con.createStatement();
// Create a Statement object
rs = stmt.executeQuery("SELECT * FROM EMPLOYEE");
// Get the ResultSet from the query
rsmtadta = rs.getMetaData();
// Create a ResultSetMetaData object 1
colCount = rsmtadta.getColumnCount();
2
// Find number of columns in EMP
for (i=1; i<= colCount; i++) {
3
colName = rsmtadta.getColumnName();
// Get column name
colType = rsmtadta.getColumnTypeName();
// Get column data type
System.out.println("Column = " + colName +
" is data type " + colType);
// Print the column value
}
Figure 14. Using ResultSetMetaData methods to get information about a ResultSet
Chapter 3. JDBC application programming
37
Related tasks
“Retrieving multiple result sets from a stored procedure in a JDBC application” on
page 48
“Calling stored procedures in JDBC applications” on page 46
“Retrieving data from tables using the Statement.executeQuery method” on page
33
Characteristics of a JDBC ResultSet under the IBM Data Server
Driver for JDBC and SQLJ
The IBM Data Server Driver for JDBC and SQLJ provides support for scrollable,
updatable, and holdable cursors.
In addition to moving forward, one row at a time, through a ResultSet, you might
want to do the following things:
v Move backward or go directly to a specific row
v Update, delete, or insert rows in a ResultSet
v Leave the ResultSet open after a COMMIT
The following terms describe characteristics of a ResultSet:
scrollability
Whether the cursor for the ResultSet can move forward only, or forward one
or more rows, backward one or more rows, or to a specific row.
If a cursor for a ResultSet is scrollable, it also has a sensitivity attribute, which
describes whether the cursor is sensitive to changes to the underlying table.
updatability
Whether the cursor can be used to update or delete rows. This characteristic
does not apply to a ResultSet that is returned from a stored procedure,
because a stored procedure ResultSet cannot be updated.
holdability
Whether the cursor stays open after a COMMIT.
You set the updatability, scrollability, and holdability characteristics of a ResultSet
through parameters in the Connection.prepareStatement or
Connection.createStatement methods. The ResultSet settings map to attributes of
a cursor in the database. The following table lists the JDBC scrollability,
updatability, and holdability settings, and the corresponding cursor attributes.
Table 9. JDBC ResultSet characteristics and SQL cursor attributes
JDBC setting
DB2 cursor setting
IBM Informix cursor setting
CONCUR_READ_ONLY
FOR READ ONLY
FOR READ ONLY
CONCUR_UPDATABLE
FOR UPDATE
FOR UPDATE
HOLD_CURSORS_OVER_COMMIT
WITH HOLD
WITH HOLD
TYPE_FORWARD_ONLY
SCROLL not specified
SCROLL not specified
TYPE_SCROLL_INSENSITIVE
INSENSITIVE SCROLL
SCROLL
TYPE_SCROLL_SENSITIVE
SENSITIVE STATIC, SENSITIVE
DYNAMIC, or ASENSITIVE,
depending on the cursorSensitvity
Connection and DataSource property
Not supported
38
Application Programming Guide and Reference for Java
Important: Like static scrollable cursors in any other language, JDBC static
scrollable ResultSet objects use declared temporary tables for their internal
processing. This means that before you can execute any applications that contain
JDBC static scrollable ResultSet objects, your database administrator needs to
create a temporary database and temporary table spaces for those declared
temporary tables.
If a JDBC ResultSet is static, the size of the result table and the order of the rows
in the result table do not change after the cursor is opened. This means that if you
insert rows into the underlying table, the result table for a static ResultSet does
not change. If you delete a row of a result table, a delete hole occurs. You cannot
update or delete a delete hole.
Related concepts
Temporary table space storage requirements (DB2 Installation Guide)
Specifying updatability, scrollability, and holdability for ResultSets in JDBC
applications:
You use special parameters in the Connection.prepareStatement or
Connection.createStatement methods to specify the updatability, scrollability, and
holdability of a ResultSet.
By default, ResultSet objects are not scrollable and not updatable. The default
holdability depends on the data source, and can be determined from the
DatabaseMetaData.getResultSetHoldability method. To change the scrollability,
updatability, and holdability attributes for a ResultSet, follow these steps:
1. If the SELECT statement that defines the ResultSet has no input parameters,
invoke the createStatement method to create a Statement object. Otherwise,
invoke the prepareStatement method to create a PreparedStatement object. You
need to specify forms of the createStatement or prepareStatement methods
that include the resultSetType, resultSetConcurrency, or resultSetHoldability
parameters.
The form of the createStatement method that supports scrollability and
updatability is:
createStatement(int resultSetType, int resultSetConcurrency);
The form of the createStatement method that supports scrollability,
updatability, and holdability is:
createStatement(int resultSetType, int resultSetConcurrency,
int resultSetHoldability);
The form of the prepareStatement method that supports scrollability and
updatability is:
prepareStatement(String sql, int resultSetType,
int resultSetConcurrency);
The form of the prepareStatement method that supports scrollability,
updatability, and holdability is:
prepareStatement(String sql, int resultSetType,
int resultSetConcurrency, int resultSetHoldability);
The following table contains a list of valid values for resultSetType and
resultSetConcurrency.
Chapter 3. JDBC application programming
39
Table 10. Valid combinations of resultSetType and resultSetConcurrency for ResultSets
resultSetType value
resultSetConcurrency value
TYPE_FORWARD_ONLY
CONCUR_READ_ONLY
TYPE_FORWARD_ONLY
CONCUR_UPDATABLE
TYPE_SCROLL_INSENSITIVE
CONCUR_READ_ONLY
TYPE_SCROLL_SENSITIVE
1
CONCUR_READ_ONLY
TYPE_SCROLL_SENSITIVE
1
CONCUR_UPDATABLE
Note:
1. This value does not apply to connections to IBM Informix.
resultSetHoldability has two possible values: HOLD_CURSORS_OVER_COMMIT and
CLOSE_CURSORS_AT_COMMIT. Either of these values can be specified with any
valid combination of resultSetConcurrency and resultSetHoldability. The value that
you set overrides the default holdability for the connection.
Restriction: If the ResultSet is scrollable, and the ResultSet is used to select
columns from a table on a DB2 Database for Linux, UNIX, and Windows
server, the SELECT list of the SELECT statement that defines the ResultSet
cannot include columns with the following data types:
v LONG VARCHAR
v LONG VARGRAPHIC
v BLOB
v CLOB
v XML
v A distinct type that is based on any of the previous data types in this list
v A structured type
2. If the SELECT statement has input parameters, invoke setXXX methods to pass
values to the input parameters.
3. Invoke the executeQuery method to obtain the result table from the SELECT
statement in a ResultSet object.
4. For each row that you want to access:
a. Position the cursor using one of the methods that are listed in the following
table.
Table 11. ResultSet methods for positioning a scrollable cursor
Method
first
last
1
next
2
Positions the cursor
1
previous
On the first row of the ResultSet
On the last row of the ResultSet
On the next row of the ResultSet
1,3
On the previous row of the ResultSet
absolute(int n)
If n>0, on row n of the ResultSet. If n<0, and m is the
number of rows in the ResultSet, on row m+n+1 of
the ResultSet.
relative(int n)1,5,6,
If n>0, on the row that is n rows after the current row.
If n<0, on the row that is n rows before the current
row. If n=0, on the current row.
afterLast1
After the last row in the ResultSet
beforeFirst
40
1,4
1
Application Programming Guide and Reference for Java
Before the first row in the ResultSet
Table 11. ResultSet methods for positioning a scrollable cursor (continued)
Method
Positions the cursor
Notes:
1. This method does not apply to connections to IBM Informix.
2. If the cursor is before the first row of the ResultSet, this method positions the cursor on
the first row.
3. If the cursor is after the last row of the ResultSet, this method positions the cursor on
the last row.
4. If the absolute value of n is greater than the number of rows in the result set, this
method positions the cursor after the last row if n is positive, or before the first row if n
is negative.
5. The cursor must be on a valid row of the ResultSet before you can use this method. If
the cursor is before the first row or after the last row, the method throws an
SQLException.
6. Suppose that m is the number of rows in the ResultSet and x is the current row number
in the ResultSet. If n>0 and x+n>m, the driver positions the cursor after the last row. If
n<0 and x+n<1, the driver positions the cursor before the first row.
b. If you need to know the current cursor position, use the getRow, isFirst,
isLast, isBeforeFirst, or isAfterLast method to obtain this information.
c. If you specified a resultSetType value of TYPE_SCROLL_SENSITIVE in step 1 on
page 39, and you need to see the latest values of the current row, invoke the
refreshRow method.
Recommendation: Because refreshing the rows of a ResultSet can have a
detrimental effect on the performance of your applications, you should
invoke refreshRow only when you need to see the latest data.
d. Perform one or more of the following operations:
v To retrieve data from each column of the current row of the ResultSet
object, use getXXX methods.
v To update the current row from the underlying table, use updateXXX
methods to assign column values to the current row of the ResultSet.
Then use updateRow to update the corresponding row of the underlying
table. If you decide that you do not want to update the underlying table,
invoke the cancelRowUpdates method instead of the updateRow method.
The resultSetConcurrency value for the ResultSet must be
CONCUR_UPDATABLE for you to use these methods.
v To delete the current row from the underlying table, use the deleteRow
method. Invoking deleteRow causes the driver to replace the current row
of the ResultSet with a hole.
The resultSetConcurrency value for the ResultSet must be
CONCUR_UPDATABLE for you to use this method.
5. Invoke the close method to close the ResultSet object.
6. Invoke the close method to close the Statement or PreparedStatement object.
The following code demonstrates how to retrieve all rows from the employee table
in reverse order, and update the phone number for employee number "000010".
The numbers to the right of selected statements correspond to the
previously-described steps.
Chapter 3. JDBC application programming
41
String s;
String stmtsrc;
Connection con;
Statement stmt;
ResultSet rs;
...
stmt = con.createStatement(ResultSet.TYPE_SCROLL_SENSITIVE,
ResultSet.CONCUR_UPDATABLE);
1
// Create a Statement object
// for a scrollable, updatable
// ResultSet
stmtsrc = "SELECT EMPNO, PHONENO FROM EMPLOYEE " +
"FOR UPDATE OF PHONENO";
rs = stmt.executeQuery(stmtsrc);
// Create the ResultSet
3
rs.afterLast();
// Position the cursor at the end of
// the ResultSet
4a
while (rs.previous()) {
// Position the cursor backward
s = rs.getString("EMPNO");
// Retrieve the employee number 4d
// (column 1 in the result
// table)
System.out.println("Employee number = " + s);
// Print the column value
if (s.compareTo("000010") == 0) {
// Look for employee 000010
rs.updateString("PHONENO","4657");
// Update their phone number
rs.updateRow();
// Update the row
}
}
rs.close();
// Close the ResultSet
5
stmt.close();
// Close the Statement
6
Figure 15. Using a scrollable cursor
Related tasks
“Retrieving data from tables using the Statement.executeQuery method” on page
33
Multi-row SQL operations in JDBC applications:
The IBM Data Server Driver for JDBC and SQLJ supports multi-row INSERT,
UPDATE, and FETCH for connections to data sources that support these
operations.
Multi-row INSERT
In JDBC applications, when you execute INSERT or MERGE statements that use
parameter markers in a batch, if the data server supports multi-row INSERT, the
IBM Data Server Driver for JDBC and SQLJ can transform the batch INSERT or
MERGE operations into multi-row INSERT statements. Multi-row INSERT
operations can provide better performance in the following ways:
v For local applications, multi-row INSERTs result in fewer accesses of the data
server.
v For distributed applications, multi-row INSERTs result in fewer network
operations.
You cannot execute a multi-row INSERT operation by including a multi-row
INSERT statement in a statement string in your JDBC application.
Multi-row INSERT is used by default. You can use the Connection or DataSource
property enableMultiRowInsertSupport to control whether multi-row INSERT is
used. Multi-row INSERT cannot be used for INSERT FROM SELECT statements
that are executed in a batch.
42
Application Programming Guide and Reference for Java
Multi-row FETCH
Multi-row FETCH can provide better performance than retrieving one row with
each FETCH statement. For IBM Data Server Driver for JDBC and SQLJ type 2
connectivity on DB2 for z/OS, multi-row FETCH can be used for forward-only
cursors and scrollable cursors. For IBM Data Server Driver for JDBC and SQLJ type
4 connectivity, multi-row FETCH can be used only for scrollable cursors.
When you retrieve data in your applications, the IBM Data Server Driver for JDBC
and SQLJ determines whether to use multi-row FETCH, depending on several
factors:
v The settings of the enableRowsetSupport and useRowsetCursor properties
v The type of IBM Data Server Driver for JDBC and SQLJ connectivity that is
being used
v The version of the IBM Data Server Driver for JDBC and SQLJ
For IBM Data Server Driver for JDBC and SQLJ type 4 connectivity to DB2 for
z/OS, one of the following sets of conditions must be true for multi-row FETCH to
be used.
v First set of conditions:
– The IBM Data Server Driver for JDBC and SQLJ version is 3.51 or later.
– The enableRowsetSupport property value is
com.ibm.db2.jcc.DB2BaseDataSource.YES (1), or the enableRowsetSupport
property value is com.ibm.db2.jcc.DB2BaseDataSource.NOT_SET (0) and the
useRowsetCursor property value is com.ibm.db2.jcc.DB2BaseDataSource.YES
(1).
– The FETCH operation uses a scrollable cursor.
For forward-only cursors, fetching of multiple rows might occur through
DRDA block FETCH. However, this behavior does not utilize the data
source's multi-row FETCH capability.
v Second set of conditions:
– The IBM Data Server Driver for JDBC and SQLJ version is 3.1.
– The useRowsetCursor property value is
com.ibm.db2.jcc.DB2BaseDataSource.YES (1).
– The FETCH operation uses a scrollable cursor.
For forward-only cursors, fetching of multiple rows might occur through
DRDA block FETCH. However, this behavior does not utilize the data
source's multi-row FETCH capability.
For IBM Data Server Driver for JDBC and SQLJ type 2 connectivity to DB2 for
z/OS the following conditions must be true for multi-row FETCH to be used.
v The IBM Data Server Driver for JDBC and SQLJ version is 3.51 or later.
v The enableRowsetSupport property value is
com.ibm.db2.jcc.DB2BaseDataSource.YES (1).
v The FETCH operation uses a scrollable cursor or a forward-only cursor.
For IBM Data Server Driver for JDBC and SQLJ type 2 connectivity on DB2 for
z/OS, you can control the maximum size of a rowset for each statement by setting
the maxRowsetSize property.
Chapter 3. JDBC application programming
43
Multi-row positioned UPDATE or DELETE
The IBM Data Server Driver for JDBC and SQLJ supports a technique for
performing positioned update or delete operations that follows the JDBC 1
standard. That technique involves using the ResultSet.getCursorName method to
obtain the name of the cursor for the ResultSet, and defining a positioned
UPDATE or positioned DELETE statement of the following form:
UPDATE table SET col1=value1,...coln=valueN WHERE CURRENT OF cursorname
DELETE FROM table WHERE CURRENT OF cursorname
Multi-row UPDATE or DELETE when useRowsetCursor is set to true: If you use the
JDBC 1 technique to update or delete data on a database server that supports
multi-row FETCH, and multi-row FETCH is enabled through the useRowsetCursor
property, the positioned UPDATE or DELETE statement might update or delete
multiple rows, when you expect it to update or delete a single row. To avoid
unexpected updates or deletes, you can take one of the following actions:
v Use an updatable ResultSet to retrieve and update one row at a time, as shown
in the previous example.
v Set useRowsetCursor to false.
Multi-row UPDATE or DELETE when enableRowsetSupport is set to
com.ibm.db2.jcc.DB2BaseDataSource.YES (1): The JDBC 1 technique for updating or
deleting data is incompatible with multi-row FETCH that is enabled through the
enableRowsetSupport property.
Recommendation: If your applications use the JDBC 1 technique, update them to
use the JDBC 2.0 ResultSet.updateRow or ResultSet.deleteRow methods for
positioned update or delete activity.
Testing whether the current row of a ResultSet is a delete hole or update hole in
a JDBC application:
If a ResultSet has the TYPE_SCROLL_SENSITIVE attribute, and the underlying
cursor is SENSITIVE STATIC, you need to test for delete holes or update holes
before you attempt to retrieve rows of the ResultSet.
After a SENSITIVE STATIC ResultSet is opened, it does not change size. This
means that deleted rows are replaced by placeholders, which are also called holes.
If updated rows no longer fit the criteria for the ResultSet, those rows also become
holes. You cannot retrieve rows that are holes.
To test whether the current row in a ResultSet is a delete hole or update hole,
follow these steps:
1. Call the DatabaseMetaData.deletesAreDetected or
DatabaseMetaData.updatesAreDetected method with the
TYPE_SCROLL_SENSITIVE argument to determine whether the data source
creates holes for a TYPE_SCROLL_SENSITIVE ResultSet.
2. If DatabaseMetaData.deletesAreDetected or
DatabaseMetaData.updatesAreDetected returns true, which means that the data
source can create holes, call the ResultSet.rowDeleted or ResultSet.rowUpdated
method to determine whether the current row is a delete or update hole. If the
method returns true, the current row is a hole.
The following code tests whether the current row is a delete hole.
44
Application Programming Guide and Reference for Java
Statement stmt = con.createStatement(ResultSet.TYPE_SCROLL_SENSITIVE,
ResultSet.CONCUR_UPDATABLE);
// Create a Statement object
// for a scrollable, updatable
// ResultSet
ResultSet rs =
stmt.executeQuery("SELECT EMPNO FROM EMPLOYEE FOR UPDATE OF PHONENO");
// Create the ResultSet
DatabaseMetaData dbmd = con.getMetaData();
// Create the DatabaseMetaData object
boolean dbSeesDeletes =
dbmd.deletesAreDetected(ResultSet.TYPESCROLL_SENSITIVE);
// Can the database see delete holes?
rs.afterLast();
// Position the cursor at the end of
// the ResultSet
while (rs.previous()) {
// Position the cursor backward
if (dbSeesDeletes) {
// If delete holes can be detected
if (!(rs.rowDeleted()))
// If this row is not a delete hole
{
s = rs.getString("EMPNO");
// Retrieve the employee number
System.out.println("Employee number = " + s);
// Print the column value
}
}
}
rs.close();
// Close the ResultSet
stmt.close();
// Close the Statement
Inserting a row into a ResultSet in a JDBC application:
If a ResultSet has a resultSetConcurrency attribute of CONCUR_UPDATABLE, you
can insert rows into the ResultSet.
To insert a row into a ResultSet, follow these steps:
1. Perform the following steps for each row that you want to insert.
a. Call the ResultSet.moveToInsertRow method to create the row that you
want to insert. The row is created in a buffer outside the ResultSet.
If an insert buffer already exists, all old values are cleared from the buffer.
b. Call ResultSet.updateXXX methods to assign values to the row that you
want to insert.
You need to assign a value to at least one column in the ResultSet. If you
do not do so, an SQLException is thrown when the row is inserted into the
ResultSet.
If you do not assign a value to a column of the ResultSet, when the
underlying table is updated, the data source inserts the default value for the
associated table column.
If you assign a null value to a column that is defined as NOT NULL, the
JDBC driver throws and SQLException.
c. Call ResultSet.insertRow to insert the row into the ResultSet.
After you call ResultSet.insertRow, all values are always cleared from the
insert buffer, even if ResultSet.insertRow fails.
2. Reposition the cursor within the ResultSet.
To move the cursor from the insert row to the ResultSet, you can invoke any
of the methods that position the cursor at a specific row, such as
ResultSet.first, ResultSet.absolute, or ResultSet.relative. Alternatively,
you can call ResultSet.moveToCurrentRow to move the cursor to the row in the
ResultSet that was the current row before the insert operation occurred.
Chapter 3. JDBC application programming
45
After you call ResultSet.moveToCurrentRow, all values are cleared from the
insert buffer.
Example: The following code illustrates inserting a row into a ResultSet that
consists of all rows in the sample DEPARTMENT table. After the row is inserted,
the code places the cursor where it was located in the ResultSet before the insert
operation. The numbers to the right of selected statements correspond to the
previously-described steps.
stmt = con.createStatement(ResultSet.TYPE_SCROLL_SENSITIVE,
ResultSet.CONCUR_UPDATABLE);
ResultSet rs = stmt.executeQuery("SELECT * FROM DEPARTMENT");
rs.moveToInsertRow();
1a
rs.updateString("DEPT_NO", "M13");
1b
rs.updateString("DEPTNAME", "TECHNICAL SUPPORT");
rs.updateString("MGRNO", "000010");
rs.updateString("ADMRDEPT", "A00");
rs.insertRow();
1c
rs.moveToCurrentRow();
2
Testing whether the current row was inserted into a ResultSet in a JDBC
application:
If a ResultSet is dynamic, you can insert rows into it. After you insert rows into a
ResultSet you might need to know which rows were inserted.
To test whether the current row in a ResultSet was inserted, follow these steps:
1. Call the DatabaseMetaData.ownInsertsAreVisible and
DatabaseMetaData.othersInsertsAreVisible methods to determine whether
inserts can be visible to the given type of ResultSet.
2. If inserts can be visible to the ResultSet, call the
DatabaseMetaData.insertsAreDetected method to determine whether the given
type of ResultSet can detect inserts.
3. If the ResultSet can detect inserts, call the ResultSet.rowInserted method to
determine whether the current row was inserted.
Calling stored procedures in JDBC applications
To call stored procedures, you invoke methods in the CallableStatement class.
The basic steps for calling a stored procedures using standard CallableStatement
methods are:
1. Invoke the Connection.prepareCall method with the CALL statement as its
argument to create a CallableStatement object.
You can represent parameters with standard parameter markers (?) or named
parameter markers. You cannot mix named parameter markers with standard
parameter markers in the same CALL statement.
Restriction: The parameter types that are permitted depend on whether the
data source supports dynamic execution of the CALL statement. DB2 for z/OS
does not support dynamic execution of the CALL statement. For a call to a
stored procedure that is on a DB2 for z/OS database server, the parameters can
be parameter markers or literals, but not expressions. The following table lists
the types of literals that are supported, and the JDBC types to which they map.
46
Application Programming Guide and Reference for Java
Table 12. Supported literal types in parameters in DB2 for z/OS stored procedure calls
Literal parameter type
JDBC type
Examples
Integer
java.sql.Types.INTEGER
-122, 40022, +27
Floating-point decimal
java.sql.Types.DOUBLE
23E12, 40022E-4, +2723E+15, 1E+23, 0E0
Fixed-point decimal
java.sql.Types.DECIMAL
-23.12, 40022.4295, 0.0, +2723.23, 10000000000
Character
java.sql.Types.VARCHAR
'Grantham Lutz', 'O''Conner', 'ABcde?z?'
Hexadecimal
java.sql.Types.VARBINARY
X'C1C30427', X'00CF18E0'
Unicode string
java.sql.Types.VARCHAR
UX'0041', UX'0054006500730074'
2. Invoke the CallableStatement.setXXX methods to pass values to the input
parameters (parameters that are defined as IN or INOUT in the CREATE
PROCEDURE statement).
This step assumes that you use standard parameter markers or named
parameters. Alternatively, if you use named parameter markers, you use IBM
Data Server Driver for JDBC and SQLJ-only methods to pass values to the
input parameters.
Restriction: If the data source does not support dynamic execution of the
CALL statement, you must specify the data types for CALL statement input
parameters exactly as they are specified in the stored procedure definition.
3. Invoke the CallableStatement.registerOutParameter method to register
parameters that are defined as OUT in the CREATE PROCEDURE statement
with specific data types.
This step assumes that you use standard parameter markers. Alternatively, if
you use named parameter markers, you use IBM Data Server Driver for JDBC
and SQLJ-only methods to register OUT parameters with specific data types.
Restriction: If the data source does not support dynamic execution of the
CALL statement, you must specify the data types for CALL statement OUT, IN,
or INOUT parameters exactly as they are specified in the stored procedure
definition.
4. Invoke one of the following methods to call the stored procedure:
CallableStatement.executeUpdate
Invoke this method if the stored procedure does not return result sets.
CallableStatement.executeQuery
Invoke this method if the stored procedure returns one result set.
You can invoke CallableStatement.executeQuery for a stored procedure
that returns no result sets if you set property
allowNullResultSetForExecuteQuery to DB2BaseDataSource.YES (1). In that
case, CallableStatement.executeQuery returns null. This behavior does not
conform to the JDBC standard.
CallableStatement.execute
Invoke this method if the stored procedure returns multiple result sets, or
an unknown number of result sets.
Restriction: IBM Informix data sources do not support multiple result sets.
5. If the stored procedure returns multiple result sets, retrieve the result sets.
Restriction: IBM Informix data sources do not support multiple result sets.
Chapter 3. JDBC application programming
47
6. Invoke the CallableStatement.getXXX methods to retrieve values from the OUT
parameters or INOUT parameters.
7. Invoke the CallableStatement.close method to close the CallableStatement
object when you have finished using that object.
Example: The following code illustrates calling a stored procedure that has one
input parameter, four output parameters, and no returned ResultSets. The
numbers to the right of selected statements correspond to the previously-described
steps.
int ifcaret;
int ifcareas;
int xsbytes;
String errbuff;
Connection con;
CallableStatement cstmt;
ResultSet rs;
...
cstmt = con.prepareCall("CALL DSN8.DSN8ED2(?,?,?,?,?)");
// Create a CallableStatement object
cstmt.setString (1, "DISPLAY THREAD(*)");
// Set input parameter (DB2 command)
cstmt.registerOutParameter (2, Types.INTEGER);
// Register output parameters
cstmt.registerOutParameter (3, Types.INTEGER);
cstmt.registerOutParameter (4, Types.INTEGER);
cstmt.registerOutParameter (5, Types.VARCHAR);
cstmt.executeUpdate();
// Call the stored procedure
ifcaret = cstmt.getInt(2);
// Get the output parameter values
ifcareas = cstmt.getInt(3);
xsbytes = cstmt.getInt(4);
errbuff = cstmt.getString(5);
cstmt.close();
1
2
3
4
6
7
Related tasks
“Using named parameter markers with CallableStatement objects” on page 74
Related reference
“Driver support for JDBC APIs” on page 283
Retrieving multiple result sets from a stored procedure in a
JDBC application
If you call a stored procedure that returns result sets, you need to include code to
retrieve the result sets.
The steps that you take depend on whether you know how many result sets are
returned, and whether you know the contents of those result sets.
Related tasks
“Retrieving data from tables using the PreparedStatement.executeQuery method”
on page 34
“Retrieving data from tables using the Statement.executeQuery method” on page
33
“Calling stored procedures in JDBC applications” on page 46
Retrieving a known number of result sets from a stored procedure in a JDBC
application:
Retrieving a known number of result sets from a stored procedure is a simpler
procedure than retrieving an unknown number of result sets.
48
Application Programming Guide and Reference for Java
To retrieve result sets when you know the number of result sets and their contents,
follow these steps:
1. Invoke the Statement.execute method, the PreparedStatement.execute method,
or the CallableStatement.execute method to call the stored procedure.
Use PreparedStatement.execute if the stored procedure has input parameters.
2. Invoke the getResultSet method to obtain the first result set, which is in a
ResultSet object.
3. In a loop, position the cursor using the next method, and retrieve data from
each column of the current row of the ResultSet object using getXXX methods.
4. If there are n result sets, repeat the following steps n-1 times:
a. Invoke the getMoreResults method to close the current result set and point
to the next result set.
b. Invoke the getResultSet method to obtain the next result set, which is in a
ResultSet object.
c. In a loop, position the cursor using the next method, and retrieve data from
each column of the current row of the ResultSet object using getXXX
methods.
Example: The following code illustrates retrieving two result sets. The first result
set contains an INTEGER column, and the second result set contains a CHAR
column. The numbers to the right of selected statements correspond to the
previously described steps.
CallableStatement cstmt;
ResultSet rs;
int i;
String s;
...
cstmt.execute();
// Call the stored procedure
1
rs = cstmt.getResultSet();
// Get the first result set
2
while (rs.next()) {
// Position the cursor
3
i = rs.getInt(1);
// Retrieve current result set value
System.out.println("Value from first result set = " + i);
// Print the value
}
cstmt.getMoreResults();
// Point to the second result set 4a
// and close the first result set
rs = cstmt.getResultSet();
// Get the second result set
4b
while (rs.next()) {
// Position the cursor
4c
s = rs.getString(1);
// Retrieve current result set value
System.out.println("Value from second result set = " + s);
// Print the value
}
rs.close();
// Close the result set
cstmt.close();
// Close the statement
Retrieving an unknown number of result sets from a stored procedure in a
JDBC application:
Retrieving an unknown number of result sets from a stored procedure is a more
complicated procedure than retrieving a known number of result sets.
To retrieve result sets when you do not know the number of result sets or their
contents, you need to retrieve ResultSets, until no more ResultSets are returned.
For each ResultSet, use ResultSetMetaData methods to determine its contents.
After you call a stored procedure, follow these basic steps to retrieve the contents
of an unknown number of result sets.
Chapter 3. JDBC application programming
49
1. Check the value that was returned from the execute statement that called the
stored procedure.
If the returned value is true, there is at least one result set, so you need to go
to the next step.
2. Repeat the following steps in a loop:
a. Invoke the getResultSet method to obtain a result set, which is in a
ResultSet object. Invoking this method closes the previous result set.
b. Use ResultSetMetaData methods to determine the contents of the ResultSet,
and retrieve data from the ResultSet.
c. Invoke the getMoreResults method to determine whether there is another
result set. If getMoreResults returns true, go to step 1 to get the next result
set.
Example: The following code illustrates retrieving result sets when you do not
know the number of result sets or their contents. The numbers to the right of
selected statements correspond to the previously described steps.
CallableStatement cstmt;
ResultSet rs;
...
boolean resultsAvailable = cstmt.execute(); // Call the stored procedure
while (resultsAvailable) {
// Test for result sets
1
ResultSet rs = cstmt.getResultSet();
// Get a result set
2a
...
// Process the ResultSet
// as you would process
// a ResultSet from a table
resultsAvailable = cstmt.getMoreResults(); // Check for next result set 2c
// (Also closes the
// previous result set)
}
Related tasks
“Learning about a ResultSet using ResultSetMetaData methods” on page 36
Keeping result sets open when retrieving multiple result sets from a stored
procedure in a JDBC application:
The getMoreResults method has a form that lets you leave the current ResultSet
open when you open the next ResultSet.
To specify whether result sets stay open, follow this process:
When you call getMoreResults to check for the next ResultSet, use this form:
CallableStatement.getMoreResults(int current);
v To keep the current ResultSet open when you check for the next ResultSet,
specify a value of Statement.KEEP_CURRENT_RESULT for current.
v To close the current ResultSet when you check for the next ResultSet, specify a
value of Statement.CLOSE_CURRENT_RESULT for current.
v To close all ResultSet objects, specify a value of Statement.CLOSE_ALL_RESULTS
for current.
Example: The following code keeps all ResultSets open until the final ResultSet
has been retrieved, and then closes all ResultSets.
CallableStatement cstmt;
...
boolean resultsAvailable = cstmt.execute(); // Call the stored procedure
if (resultsAvailable==true) {
// Test for result set
ResultSet rs1 = cstmt.getResultSet();
// Get a result set
50
Application Programming Guide and Reference for Java
...
resultsAvailable = cstmt.getMoreResults(Statement.KEEP_CURRENT_RESULT);
// Check for next result set
// but do not close
// previous result set
if (resultsAvailable==true) {
// Test for another result set
ResultSet rs2 = cstmt.getResultSet();
// Get next result set
...
// Process either ResultSet
}
}
resultsAvailable = cstmt.getMoreResults(Statement.CLOSE_ALL_RESULTS);
// Close the result sets
LOBs in JDBC applications with the IBM Data Server Driver
for JDBC and SQLJ
The IBM Data Server Driver for JDBC and SQLJ supports methods for updating
and retrieving data from BLOB, CLOB, and DBCLOB columns in a table, and for
calling stored procedures or user-defined functions with BLOB or CLOB
parameters.
Related reference
“Driver support for JDBC APIs” on page 283
“Properties for the IBM Data Server Driver for JDBC and SQLJ” on page 221
Progressive streaming with the IBM Data Server Driver for JDBC
and SQLJ
If the data source supports progressive streaming, also known as dynamic data
format, the IBM Data Server Driver for JDBC and SQLJ can use progressive
streaming to retrieve data in LOB or XML columns.
DB2 for z/OS Version 9.1 and later supports progressive streaming for LOBs and
XML objects. DB2 Database for Linux, UNIX, and Windows Version 9.5 and later,
IBM Informix Version 11.50 and later, and DB2 for i V6R1 and later support
progressive streaming for LOBs.
With progressive streaming, the data source dynamically determines the most
efficient mode in which to return LOB or XML data, based on the size of the LOBs
or XML objects.
Progressive streaming is the default behavior in the following environments:
MinimumIBM Data Server
Driver for JDBC and SQLJ
version
Minimum data server
version
Types of objects
3.53
DB2 for i V6R1
LOB, XML
3.50
DB2 Database for Linux,
UNIX, and Windows Version
9.5
LOB
3.50
IBM Informix Version 11.50
LOB
3.2
DB2 for z/OS Version 9
LOB, XML
You set the progressive streaming behavior on new connections using the IBM
Data Server Driver for JDBC and SQLJ progressiveStreaming property.
For DB2 for z/OS Version 9.1 and later data sources, or DB2 Database for Linux,
UNIX, and Windows Version 9.5 and later data sources, you can set the
Chapter 3. JDBC application programming
51
progressive streaming behavior for existing connections with the
DB2Connection.setDBProgressiveStreaming(DB2BaseDataSource.YES) method. If
you call DB2Connection.setDBProgressiveStreaming(DB2BaseDataSource.YES),
all ResultSet objects that are created on the connection use progressive streaming
behavior.
When progressive streaming is enabled, you can control when the JDBC driver
materializes LOBs with the streamBufferSize property. If a LOB or XML object is
less than or equal to the streamBufferSize value, the object is materialized.
Important: With progressive streaming, when you retrieve a LOB or XML value
from a ResultSet into an application variable, you can manipulate the contents of
that application variable until you move the cursor or close the cursor on the
ResultSet. After that, the contents of the application variable are no longer
available to you. If you perform any actions on the LOB in the application variable,
you receive an SQLException. For example, suppose that progressive streaming is
enabled, and you execute statements like this:
...
ResultSet rs = stmt.executeQuery("SELECT CLOBCOL FROM MY_TABLE");
rs.next();
// Retrieve the first row of the ResultSet
Clob clobFromRow1 = rs.getClob(1);
// Put the CLOB from the first column of
// the first row in an application variable
String substr1Clob = clobFromRow1.getSubString(1,50);
// Retrieve the first 50 bytes of the CLOB
rs.next();
// Move the cursor to the next row.
// clobFromRow1 is no longer available.
// String substr2Clob = clobFromRow1.getSubString(51,100);
// This statement would yield an SQLException
Clob clobFromRow2 = rs.getClob(1);
// Put the CLOB from the first column of
// the second row in an application variable
rs.close();
// Close the ResultSet.
// clobFromRow2 is also no longer available.
After you execute rs.next() to position the cursor at the second row of the
ResultSet, the CLOB value in clobFromRow1 is no longer available to you.
Similarly, after you execute rs.close() to close the ResultSet, the values in
clobFromRow1 and clobFromRow2 are no longer available.
If you disable progressive streaming, the way in which the IBM Data Server Driver
for JDBC and SQLJ handles LOBs depends on the value of the
fullyMaterializeLobData property.
Use of progressive streaming is the preferred method of LOB or XML data
retrieval.
LOB locators with the IBM Data Server Driver for JDBC and
SQLJ
The IBM Data Server Driver for JDBC and SQLJ can use LOB locators to retrieve
data in LOB columns.
To cause JDBC to use LOB locators to retrieve data from LOB columns, you need
to set the fullyMaterializeLobData property to false and set the
progressiveStreaming property to NO (DB2BaseDataSource.NO in an application
program).
52
Application Programming Guide and Reference for Java
The effect of fullyMaterializeLobData depends on whether the data source
supports progressive streaming and the value of the progressiveStreaming
property:
v If the data source does not support progressive locators:
If the value of fullyMaterializeLobData is true, LOB data is fully materialized
within the JDBC driver when a row is fetched. If the value is false, LOB data is
streamed. The driver uses locators internally to retrieve LOB data in chunks on
an as-needed basis It is highly recommended that you set this value to false
when you retrieve LOBs that contain large amounts of data. The default is true.
v If the data source supports progressive streaming, also known as dynamic data
format:
The JDBC driver ignores the value of fullyMaterializeLobData if the
progressiveStreaming property is set to YES (DB2BaseDataSource.YES in an
application program) or is not set.
fullyMaterializeLobData has no effect on stored procedure parameters.
As in any other language, a LOB locator in a Java application is associated with
only one data source. You cannot use a single LOB locator to move data between
two different data sources. To move LOB data between two data sources, you need
to materialize the LOB data when you retrieve it from a table in the first data
source and then insert that data into the table in the second data source.
LOB operations with the IBM Data Server Driver for JDBC and
SQLJ
The IBM Data Server Driver for JDBC and SQLJ supports methods for updating
and retrieving data from BLOB, CLOB, and DBCLOB columns in a table, and for
calling stored procedures or user-defined functions with BLOB or CLOB
parameters.
Among the operations that you can perform on LOB data under the IBM Data
Server Driver for JDBC and SQLJ are:
v Specify a BLOB or column as an argument of the following ResultSet methods
to retrieve data from a BLOB or CLOB column:
For BLOB columns:
– getBinaryStream
– getBlob
– getBytes
For CLOB columns:
– getAsciiStream
– getCharacterStream
– getClob
– getString
v Call the following ResultSet methods to update a BLOB or CLOB column in an
updatable ResultSet:
For BLOB columns:
– updateBinaryStream
– updateBlob
For CLOB columns:
– updateAsciiStream
– updateCharacterStream
– updateClob
Chapter 3. JDBC application programming
53
If you specify -1 for the length parameter in any of the previously listed
methods, the IBM Data Server Driver for JDBC and SQLJ reads the input data
until it is exhausted.
v Use the following PreparedStatement methods to set the values for parameters
that correspond to BLOB or CLOB columns:
For BLOB columns:
– setBytes
– setBlob
– setBinaryStream
– setObject, where the Object parameter value is an InputStream.
For CLOB columns:
– setString
– setAsciiStream
– setClob
– setCharacterStream
– setObject, where the Object parameter value is a Reader.
If you specify -1 for length, the IBM Data Server Driver for JDBC and SQLJ reads
the input data until it is exhausted.
v Retrieve the value of a JDBC CLOB parameter using the
CallableStatement.getString method.
Restriction: With IBM Data Server Driver for JDBC and SQLJ type 2 connectivity,
you cannot call a stored procedure that has DBCLOB OUT or INOUT parameters.
If you are using the IBM Data Server Driver for JDBC and SQLJ version 4.0 or
later, you can perform the following additional operations:
v Use ResultSet.updateXXX or PreparedStatement.setXXX methods to update a
BLOB or CLOB with a length value of up to 2GB for a BLOB or CLOB. For
example, these methods are defined for BLOBs:
ResultSet.updateBlob(int columnIndex, InputStream x, long length)
ResultSet.updateBlob(String columnLabel, InputStream x, long length)
ResultSet.updateBinaryStream(int columnIndex, InputStream x, long length)
ResultSet.updateBinaryStream(String columnLabel, InputStream x, long length)
PreparedStatement.setBlob(int columnIndex, InputStream x, long length)
PreparedStatement.setBlob(String columnLabel, InputStream x, long length)
PreparedStatement.setBinaryStream(int columnIndex, InputStream x, long length)
PreparedStatement.setBinaryStream(String columnLabel, InputStream x, long length)
v Use ResultSet.updateXXX or PreparedStatement.setXXX methods without the
length parameter when you update a BLOB or CLOB, to cause the IBM Data
Server Driver for JDBC and SQLJ to read the input data until it is exhausted. For
example:
ResultSet.updateBlob(int columnIndex, InputStream x)
ResultSet.updateBlob(String columnLabel, InputStream x)
ResultSet.updateBinaryStream(int columnIndex, InputStream x)
ResultSet.updateBinaryStream(String columnLabel, InputStream x)
PreparedStatement.setBlob(int columnIndex, InputStream x)
PreparedStatement.setBlob(String columnLabel, InputStream x)
PreparedStatement.setBinaryStream(int columnIndex, InputStream x)
PreparedStatement.setBinaryStream(String columnLabel, InputStream x)
v Create a Blob or Clob object that contains no data, using the
Connection.createBlob or Connection.createClob method.
v Materialize a Blob or Clob object on the client, when progressive streaming or
locators are in use, using the Blob.getBinaryStream or Clob.getCharacterStream
method.
54
Application Programming Guide and Reference for Java
v Free the resources that a Blob or Clob object holds, using the Blob.free or
Clob.free method.
Java data types for retrieving or updating LOB column data in
JDBC applications
When the JDBC driver cannot immediately determine the data type of a parameter
that is used with a LOB column, you need to choose a parameter data type that is
compatible with the LOB data type.
For IBM Data Server Driver for JDBC and SQLJ type 2 connectivity to DB2 for
z/OS, when the JDBC driver processes a CallableStatement.setXXX call for a
stored procedure input parameter, or a CallableStatement.registerOutParameter
call for a stored procedure output parameter, the driver cannot determine the
parameter data types.
When the deferPrepares property is set to true, and the IBM Data Server Driver for
JDBC and SQLJ processes a PreparedStatement.setXXX call, the driver might need
to do extra processing to determine data types. This extra processing can impact
performance.
Input parameters for BLOB columns
For IN parameters for BLOB columns, or INOUT parameters that are used for
input to BLOB columns, you can use one of the following techniques:
v Use a java.sql.Blob input variable, which is an exact match for a BLOB column:
cstmt.setBlob(parmIndex, blobData);
v Use a CallableStatement.setObject call that specifies that the target data type is
BLOB:
byte[] byteData = {(byte)0x1a, (byte)0x2b, (byte)0x3c};
cstmt.setObject(parmInd, byteData, java.sql.Types.BLOB);
v Use an input parameter of type of java.io.ByteArrayInputStream with a
CallableStatement.setBinaryStream call. A java.io.ByteArrayInputStream
object is compatible with a BLOB data type. For this call, you need to specify the
exact length of the input data:
java.io.ByteArrayInputStream byteStream =
new java.io.ByteArrayInputStream(byteData);
int numBytes = byteData.length;
cstmt.setBinaryStream(parmIndex, byteStream, numBytes);
Output parameters for BLOB columns
For OUT parameters for BLOB columns, or INOUT parameters that are used for
output from BLOB columns, you can use the following technique:
v Use the CallableStatement.registerOutParameter call to specify that an output
parameter is of type BLOB. Then you can retrieve the parameter value into any
variable that has a data type that is compatible with a BLOB data type. For
example, the following code lets you retrieve a BLOB value into a byte[]
variable:
cstmt.registerOutParameter(parmIndex, java.sql.Types.BLOB);
cstmt.execute();
byte[] byteData = cstmt.getBytes(parmIndex);
Chapter 3. JDBC application programming
55
Input parameters for CLOB columns
For IN parameters for CLOB columns, or INOUT parameters that are used for
input to CLOB columns, you can use one of the following techniques:
v Use a java.sql.Clob input variable, which is an exact match for a CLOB column:
cstmt.setClob(parmIndex, clobData);
v Use a CallableStatement.setObject call that specifies that the target data type is
CLOB:
String charData = "CharacterString";
cstmt.setObject(parmInd, charData, java.sql.Types.CLOB);
v Use one of the following types of stream input parameters:
– A java.io.StringReader input parameter with a cstmt.setCharacterStream
call:
java.io.StringReader reader = new java.io.StringReader(charData);
cstmt.setCharacterStream(parmIndex, reader, charData.length);
– A java.io.ByteArrayInputStream parameter with a cstmt.setAsciiStream
call, for ASCII data:
byte[] charDataBytes = charData.getBytes("US-ASCII");
java.io.ByteArrayInputStream byteStream =
new java.io.ByteArrayInputStream (charDataBytes);
cstmt.setAsciiStream(parmIndex, byteStream, charDataBytes.length);
For these calls, you need to specify the exact length of the input data.
v Use a String input parameter with a cstmt.setString call:
cstmt.setString(parmIndex, charData);
If the length of the data is greater than 32KB, and the JDBC driver has no
DESCRIBE information about the parameter data type, the JDBC driver assigns
the CLOB data type to the input data.
v Use a String input parameter with a cstmt.setObject call, and specify the target
data type as VARCHAR or LONGVARCHAR:
cstmt.setObject(parmIndex, charData, java.sql.Types.VARCHAR);
If the length of the data is greater than 32KB, and the JDBC driver has no
DESCRIBE information about the parameter data type, the JDBC driver assigns
the CLOB data type to the input data.
Output parameters for CLOB columns
For OUT parameters for CLOB columns, or INOUT parameters that are used for
output from CLOB columns, you can use one of the following techniques:
v Use the CallableStatement.registerOutParameter call to specify that an output
parameter is of type CLOB. Then you can retrieve the parameter value into a
Clob variable. For example:
cstmt.registerOutParameter(parmIndex, java.sql.Types.CLOB);
cstmt.execute();
Clob clobData = cstmt.getClob(parmIndex);
v Use the CallableStatement.registerOutParameter call to specify that an output
parameter is of type VARCHAR or LONGVARCHAR:
cstmt.registerOutParameter(parmIndex, java.sql.Types.VARCHAR);
cstmt.execute();
String charData = cstmt.getString(parmIndex);
56
Application Programming Guide and Reference for Java
This technique should be used only if you know that the length of the retrieved
data is less than or equal to 32KB. Otherwise, the data is truncated.
Related concepts
“LOBs in JDBC applications with the IBM Data Server Driver for JDBC and SQLJ”
on page 51
Related reference
“Data types that map to database data types in Java applications” on page 211
ROWIDs in JDBC with the IBM Data Server Driver for JDBC
and SQLJ
DB2 for z/OS and DB2 for i support the ROWID data type for a column in a
database table. A ROWID is a value that uniquely identifies a row in a table.
Although IBM Informix also supports rowids, those rowids have the INTEGER
data type. You can select an IBM Informix rowid column into a variable with a
four-byte integer data type.
You can use the following ResultSet methods to retrieve data from a ROWID
column:
v getRowId (JDBC 4.0 and later)
v getBytes
v getObject
You can use the following ResultSet method to update a ROWID column of an
updatable ResultSet:
v updateRowId (JDBC 4.0 and later)
updateRowId is valid only if the target database system supports updating of
ROWID columns.
If you are using JDBC 3.0, for getObject, the IBM Data Server Driver for JDBC and
SQLJ returns an instance of the IBM Data Server Driver for JDBC and SQLJ-only
class com.ibm.db2.jcc.DB2RowID.
If you are using JDBC 4.0, for getObject, the IBM Data Server Driver for JDBC and
SQLJ returns an instance of the class java.sql.RowId.
You can use the following PreparedStatement methods to set a value for a
parameter that is associated with a ROWID column:
v setRowId (JDBC 4.0 and later)
v setBytes
v setObject
If you are using JDBC 3.0, for setObject, use the IBM Data Server Driver for JDBC
and SQLJ-only type com.ibm.db2.jcc.Types.ROWID or an instance of the
com.ibm.db2.jcc.DB2RowID class as the target type for the parameter.
If you are using JDBC 4.0, for setObject, use the type java.sql.Types.ROWID or an
instance of the java.sql.RowId class as the target type for the parameter.
You can use the following CallableStatement methods to retrieve a ROWID
column as an output parameter from a stored procedure call:
v getRowId (JDBC 4.0 and later)
v getObject
Chapter 3. JDBC application programming
57
To call a stored procedure that is defined with a ROWID output parameter, register
that parameter to be of the java.sql.Types.ROWID type.
ROWID values are valid for different periods of time, depending on the data
source on which those ROWID values are defined. Use the
DatabaseMetaData.getRowIdLifetime method to determine the time period for
which a ROWID value is valid. The values that are returned for the data sources
are listed in the following table.
Table 13. DatabaseMetaData.getRowIdLifetime values for supported data sources
Database server
DatabaseMetaData.getRowIdLifetime
DB2 for z/OS
ROWID_VALID_TRANSACTION
DB2 Database for Linux, UNIX, and Windows
ROWID_UNSUPPORTED
DB2 for i
ROWID_VALID_FOREVER
IBM Informix
ROWID_VALID_FOREVER
Example: Using PreparedStatement.setRowId with a java.sql.RowId target type: Suppose
that rwid is a RowId object. To set parameter 1, use this form of the setRowId
method:
ps.setRowId(1, rid);
Example: Using ResultSet.getRowId to retrieve a ROWID value from a data source: To
retrieve a ROWID value from the first column of a result set into RowId object
rwid, use this form of the ResultSet.getRowId method:
java.sql.RowId rwid = rs.getRowId(1);
Example: Using CallableStatement.registerOutParameter with a java.sql.Types.ROWID
parameter type: To register parameter 1 of a CALL statement as a
java.sql.Types.ROWID data type, use this form of the registerOutParameter
method:
cs.registerOutParameter(1, java.sql.Types.ROWID)
Related reference
“Data types that map to database data types in Java applications” on page 211
Update and retrieval of timestamps with time zone information
in JDBC applications
The JDBC methods and data types that you use and the information that the IBM
Data Server Driver for JDBC and SQLJ has about the column data types determine
the timestamp values that are sent to and received from TIMESTAMP WITH TIME
ZONE or TIMESTAMP columns.
Updates of values in TIMESTAMP or TIMESTAMP WITH TIME
ZONE columns
You can use the following standard JDBC methods to update a TIMESTAMP WITH
TIME ZONE or TIMESTAMP column:
v PreparedStatement.setObject
v PreparedStatement.setTimestamp
v PreparedStatement.setString
For a PreparedStatement.setTimestamp call in which the second parameter is a
DBTimestamp object and the third parameter is a Calendar object, the value that is
58
Application Programming Guide and Reference for Java
passed to a TIMESTAMP WITH TIME ZONE or TIMESTAMP column contains the
time zone value in the Calendar parameter, and not the time zone value in the
DBTimestamp object. For a PreparedStatement.setTimestamp in which the second
parameter is a DBTimestamp object and there is no Calendar parameter, the IBM
Data Server Driver for JDBC and SQLJ value that is passed to a TIMESTAMP
WITH TIME ZONE or TIMESTAMP column has the default time zone, which is
that of the Java virtual machine in which the application is running.
If you want the value that is passed to a TIMESTAMP WITH TIME ZONE or
TIMESTAMP column to use the time zone that is in the DBTimestamp object, you
need to use PreparedStatement.setObject.
Example: Suppose that table TSTABLE is defined like this:
CREATE TABLE TSTABLE (
TSCOL TIMESTAMP,
TSTZCOL TIMESTAMP WITH TIME ZONE)
Also suppose that the default time zone of the Java Virtual Machine (JVM) is
GMT-08:00 (Pacific Standard Time). The following code assigns timestamp values
to the column.
...
java.util.TimeZone esttz = java.util.TimeZone.getTimeZone("EST");
java.util.Calendar estcal = java.util.Calendar.getInstance(esttz);
// Construct a Calendar object with the
// GMT-05:00 (Eastern Standard Time) time zone.
java.util.Calendar defcal = java.util.Calendar.getInstance();
// Construct a Calendar object
// with the default time zone.
java.sql.Timestamp ts =
java.sql.Timestamp.valueOf("2010-10-27 21:22:33.123456");
// Assign a timestamp to a Timestamp object.
DBTimestamp dbts = new DBTimestamp(ts,estcal);
// Construct a DBTimestamp object that has
// the GMT-05:00 time zone.
...
PreparedStatement ps = con.prepareStatement(
"INSERT INTO TSTABLE (TSCOL,TSTZCOL) VALUES (?,?)");
//
// Use setTimestamp methods to assign a timestamp value to a
// TIMESTAMP WITH TIME ZONE or TIMESTAMP column
//
ps.setTimestamp(1, ts); // Assign a timestamp value in a Timestamp
// object to a TIMESTAMP column.
ps.setTimestamp(2,ts); // Assign the same timestamp value to
// a TIMESTAMP WITH TIME ZONE column.
ps.execute(); // 2010-10-27-21.22.33.123456 is assigned to TSCOL
// if the driver has information that the column
// has the TIMESTAMP data type.
// 2010-10-27-21.22.33.123456-08:00 is assigned to TSCOL
// if the driver has no information about the column
// data type.
// 2010-10-27-21.22.33.123456-08:00 is assigned
// to TSTZCOL regardless of whether the driver
// has information that the the column has
// the TIMESTAMP WITH TIME ZONE data type.
ps.setTimestamp(1, dbts);
// Assign a timestamp value in a DBTimestamp
// object to a TIMESTAMP column.
ps.setTimestamp(2,dbts);
// Assign the same timestamp value to
// a TIMESTAMP WITH TIME ZONE column.
ps.execute(); // 2010-10-27-21.22.33.123456 is assigned to TSCOL
// if the driver has information that the column
Chapter 3. JDBC application programming
59
// has the TIMESTAMP data type.
// 2010-10-27-21.22.33.123456-08:00 is assigned to TSCOL
// if the driver has no information about the column
// data type.
// 2010-02-27-21.22.33.123456-08:00 is assigned
// to TSTZCOL regardless of whether the driver
// has information that the the column has
// the TIMESTAMP WITH TIME ZONE data type. The
// default time zone of GMT-08:00 is sent to
// the column.
ps.setTimestamp(1, ts, estcal);
// Assign a timestamp value in a Timestamp
// object to a TIMESTAMP column. Include
// a Calendar parameter that specifies
// the GMT-05:00 time zone.
ps.setTimestamp(2, ts, estcal);
// Assign the same timestamp value to
// a TIMESTAMP WITH TIME ZONE column. Include
// a Calendar parameter that specifies the
// GMT-05:00 time zone.
ps.execute(); // 2010-10-28-00.22.33.123456 is assigned to TSCOL
// if the driver has information that the column
// has the TIMESTAMP data type.
// The value is adjusted for the difference
// between the time zone in the Calendar parameter and
// the default time zone.
// 2010-10-28-00.22.33.123456-05:00 is assigned to TSCOL
// if the driver has no information about the column
// data type. The value is adjusted for the difference
// between the time zone in the Calendar parameter and
// the default time zone.
// 2010-10-28-00.22.33.123456-05:00 is assigned
// to TSTZCOL regardless of whether the driver
// has information that the the column has
// the TIMESTAMP WITH TIME ZONE data type.
// The value is adjusted for the difference
// between the time zone in the Calendar parameter and
// the default time zone.
ps.setTimestamp(1, dbts, estcal);
// Assign a timestamp value in a DBTimestamp
// object to a TIMESTAMP column. Include
// a Calendar parameter that specifies the
// GMT-05:00 time zone.
ps.setTimestamp(2, dbts, estcal);
// Assign the same timestamp value to
// a TIMESTAMP WITH TIME ZONE column.
ps.execute(); // 2010-10-28-00.22.33.123456 is assigned to TSCOL
// if the driver has information that the column
// has the TIMESTAMP data type.
// The value is adjusted for the difference
// between the time zone in the Calendar parameter and
// the default time zone.
// 2010-10-28-00.22.33.123456-05:00 is assigned to TSCOL
// if the driver has no information about the column
// data type.
// The value is adjusted for the difference
// between the time zone in the Calendar parameter and
// the default time zone.
// 2010-10-28-00.22.33.123456-05:00 is assigned
// to TSTZCOL regardless of whether the driver
// has information that the the column has
// the TIMESTAMP WITH TIME ZONE data type. The
// time zone in the Calendar parameter, GMT-05:00,
// is sent to the column.
// The value is adjusted for the difference
// between the time zone in the Calendar parameter and
// the default time zone.
60
Application Programming Guide and Reference for Java
ps.setTimestamp(1, ts, defcal);
// Assign a timestamp value in a Timestamp
// object to a TIMESTAMP column. Include
// a Calendar parameter that specifies
// the default time zone (GMT-08:00).
ps.setTimestamp(2, ts, defcal);
// Assign the same timestamp value to
// a TIMESTAMP WITH TIME ZONE column. Include
// a Calendar parameter that specifies the
// default (GMT-08:00) time zone.
ps.execute(); // 2010-10-27-21.22.33.123456 is assigned to TSCOL
// if the driver has information that the column
// has the TIMESTAMP data type.
// 2010-10-27-21.22.33.123456-08:00 is assigned to TSCOL
// if the driver has no information about the column
// data type.
// 2010-10-27-21.22.33.123456-08:00 is assigned
// to TSTZCOL regardless of whether the driver
// has information that the the column has
// the TIMESTAMP WITH TIME ZONE data type.
ps.setTimestamp(1, dbts, defcal);
// Assign a timestamp value in a DBTimestamp
// object to a TIMESTAMP column
ps.setTimestamp(2, dbts, defcal);
// Assign the same timestamp value to
// a TIMESTAMP WITH TIME ZONE column
ps.execute(); // 2010-10-27-21.22.33.123456 is assigned to TSCOL
// if the driver has information that the column
// has the TIMESTAMP data type
// 2010-10-27-21.22.33.123456-08:00 is assigned to TSCOL
// if the driver has no information about the column
// data type
// 2010-10-27-21.22.33.123456-08:00 is assigned
// to TSTZCOL regardless of whether the driver
// has information that the the column has
// the TIMESTAMP WITH TIME ZONE data type. The
// default time zone in the Calendar parameter,
// GMT-08:00, is sent to the column.
//
// Use setObject methods to assign a timestamp value to a
// TIMESTAMP WITH TIME ZONE or TIMESTAMP column
//
ps.setObject(1, ts);
// Assign a timestamp value in a Timestamp
// object to a TIMESTAMP column.
ps.setObject(2, ts);
// Assign the same timestamp value to
// a TIMESTAMP WITH TIME ZONE column.
ps.execute(); // 2010-10-27-21.22.33.123456 is assigned to TSCOL
// if the driver has information that the column
// has the TIMESTAMP data type.
// 2010-10-27-21.22.33.123456-08:00 is assigned to TSCOL
// if the driver has no information about the column
// data type. The time zone is the default time zone.
// 2010-10-27-21.22.33.123456-08:00 is assigned
// to TSTZCOL regardless of whether the driver
// has information that the the column has
// the TIMESTAMP WITH TIME ZONE data type. The
// time zone is the default time zone.
ps.setObject(1, dbts);
// Assign a timestamp value in a DBTimestamp
// object to a TIMESTAMP column.
ps.setObject(2, dbts);
// Assign the same timestamp value to
// a TIMESTAMP WITH TIME ZONE column.
ps.execute(); // 2010-10-28-00.22.33.123456 is assigned to TSCOL
// if the driver has information that the column
// has the TIMESTAMP data type.
Chapter 3. JDBC application programming
61
//
//
//
//
//
//
//
//
//
2010-10-28-00.22.33.123456-05:00 is assigned to TSCOL
if the driver has no information about the column
data type.
2010-10-28-00.22.33.123456-05:00 is assigned
to TSTZCOL regardless of whether the driver
has information that the the column has
the TIMESTAMP WITH TIME ZONE data type.
The time zone is the time zone in the DBTimestamp
object.
//
// Use setString methods to assign a timestamp value to a
// TIMESTAMP WITH TIME ZONE or TIMESTAMP column
//
ps.setString(1, "2010-10-27-21.22.33.123456");
// Assign a constant timestamp value
// with no time zone to a TIMESTAMP column.
ps.setString(2, "2010-10-27-21.22.33.123456");
// Assign the same timestamp value to
// a TIMESTAMP WITH TIME ZONE column.
ps.execute(); // 2010-10-27-21.22.33.123456 is assigned to TSCOL
// regardless of whether the driver has information
// that the column has the TIMESTAMP data type.
// 2010-10-27-21.22.33.123456-08:00 is assigned
// to TSTZCOL if the driver has information that
// the column has the TIMESTAMP WITH TIME ZONE
// data type. The time zone is the default time zone.
// 2010-10-27-21.22.33.123456 is assigned to TSTZCOL
// if the driver has no information about the column
// data type.
ps.setString(1, "2010-10-27-21.22.33.123456-05:00");
// Assign a constant timestamp value
// with a time zone to a TIMESTAMP column.
ps.setString(2, "2010-10-27-21.22.33.123456-05:00");
// Assign the same timestamp value to
// a TIMESTAMP WITH TIME ZONE column.
ps.execute(); // 2010-10-27-21.22.33.123456 is assigned to TSCOL
// if the driver has information that the column
// data type is TIMESTAMP.
// 2010-10-27-21.22.33.123456-05:00 is assigned to
// TSCOL if the driver has no information about the
// column data type.
// 2010-10-27-21.22.33.123456-05:00 is assigned
// to TSTZCOL regardless of whether the driver has
// information that the column data type is
// TIMESTAMP WITH TIME ZONE.
Alternatively, if you want to assign data that has a time zone or has a precision of
greater than nine to a TIMESTAMP WITH TIME ZONE column, you can construct
a DBTimestamp object, and use the IBM Data Server Driver for JDBC and SQLJ-only
method DB2PreparedStatement.setDBTimestamp to update a TIMESTAMP WITH
TIME ZONE column.
Example: Suppose that table TSTABLE is defined like this:
CREATE TABLE TSTABLE (
TSCOL TIMESTAMP,
TSTZCOL TIMESTAMP(12) WITH TIME ZONE)
The following code assigns a timestamp value with a time zone and a precision of
10 to each column.
...
DBTimestamp tstz =
DBTimestamp.valueOfDBString("2010-10-28-00.22.33.1234567890-05:00");
// Create a DBTimestamp object from the input value
PreparedStatement ps = con.prepareStatement(
62
Application Programming Guide and Reference for Java
"INSERT INTO TSTABLE (TSCOL, TSTXCOL) VALUES (?,?)");
DB2PreparedStatement dbps = (DB2PreparedStatement)ps;
dbps.setDBTimestamp(1, tstz);
dbps.setDBTimestamp(2, tstz);
dbps.execute(); // 2010-10-28-00.22.33.123456 is assigned to TSCOL if
// the driver has information that the column data type is
// TIMESTAMP.
// 2010-10-28-00.22.33.1234567890-05:00 is assigned to TSCOL
// if the driver has no information about the column
// data type.
// 2010-10-28-00.22.33.1234567890-05:00 is assigned to TSTZCOL
// regardless of whether the driver has information that
// the column data type is TIMESTAMP(12) WITH TIME ZONE.
Retrieval of values from TIMESTAMP or TIMESTAMP WITH TIME
ZONE columns
You can use the following standard JDBC methods to retrieve data from a
TIMESTAMP WITH TIME ZONE or TIMESTAMP column or output parameter:
v ResultSet.getTimestamp
v CallableStatement.getTimestamp
v ResultSet.getObject
v CallableStatement.getObject
v ResultSet.getString
v CallableStatement.getString
For a ResultSet.getTimestamp, CallableStatement.getTimestamp,
ResultSet.getObject, or CallableStatement.getObject call, you can specify the
type of object that you want the IBM Data Server Driver for JDBC and SQLJ to
return by setting the DB2BaseDataSource.timestampOutputType property:
v If you set the property to DB2BaseDataSource.JDBC_TIMESTAMP (1), the driver
returns a java.sql.Timestamp object.
v If you set the property to DB2BaseDataSource.JCC_DBTIMESTAMP (2), the
driver returns a com.ibm.db2.jcc.DBTimestamp object.
For a ResultSet.getTimestamp or CallableStatement.getTimestamp call, if the
ResultSet.getTimestamp or CallableStatement.getTimestamp call has a Calendar
parameter with a non-null value, the IBM Data Server Driver for JDBC and SQLJ
uses the Calendar object when it constructs the returned object. If the
ResultSet.getTimestamp or CallableStatement.getTimestamp call has no Calendar
parameter, or the Calendar parameter value is null, the IBM Data Server Driver for
JDBC and SQLJ uses the default time zone when it constructs the returned object.
If you want to retrieve a timestamp with the time zone value that is in a
TIMESTAMP WITH TIME ZONE column, call ResultSet.getObject or
CallableStatement.getObject, and then call DBTimestamp.toDBString(true) to
retrieve the timestamp with the time zone.
getString retrieves the timestamp value in the standard JDBC format: without the
time zone, and with a precision of up to nine. The returned value is adjusted for
the difference between the time zone of the column value and the default time
zone.
Example: Suppose that table TSTABLE is defined like this:
CREATE TABLE TSTABLE (
TSCOL TIMESTAMP,
TSTZCOL TIMESTAMP WITH TIME ZONE)
Chapter 3. JDBC application programming
63
Also suppose that the default time zone is GMT-08:00 (Pacific Standard Time). The
following code retrieves timestamp values from the TIMESTAMP column.
...
java.util.TimeZone esttz = java.util.TimeZone.getTimeZone("EST");
java.util.Calendar estcal = java.util.Calendar.getInstance(esttz);
java.util.Calendar defcal = java.util.Calendar.getInstance();
Statement stmt = conn.createStatement ();
ResultSet rs = stmt.executeQuery("SELECT TSCOL, TSTZCOL FROM TSTABLE");
com.ibm.db2.jcc.DB2ResultSet dbrs = (com.ibm.db2.jcc.DB2ResultSet)rs;
Timestamp ts;
DBTimestamp dbts;
...
rs.next();
// Suppose that the TSCOL column value is 2010-10-27-21.22.33.123456
ts=rs.getTimestamp(1);
//
//
ts.toString();
//
//
//
((DBTimestamp)ts).toDBString(false); //
//
//
//
//
((DBTimestamp)ts).toDBString(true);
//
//
//
//
//
//
//
ts=rs.getTimestamp(1,estcal);
//
//
//
//
ts.toString();
//
//
//
//
((DBTimestamp)ts).toDBString(false); //
//
//
//
//
((DBTimestamp)ts).toDBString(true);
//
//
//
//
//
//
//
ts=rs.getObject(1);
//
//
ts.toString();
//
//
//
((DBTimestamp)ts).toDBString(false); //
//
//
//
//
((DBTimestamp)ts).toDBString(true);
//
//
//
//
64
Application Programming Guide and Reference for Java
Retrieve the TIMESTAMP column value
into a Timestamp object.
Format the Timestamp object as a String.
2010-10-27-21:22:33.123456 is
returned.
Cast the retrieved object to a
DBTimestamp object, and format the
value as a String, without the time
zone information.
2010-10-27-21.22.33.123456 is returned.
Cast the retrieved object to a
DBTimestamp object, and format the value
as a String, with the time zone
information.
2009-02-27-21.22.33.123456-08:00 is
returned. The time zone is the default
time zone.
Retrieve the TIMESTAMP column value
into a Timestamp object. Specify a
calendar parameter that says that the
time zone is GMT-05:00.
Format the value as a String, using the
default time zone of GMT-08:00.
2010-10-27-18:22:33.123456 is
returned.
Cast the retrieved object to a
DBTimestamp object, and format the
value as a String, without the time zone
information.
2010-10-27-21.22.33.123456 is returned.
Cast the retrieved object to a
DBTimestamp object, and format the
value as a String, with the time zone
information.
2010-10-27-21.22.33.123456-05:00 is
returned. The time zone is the time zone
in the Calendar parameter.
Retrieve the TIMESTAMP column value
into an Object.
Format the Timestamp object as a String.
2010-10-27-21:22:33.123456 is
returned.
Cast the retrieved object to a
DBTimestamp object, and format the
value as a String, without the time
zone information.
2010-10-27-21.22.33.123456 is returned.
Cast the retrieved object to a
DBTimestamp object, and format the value
as a String, with the time zone
information.
// 2009-02-27-21.22.33.123456-08:00 is
// returned. The time zone is the default
// time zone.
Alternatively, you can use DB2ResultSet methods to retrieve the TIMESTAMP or
TIMESTAMP WITH TIME ZONE column values.
Example: Suppose that table TSTABLE is defined like this:
CREATE TABLE TSTABLE (
TSCOL TIMESTAMP,
TSTZCOL TIMESTAMP(12) WITH TIME ZONE)
Also suppose that the default time zone is GMT-08:00 (Pacific Standard Time). The
following code retrieves timestamp values from the TIMESTAMP and TIMESTAMP
WITH TIME ZONE columns.
...
java.util.TimeZone esttz = java.util.TimeZone.getTimeZone("EST");
java.util.Calendar estcal = java.util.Calendar.getInstance(esttz);
java.util.Calendar defcal = java.util.Calendar.getInstance();
Statement stmt = conn.createStatement ();
ResultSet rs = stmt.executeQuery("SELECT TSCOL, TSTZCOL FROM TSTABLE");
com.ibm.db2.jcc.DB2ResultSet dbrs = (com.ibm.db2.jcc.DB2ResultSet)rs;
Timestamp ts;
DBTimestamp dbts;
...
rs.next();
// Suppose that the TSTZCOL column value is 2010-10-28-00.22.33.123456-05:00, and
// the TSCOL column value is 2010-10-27-21.22.33.123456.
ts=dbrs.getDBTimestamp(1);
// Retrieve the TIMESTAMP column value into
// a Timestamp object.
ts.toString();
// Format the Timestamp object as a String.
// 2010-10-27-21:22:33.123456 is
// returned.
((DBTimestamp)ts).toDBString(false); // Format the value as a String, without
// the time zone information.
// 2010-10-27-21.22.33.123456 is returned.
((DBTimestamp)ts).toDBString(true);
// Format the value as a String, with the
// time zone information.
// 2009-02-27-21.22.33.123456-08:00 is
// returned. The time zone is the default
// time zone.
ts=dbrs.getDBTimestamp(2);
// Retrieve the TIMESTAMP WITH TIME ZONE
// column value into a Timestamp object.
ts.toString();
// Format the Timestamp object as a String.
// 2010-10-27-21:22:33.123456 is
// returned. The returned value differs
// from the original value because toString
// uses the default time zone in its
// calculations.
((DBTimestamp)ts).toDBString(false); // Format the value as a String, without
// the time zone information.
// 2010-10-28-00.22.33.123456 is returned.
((DBTimestamp)ts).toDBString(true);
// Format the value as a String, with the
// time zone information.
// 2010-10-28-00.22.33.123456-05:00 is
// returned. The time zone is the time zone
// from the retrieved column value.
dbts = (DBTimestamp)rs.getTimestamp(2);
// Retrieve the TIMESTAMP WITH TIME ZONE
// column value into a DBTimestamp object.
dbts.toString();
// Format the DBTimestamp object as a String.
// 2010-10-27-21:22:33.123456 is
// returned. The value is adjusted for the
// difference between the time zone in the
// column value and the default time zone.
Chapter 3. JDBC application programming
65
dbts.toDBString(false);
// Format the value as a String, without
// the time zone information. The value is
// adjusted for the difference between the
// time zone in the column value and the
// default time zone.
// 2010-10-27-21.22.33.123456 is returned.
dbts.toDBString(true);
// Format the value as a String, with the
// time zone information.
// 2009-02-27-21.22.33.123456-08:00 is
// returned. The time zone is the default
// time zone. The value is adjusted for
// the difference between the time zone in
// the column value and the default
// time zone.
dbts = (DBTimestamp)rs.getTimestamp(2, defcal);
// Retrieve the TIMESTAMP WITH TIME ZONE
// column value into a DBTimestamp object,
// using the default Calendar to construct
// the DBTimestamp object.
dbts.toString();
// Format the DBTimestamp object as a String.
// 2010-10-27-21:22:33.123456 is
// returned. The value is adjusted for
// the difference between the time zone in
// the column value and the time zone
// in the Calendar parameter.
dbts.toDBString(false);
// Format the value as a String, without
// the time zone information.
// 2010-10-27-21.22.33.123456 is returned.
// The value is adjusted for
// the difference between the time zone in
// the column value and the time zone
// in the Calendar parameter.
dbts.toDBString(true);
// Format the value as a String, with the
// time zone information.
// 2009-02-27-21.22.33.123456-08:00 is
// returned. The value is adjusted for
// the difference between the time zone in
// the column value and the time zone
// in the Calendar parameter.
dbts = (DBTimestamp)rs.getObject(2); // Retrieve the TIMESTAMP WITH TIME ZONE
// column value into an Object, and cast
// the object as a DBTimestamp object.
dbts.toString();
// Format the DBTimestamp object as a String.
// 2010-10-27-21:22:33.123456 is
// returned. The returned value differs from
// the original value because toString uses
// the default time zone in its calculations.
dbts.toDBString(false);
// Format the value as a String, without
// the time zone information.
// 2010-10-28-00.22.33.123456 is returned.
dbts.toDBString(true);
// Format the value as a String, with the
// time zone information.
// 2009-10-28-00.22.33.123456-05:00 is
// returned. The time zone is the time
// zone in the retrieved column value.
Recommendation: Use getObject or getDBTimestamp, followed by setObject or
setDBTimestamp when you need to preserve the original timestamp with time zone
information when you retrieve data from one table and insert it into another table.
66
Application Programming Guide and Reference for Java
Related reference
“Common IBM Data Server Driver for JDBC and SQLJ properties for DB2 servers”
on page 242
“DBTimestamp class” on page 433
Distinct types in JDBC applications
A distinct type is a user-defined data type that is internally represented as a
built-in SQL data type. You create a distinct type by executing the SQL statement
CREATE DISTINCT TYPE.
In a JDBC program, you can create a distinct type using the executeUpdate method
to execute the CREATE DISTINCT TYPE statement. You can also use
executeUpdate to create a table that includes a column of that type. When you
retrieve data from a column of that type, or update a column of that type, you use
Java identifiers with data types that correspond to the built-in types on which the
distinct types are based.
The following example creates a distinct type that is based on an INTEGER type,
creates a table with a column of that type, inserts a row into the table, and
retrieves the row from the table:
Connection con;
Statement stmt;
ResultSet rs;
String empNumVar;
int shoeSizeVar;
...
stmt = con.createStatement();
// Create a Statement object
stmt.executeUpdate(
"CREATE DISTINCT TYPE SHOESIZE AS INTEGER");
// Create distinct type
stmt.executeUpdate(
"CREATE TABLE EMP_SHOE (EMPNO CHAR(6), EMP_SHOE_SIZE SHOESIZE)");
// Create table with distinct type
stmt.executeUpdate("INSERT INTO EMP_SHOE " +
"VALUES (’000010’, 6)");
// Insert a row
rs=stmt.executeQuery("SELECT EMPNO, EMP_SHOE_SIZE FROM EMP_SHOE);
// Create ResultSet for query
while (rs.next()) {
empNumVar = rs.getString(1);
// Get employee number
shoeSizeVar = rs.getInt(2);
// Get shoe size (use int
// because underlying type
// of SHOESIZE is INTEGER)
System.out.println("Employee number = " + empNumVar +
" Shoe size = " + shoeSizeVar);
}
rs.close();
// Close ResultSet
stmt.close();
// Close Statement
Figure 16. Creating and using a distinct type
Chapter 3. JDBC application programming
67
Related reference
“Data types that map to database data types in Java applications” on page 211
CREATE TYPE (DB2 SQL)
Savepoints in JDBC applications
An SQL savepoint represents the state of data and schemas at a particular point in
time within a unit of work. You can use SQL statements to set a savepoint, release
a savepoint, and restore data and schemas to the state that the savepoint
represents.
The IBM Data Server Driver for JDBC and SQLJ supports the following methods
for using savepoints:
Connection.setSavepoint() or Connection.setSavepoint(String name)
Sets a savepoint. These methods return a Savepoint object that is used in later
releaseSavepoint or rollback operations.
When you execute either of these methods, DB2 executes the form of the
SAVEPOINT statement that includes ON ROLLBACK RETAIN CURSORS.
Connection.releaseSavepoint(Savepoint savepoint)
Releases the specified savepoint, and all subsequently established savepoints.
Connection.rollback(Savepoint savepoint)
Rolls back work to the specified savepoint.
DatabaseMetaData.supportsSavepoints()
Indicates whether a data source supports savepoints.
You can indicate whether savepoints are unique by calling the method
DB2Connection.setSavePointUniqueOption. If you call this method with a value of
true, the application cannot set more than one savepoint with the same name
within the same unit of recovery. If you call this method with a value of false (the
default), multiple savepoints with the same name can be created within the same
unit of recovery, but creation of a savepoint destroys a previously created
savepoint with the same name.
The following example demonstrates how to set a savepoint, roll back to the
savepoint, and release the savepoint.
68
Application Programming Guide and Reference for Java
Connection con;
Statement stmt;
ResultSet rs;
String empNumVar;
int shoeSizeVar;
...
con.setAutoCommit(false);
// set autocommit OFF
stmt = con.createStatement();
// Create a Statement object
...
// Perform some SQL
con.commit();
// Commit the transaction
stmt.executeUpdate("INSERT INTO EMP_SHOE " +
"VALUES (’000010’, 6)");
// Insert a row
((com.ibm.db2.jcc.DB2Connection)con).setSavePointUniqueOption(true);
// Indicate that savepoints
// are unique within a unit
// of recovery
Savepoint savept = con.setSavepoint("savepoint1");
// Create a savepoint
...
stmt.executeUpdate("INSERT INTO EMP_SHOE " +
"VALUES (’000020’, 10)");
// Insert another row
conn.rollback(savept);
// Roll back work to the point
// after the first insert
...
con.releaseSavepoint(savept);
// Release the savepoint
stmt.close();
// Close the Statement
conn.commit();
// Commit the transaction
Figure 17. Setting, rolling back to, and releasing a savepoint in a JDBC application
Related tasks
“Committing or rolling back JDBC transactions” on page 99
Related reference
“DB2Connection interface” on page 366
“Driver support for JDBC APIs” on page 283
“Data types that map to database data types in Java applications” on page 211
Retrieval of automatically generated keys in JDBC
applications
With the IBM Data Server Driver for JDBC and SQLJ, you can retrieve
automatically generated keys (also called auto-generated keys) from a table using
JDBC 3.0 methods.
An automatically generated key is any value that is generated by the data server,
instead of being specified by the user. One type of automatically generated key is
the contents of an identity column. An identity column is a table column that
provides a way for the data source to automatically generate a numeric value for
each row. You define an identity column in a CREATE TABLE or ALTER TABLE
statement by specifying the AS IDENTITY clause when you define a column that
has an exact numeric type with a scale of 0 (SMALLINT, INTEGER, BIGINT,
DECIMAL with a scale of zero, or a distinct type based on one of these types).
For connections to DB2 for z/OS or DB2 Database for Linux, UNIX, and Windows,
the IBM Data Server Driver for JDBC and SQLJ supports the return of
automatically generated keys for INSERT statements, for searched UPDATE or
searched DELETE statements, or for MERGE statements. For UPDATE, DELETE, or
MERGE statements, you can identify any columns as automatically generated keys,
Chapter 3. JDBC application programming
69
even if they are not generated by the data server. In this case, the column values
that are returned are the column values for the rows that are modified by the
UPDATE, DELETE, or MERGE statement.
Restriction: If the Connection or DataSource property atomicMultiRowInsert is set
to DB2BaseDataSource.YES (1), you cannot prepare an SQL statement for retrieval of
automatically generated keys and use the PreparedStatement object for batch
updates. The IBM Data Server Driver for JDBC and SQLJ version 3.50 or later
throws an SQLException when you call the addBatch or executeBatch method on a
PreparedStatement object that is prepared to return automatically generated keys.
Related tasks
“Updating data in tables using the PreparedStatement.executeUpdate method” on
page 26
“Creating and modifying database objects using the Statement.executeUpdate
method” on page 25
Retrieving auto-generated keys for an INSERT statement
With the IBM Data Server Driver for JDBC and SQLJ, you can use JDBC 3.0
methods to retrieve the keys that are automatically generated when you execute an
INSERT statement.
To retrieve automatically generated keys that are generated by an INSERT
statement, you need to perform these steps.
1. Use one of the following methods to indicate that you want to return
automatically generated keys:
v If you plan to use the PreparedStatement.executeUpdate method to insert
rows, invoke one of these forms of the Connection.prepareStatement method
to create a PreparedStatement object:
The following form is valid for a table on any data source that supports
identity columns.
Restriction: For IBM Data Server Driver for JDBC and SQLJ version 3.57 or
later, the following form is not valid for inserting rows into a view on a DB2
for z/OS data server.
Connection.prepareStatement(sql-statement,
Statement.RETURN_GENERATED_KEYS);
If the data server is DB2 for z/OS, the following forms are valid only if the
data server supports SELECT FROM INSERT statements. With the first form,
you specify the names of the columns for which you want automatically
generated keys. With the second form, you specify the positions in the table
of the columns for which you want automatically generated keys.
Connection.prepareStatement(sql-statement, String [] columnNames);
Connection.prepareStatement(sql-statement, int [] columnIndexes);
v If you use the Statement.executeUpdate method to insert rows, invoke one
of these forms of the Statement.executeUpdate method:
The following form is valid for a table on any data source that supports
identity columns.
Restriction: For IBM Data Server Driver for JDBC and SQLJ version 3.57 or
later, the following form is not valid for inserting rows into a view on a DB2
for z/OS data server.
Statement.executeUpdate(sql-statement, Statement.RETURN_GENERATED_KEYS);
70
Application Programming Guide and Reference for Java
If the data server is DB2 for z/OS, the following forms are valid only if the
data server supports SELECT FROM INSERT statements. With the first form,
you specify the names of the columns for which you want automatically
generated keys. With the second form, you specify the positions in the table
of the columns for which you want automatically generated keys.
Statement.executeUpdate(sql-statement, String [] columnNames);
Statement.executeUpdate(sql-statement, int [] columnIndexes);
2. Invoke the PreparedStatement.getGeneratedKeys method or the
Statement.getGeneratedKeys method to retrieve a ResultSet object that
contains the automatically generated key values.
If you include the Statement.RETURN_GENERATED_KEYS parameter, the data type
of the automatically generated keys in the ResultSet is DECIMAL, regardless
of the data type of the corresponding column.
The following code creates a table with an identity column, inserts a row into the
table, and retrieves the automatically generated key value for the identity column.
The numbers to the right of selected statements correspond to the previously
described steps.
import java.sql.*;
import java.math.*;
import com.ibm.db2.jcc.*;
Connection con;
Statement stmt;
ResultSet rs;
java.math.BigDecimal iDColVar;
...
stmt = con.createStatement();
// Create a Statement object
stmt.executeUpdate(
"CREATE TABLE EMP_PHONE (EMPNO CHAR(6), PHONENO CHAR(4), " +
"IDENTCOL INTEGER GENERATED ALWAYS AS IDENTITY)");
// Create table with identity column
stmt.executeUpdate("INSERT INTO EMP_PHONE (EMPNO, PHONENO) " +
1
"VALUES (’000010’, ’5555’)",
// Insert a row
Statement.RETURN_GENERATED_KEYS);
// Indicate you want automatically
// generated keys
rs = stmt.getGeneratedKeys();
// Retrieve the automatically
2
// generated key value in a ResultSet.
// Only one row is returned.
// Create ResultSet for query
while (rs.next()) {
java.math.BigDecimal idColVar = rs.getBigDecimal(1);
// Get automatically generated key
// value
System.out.println("automatically generated key value = " + idColVar);
}
rs.close();
// Close ResultSet
stmt.close();
// Close Statement
With any version of the IBM Data Server Driver for JDBC and SQLJ, you can
retrieve the most recently assigned value of an identity column by explicitly
executing the IDENTITY_VAL_LOCAL built-in function. Execute code similar to
this:
String idntVal;
Connection con;
Statement stmt;
ResultSet rs;
...
stmt = con.createStatement();
// Create a Statement object
rs = stmt.executeQuery("SELECT IDENTITY_VAL_LOCAL() FROM SYSIBM.SYSDUMMY1");
Chapter 3. JDBC application programming
71
//
//
//
while (rs.next()) {
//
idntVal = rs.getString(1);
//
System.out.println("Identity column
//
}
rs.close();
//
stmt.close();
//
Get the result table from the query.
This is a single row with the most
recent identity column value.
Position the cursor
Retrieve column value
value = " + idntVal);
Print the column value
Close the ResultSet
Close the Statement
Retrieving auto-generated keys for an UPDATE, DELETE, or
MERGE statement
With the IBM Data Server Driver for JDBC and SQLJ, you can use JDBC 3.0
methods to retrieve the keys that are automatically generated when you execute a
searched UPDATE, searched DELETE, or MERGE statement.
To retrieve automatically generated keys that are generated by an UPDATE,
DELETE, or MERGE statement, you need to perform these steps.
1. Construct a String array that contains the names of the columns from which
you want to return automatically generated keys.
The array must be an array of column names, and not column indexes.
2. Set the autocommit mode for the connection to false.
3. Use one of the following methods to indicate that you want to return
automatically generated keys:
v If you plan to use the PreparedStatement.executeUpdate method to update,
delete, or merge rows, invoke this form of the Connection.prepareStatement
method to create a PreparedStatement object:
Connection.prepareStatement(sql-statement, String [] columnNames);
v If you use the Statement.executeUpdate method to update, delete, or merge
rows, invoke this form of the Statement.executeUpdate method:
Statement.executeUpdate(sql-statement, String [] columnNames);
4. Invoke the PreparedStatement.getGeneratedKeys method or the
Statement.getGeneratedKeys method to retrieve a ResultSet object that
contains the automatically generated key values.
Suppose that a table is defined like this and has thirty rows:
CREATE TABLE EMP_BONUS
(EMPNO CHAR(6),
BONUS DECIMAL(9,2))
The following code names the EMPNO column as an automatically generated key,
updates the thirty rows in the EMP_BONUS table, and retrieves the values of
EMPNO for the updated rows. The numbers to the right of selected statements
correspond to the previously described steps.
import java.sql.*;
...
Connection conn;
...
String[] agkNames = {"EMPNO"};
1
int updateCount = 0;
conn.setAutoCommit(false);
2
PreparedStatement ps =
3
conn.prepareStatement(“UPDATE EMP_BONUS SET BONUS = " +
“ BONUS + 300.00”,agkNames);
updateCount = ps.executeUpdate();
ResultSet rs = ps.getGeneratedKeys();
4
while (rs.next()) {
72
Application Programming Guide and Reference for Java
String agkEmpNo = rs.getString(1);
// Get automatically generated key value
System.out.println("Automatically generated key value = " + agkEmpNo);
}
ps.close();
conn.close();
Using named parameter markers in JDBC applications
You can use named parameter markers instead of standard parameter markers in
PreparedStatement and CallableStatement objects to assign values to the input
parameter markers. You can also use named parameter markers instead of
standard parameter markers in CallableStatement objects to register OUT
parameters that have named parameter markers.
SQL strings that contain the following SQL elements can include named parameter
markers:
v CALL
v DELETE
v INSERT
v MERGE
v PL/SQL block
v SELECT
v SET
v UPDATE
Named parameter markers make your JDBC applications more readable. If you
have named parameter markers in an application, set the IBM Data Server Driver
for JDBC and SQLJ Connection or DataSource property
enableNamedParameterMarkers to DB2BaseDataSource.YES (1) to direct the driver
to accept named parameter markers and send them to the data source as standard
parameter markers.
Related reference
“Common IBM Data Server Driver for JDBC and SQLJ properties for all supported
database products” on page 222
Using named parameter markers with PreparedStatement objects
You can use named parameter markers instead of standard parameter markers in
PreparedStatement objects to assign values to the parameter markers.
To ensure that applications with named parameters work correctly, regardless of
the data server type and version, before you use named parameter markers in your
applications, set the Connection or DataSource property
enableNamedParameterMarkers to DB2BaseDataSource.YES.
To use named parameter markers with PreparedStatement objects, follow these
steps.
1. Execute the Connection.prepareStatement method on an SQL statement string
that contains named parameter markers. The named parameter markers must
follow the rules for SQL host variable names.
You cannot mix named parameter markers and standard parameter markers in
the same SQL statement string.
Named parameter markers are case-insensitive.
2. For each named parameter marker, use a
DB2PreparedStatement.setJccXXXAtName method to assign a value to each
named input parameter.
Chapter 3. JDBC application programming
73
If you use the same named parameter marker more than once in the same SQL
statement string, you need to call a setJccXXXAtName method for that parameter
marker only once.
Recommendation: Do not use the same named parameter marker more than
once in the same SQL statement string if the input to that parameter marker is
a stream. Doing so can cause unexpected results.
Restriction: You cannot use standard JDBC PreparedStatement.setXXX methods
with named parameter markers. Doing so causes an exception to be thrown.
3. Execute the PreparedStatement.
The following code uses named parameter markers to update the phone number to
'4657' for the employee with employee number '000010'. The numbers to the right
of selected statements correspond to the previously described steps.
Connection con;
PreparedStatement pstmt;
int numUpd;
...
pstmt = con.prepareStatement(
"UPDATE EMPLOYEE SET PHONENO=:phonenum WHERE EMPNO=:empnum");
// Create a PreparedStatement object
1
((com.ibm.db2.jcc.DB2PreparedStatement)pstmt).setJccStringAtName
("phonenum", "4567");
// Assign a value to phonenum parameter 2
((com.ibm.db2.jcc.DB2PreparedStatement)pstmt).setJccStringAtName
("empnum", "000010");
// Assign a value to empnum parameter
numUpd = pstmt.executeUpdate();
// Perform the update
3
pstmt.close();
// Close the PreparedStatement object
The following code uses named parameter markers to update values in a PL/SQL
block. The numbers to the right of selected statements correspond to the previously
described steps.
Connection con;
PreparedStatement pstmt;
int numUpd;
...
String sql =
"BEGIN " +
" UPDATE EMPLOYEE SET PHONENO = :phonenum WHERE EMPNO = :empnum; " +
"END;";
pstmt = con.prepareStatement(sql); // Create a PreparedStatement object
1
((com.ibm.db2.jcc.DB2PreparedStatement)pstmt).setJccStringAtName
("phonenum", "4567");
// Assign a value to phonenum parameter 2
((com.ibm.db2.jcc.DB2PreparedStatement)pstmt).setJccStringAtName
("empnum", "000010");
// Assign a value to empnum parameter
numUpd = pstmt.executeUpdate();
// Perform the update
3
pstmt.close();
// Close the PreparedStatement object
Related reference
“DB2PreparedStatement interface” on page 397
Using named parameter markers with CallableStatement objects
You can use named parameter markers instead of standard parameter markers in
CallableStatement objects to assign values to IN or INOUT parameters and to
register OUT parameters.
74
Application Programming Guide and Reference for Java
To ensure that applications with named parameters work correctly, regardless of
the data server type and version, before you use named parameter markers in your
applications, set the Connection or DataSource property
enableNamedParameterMarkers to DB2BaseDataSource.YES.
To use named parameter markers with CallableStatement objects, follow these
steps.
1. Execute the Connection.prepareCall method on an SQL statement string that
contains named parameter markers.
The named parameter markers must follow the rules for SQL host variable
names.
You cannot mix named parameter markers and standard parameter markers in
the same SQL statement string.
Named parameter markers are case-insensitive.
2. If you do not know the names of the named parameter markers in the CALL
statement, or the mode of the parameters (IN, OUT, or INOUT):
a. Call the CallableStatement.getParameterMetaData method to obtain a
ParameterMetaData object with information about the parameters.
b. Call the ParameterMetaData.getParameterMode method to retrieve the
parameter mode.
c. Cast the ParameterMetaData object to a DB2ParameterMetaData object.
d. Call the DB2ParameterMetaData.getParameterMarkerNames method to retrieve
the parameter names.
3. For each named parameter marker that represents an OUT parameter, use a
DB2CallableStatement.registerJccOutParameterAtName method to register the
OUT parameter with a data type.
If you use the same named parameter marker more than once in the same SQL
statement string, you need to call a registerJccOutParameterAtName method for
that parameter marker only once. All parameters with the same name are
registered as the same data type.
Restriction: You cannot use standard JDBC
CallableStatement.registerOutParameter methods with named parameter
markers. Doing so causes an exception to be thrown.
4. For each named parameter marker for an input parameter, use a
DB2CallableStatement.setJccXXXAtName method to assign a value to each
named input parameter.
setJccXXXAtName methods are inherited from DB2PreparedStatement.
If you use the same named parameter marker more than once in the same SQL
statement string, you need to call a setJccXXXAtName method for that parameter
marker only once.
Recommendation: Do not use the same named parameter marker more than
once in the same SQL statement string if the input to that parameter marker is
a stream. Doing so can cause unexpected results.
5. Execute the CallableStatement.
6. Call CallableStatement.getXXX methods or
DB2CallableStatement.getJccXXXAtName methods to retrieve output parameter
values.
The following code illustrates calling a stored procedure that has one input
VARCHAR parameter and one output INTEGER parameter, which are represented
Chapter 3. JDBC application programming
75
by named parameter markers. The numbers to the right of selected statements
correspond to the previously described steps.
...
CallableStatement cstmt =
con.prepareCall("CALL MYSP(:inparm,:outparm)");
// Create a CallableStatement object 1
((com.ibm.db2.jcc.DB2CallableStatement)cstmt).
registerJccOutParameterAtName("outparm", java.sql.Types.INTEGER);
// Register OUT parameter data type 3
((com.ibm.db2.jcc.DB2CallableStatement)cstmt).setJccStringAtName("inparm", "4567");
// Assign a value to inparm parameter
4
cstmt.executeUpdate();
int outssid = cstmt.getInt(2);
cstmt.close();
// Call the stored procedure
// Get the output parameter value
5
6
Related reference
“DB2CallableStatement interface” on page 358
“DB2PreparedStatement interface” on page 397
Providing extended client information to the data source with
IBM Data Server Driver for JDBC and SQLJ-only methods
A set of IBM Data Server Driver for JDBC and SQLJ-only methods provide extra
information about the client to the server. This information can be used for
accounting, workload management, or debugging.
Extended client information is sent to the database server when the application
performs an action that accesses the server, such as executing SQL.
In the IBM Data Server Driver for JDBC and SQLJ version 4.0 or later, the IBM
Data Server Driver for JDBC and SQLJ-only methods are deprecated. You should
use java.sql.Connection.setClientInfo instead.
The IBM Data Server Driver for JDBC and SQLJ-only methods are listed in the
following table.
Table 14. Methods that provide client information to theDB2 server
Method
Information provided
setDB2ClientAccountingInformation
Accounting information
setDB2ClientApplicationInformation
Name of the application that is working with
a connection
setDB2ClientDebugInfo
The CLIENT DEBUGINFO connection
attribute for the Unified debugger
setDB2ClientProgramId
A caller-specified string that helps the caller
identify which program is associated with a
particular SQL statement.
setDB2ClientProgramId does not apply to DB2
Database for Linux, UNIX, and Windows data
servers.
setDB2ClientUser
User name for a connection
setDB2ClientWorkstation
Client workstation name for a connection
To set the extended client information, follow these steps:
1. Create a Connection.
76
Application Programming Guide and Reference for Java
2. Cast the java.sql.Connection object to a com.ibm.db2.jcc.DB2Connection.
3. Call any of the methods shown in Table 14 on page 76.
4. Execute an SQL statement to cause the information to be sent to theDB2 server.
The following code performs the previous steps to pass a user name and a
workstation name to theDB2 server. The numbers to the right of selected
statements correspond to the previously-described steps.
public class ClientInfoTest {
public static void main(String[] args) {
String url = "jdbc:db2://sysmvs1.stl.ibm.com:5021/san_jose";
try {
Class.forName("com.ibm.db2.jcc.DB2Driver");
String user = "db2adm";
String password = "db2adm";
Connection conn = DriverManager.getConnection(url,
1
user, password);
if (conn instanceof DB2Connection) {
DB2Connection db2conn = (DB2Connection) conn;
2
db2conn.setDB2ClientUser("Michael L Thompson");
3
db2conn.setDB2ClientWorkstation("sjwkstn1");
// Execute SQL to force extended client information to be sent
// to the server
conn.prepareStatement("SELECT * FROM SYSIBM.SYSDUMMY1"
+ "WHERE 0 = 1").executeQuery();
4
}
} catch (Throwable e) {
e.printStackTrace();
}
}
}
Figure 18. Example of passing extended client information to aDB2 server
Related reference
“IBM Data Server Driver for JDBC and SQLJ extensions to JDBC” on page 347
Providing extended client information to the data source with
client info properties
The IBM Data Server Driver for JDBC and SQLJ version 4.0 supports JDBC 4.0
client info properties, which you can use to provide extra information about the
client to the server. This information can be used for accounting, workload
management, or debugging.
Extended client information is sent to the database server when the application
performs an action that accesses the server, such as executing SQL.
The application can also use the Connection.getClientInfo method to retrieve
client information from the database server, or execute the
DatabaseMetaData.getClientInfoProperties method to determine which client
information the driver supports.
The JDBC 4.0 client info properties should be used instead IBM Data Server Driver
for JDBC and SQLJ-only methods, which are deprecated.
To set client info properties, follow these steps:
1. Create a Connection.
Chapter 3. JDBC application programming
77
2. Call the java.sql.Connection.setClientInfo method to set any of the client
info properties that the database server supports.
3. Execute an SQL statement to cause the information to be sent to the database
server.
The following code performs the previous steps to pass a client's user name and
host name to theDB2 server. The numbers to the right of selected statements
correspond to the previously-described steps.
public class ClientInfoTest {
public static void main(String[] args) {
String url = "jdbc:db2://sysmvs1.stl.ibm.com:5021/san_jose";
try {
Class.forName("com.ibm.db2.jcc.DB2Driver");
String user = "db2adm";
String password = "db2adm";
Connection conn = DriverManager.getConnection(url,
1
user, password);
conn.setClientInfo("ClientUser", "Michael L Thompson"); 2
conn.setClientInfo("ClientHostname, "sjwkstn1");
// Execute SQL to force extended client information to be sent
// to the server
conn.prepareStatement("SELECT * FROM SYSIBM.SYSDUMMY1"
+ "WHERE 0 = 1").executeQuery();
3
} catch (Throwable e) {
e.printStackTrace();
}
}
}
Figure 19. Example of passing extended client information to aDB2 server
Client info properties support by the IBM Data Server Driver for
JDBC and SQLJ
JDBC 4.0 includes client info properties, which contain information about a
connection to a data source. The DatabaseMetaData.getClientInfoProperties
method returns a list of client info properties that the IBM Data Server Driver for
JDBC and SQLJ supports.
When you call DatabaseMetaData.getClientInfoProperties, a result set is returned
that contains the following columns:
v NAME
v MAX_LEN
v DEFAULT_VALUE
v DESCRIPTION
The following table lists the client info property values that the IBM Data Server
Driver for JDBC and SQLJ returns for DB2 Database for Linux, UNIX, and
Windows and for DB2 for i.
Table 15. Client info property values for DB2 Database for Linux, UNIX, and Windows and for DB2 for i
NAME
MAX_LEN
(bytes)
DEFAULT_VALUE
DESCRIPTION
ApplicationName
255
Empty string
The name of the application
that is currently using the
connection. This value is stored
in DB2 special register
CURRENT
CLIENT_APPLNAME.
78
Application Programming Guide and Reference for Java
Table 15. Client info property values for DB2 Database for Linux, UNIX, and Windows and for DB2 for i (continued)
NAME
MAX_LEN
(bytes)
DEFAULT_VALUE
DESCRIPTION
ClientAccountingInformation
255
Empty string
The value of the accounting
string from the client
information that is specified for
the connection. This value is
stored in DB2 special register
CURRENT CLIENT_ACCTNG.
ClientHostname
255
The value that is set by
DB2Connection.setDB2ClientWorkstation. If
the value is not set, the default is the host
name of the local host.
The host name of the computer
on which the application that is
using the connection is running.
This value is stored in DB2
special register CURRENT
CLIENT_WRKSTNNAME.
ClientUser
255
Empty string
The name of the user on whose
behalf the application that is
using the connection is running.
This value is stored in DB2
special register CURRENT
CLIENT_USERID.
The following table lists the client info property values that the IBM Data Server
Driver for JDBC and SQLJ returns for DB2 for z/OS when the connection uses
type 4 connectivity.
Table 16. Client info property values for type 4 connectivity to DB2 for z/OS
NAME
MAX_LEN
(bytes)
ApplicationName
DEFAULT_VALUE
DESCRIPTION
32
clientProgramName property value, if set.
"db2jcc_application" otherwise.
The name of the application that is
currently using the connection. This
value is stored in DB2 special
register CURRENT
CLIENT_APPLNAME.
ClientAccountingInformation
200
A string that is the concatenation of the
following values:
v "JCCnnnnn", where nnnnn is the driver
level, such as 04000.
v The value that is set by
DB2Connection.setDB2ClientWorkstation.
If the value is not set, the default is the
host name of the local host.
v applicationName property value, if set. 20
blanks otherwise.
v clientUser property value, if set. Eight
blanks otherwise.
The value of the accounting string
from the client information that is
specified for the connection. This
value is stored in DB2 special
register CURRENT
CLIENT_ACCTNG.
ClientHostname
18
The value that is set by
DB2Connection.setDB2ClientWorkstation. If
the value is not set, the default is the host
name of the local host.
The host name of the computer on
which the application that is using
the connection is running. This
value is stored in DB2 special
register CURRENT
CLIENT_WRKSTNNAME.
ClientUser
16
The value that is set by
DB2Connection.setDB2ClientUser. If the
value is not set, the default is the current
user ID that is used to connect to the
database.
The name of the user on whose
behalf the application that is using
the connection is running. This
value is stored in DB2 special
register CURRENT
CLIENT_USERID.
Chapter 3. JDBC application programming
79
The following table lists the client info property values that the IBM Data Server
Driver for JDBC and SQLJ returns for DB2 for z/OS when the connection uses
type 2 connectivity.
Table 17. Client info property values for type 2 connectivity to DB2 for z/OS
NAME
MAX_LEN
(bytes)
DEFAULT_VALUE
DESCRIPTION
ApplicationName
32
Empty string
The name of the application that is currently
using the connection. This value is stored in
DB2 special register CURRENT
CLIENT_APPLNAME.
ClientAccountingInformation
200
Empty string
The value of the accounting string from the
client information that is specified for the
connection. This value is stored in DB2
special register CURRENT
CLIENT_ACCTNG.
ClientHostname
18
Empty string
The host name of the computer on which
the application that is using the connection
is running. This value is stored in DB2
special register CURRENT
CLIENT_WRKSTNNAME.
ClientUser
16
Empty string
The name of the user on whose behalf the
application that is using the connection is
running. This value is stored in DB2 special
register CURRENT CLIENT_USERID.
The following table lists the client info property values that the IBM Data Server
Driver for JDBC and SQLJ returns for IBM Informix
Table 18. Client info property values for IBM Informix
NAME
MAX_LEN
(bytes)
DEFAULT_VALUE
DESCRIPTION
ApplicationName
20
Empty string
The name of the application
that is currently using the
connection.
ClientAccountingInformation
199
Empty string
The value of the accounting
string from the client
information that is specified for
the connection.
ClientHostname
20
The value that is set by
DB2Connection.setDB2ClientWorkstation. If
the value is not set, the default is the host
name of the local host.
The host name of the computer
on which the application that is
using the connection is
running.
ClientUser
1024
Empty string
The name of the user on whose
behalf the application that is
using the connection is
running.
Extended parameter information with the IBM Data Server Driver for
JDBC and SQLJ
IBM Data Server Driver for JDBC and SQLJ-only methods and constants let you
assign the default value or no value to table columns or ResultSet columns.
The data server must support extended indicators before you can use the methods
that provide extended indicator information in your Java applications. If you call
one of those methods against a data server that does not support extended
80
Application Programming Guide and Reference for Java
indicators, an exception is thrown. Extended parameter information is supported
by DB2 for z/OS Version 10 or later, or DB2 Database for Linux, UNIX, and
Windows Version 9.7 or later.
The methods that provide extended parameter information are listed in the
following table.
Extended parameter information methods
Purpose
DB2PreparedStatement.setDBDefault,
DB2PreparedStatement.setJccDBDefaultAtName
Sets an input parameter to its default value.
DB2PreparedStatement.setDBUnassigned,
DB2PreparedStatement.setJccDBUnassignedAtName
Indicates that an input parameter is unassigned. This
action yields the same behavior that would occur if the
input parameter did not appear in the SQL statement
text.
DB2ResultSet.updateDBDefault
Sets a column value in the current ResultSet row to its
default value.
These methods are applicable only for parameter markers that appear in one of the
following places:
v The SET list of an UPDATE statement
v The SET list of a MERGE statement
v The VALUES list of an INSERT statement
v The VALUES list of a MERGE statement
v The source table in a MERGE statement
v The SELECT list of an INSERT from SELECT statement
An SQLException is raised if you use these methods in any other context.
Alternatively, you can use the standard PreparedStatement.setObject or
ResultSet.updateObject methods with IBM Data Server Driver for JDBC and
SQLJ-only constants DB2PreparedStatement.DB_PARAMETER_DEFAULT or
DB2PreparedStatement.DB_PARAMETER_UNASSIGNED to assign the default value or no
value to parameters.
Extended parameter information can simplify application programs that have
several input variables, each of which can send a value or the default value to the
data server, or does not need to appear in the SQL statement. Instead of preparing
separate statement strings for all combinations of variable values, you can prepare
a single statement string. The resulting PreparedStatement object can be used in a
homogeneous batch, whereas multiple different PreparedStatement objects cannot
be used in a homogeneous batch.
Related reference
“DB2PreparedStatement interface” on page 397
Using DB2PreparedStatement methods or constants to
provide extended parameter information
Use DB2PreparedStatement methods or PreparedStatement methods with
DB2PreparedStatement constants to assign default values to target columns or to
assign no values to target columns.
Follow these steps to send extended client information for a PreparedStatement to
the data server.
Chapter 3. JDBC application programming
81
1. Create a PreparedStatement object.
The SQL statement is a INSERT, UPDATE, or MERGE statement.
2. If you are not using setObject to assign the values, cast the PreparedStatement
object to a com.ibm.db2.jcc.DB2PreparedStatement object.
3. Call one of the following methods:
v If you are not using setObject to assign the value:
– To assign the default value of the target column to the input parameter,
call DB2PreparedStatement.setDBDefault or
DB2PreparedStatement.setJccDBDefaultAtName.
– To mark the input parameter as unassigned, call
DB2PreparedStatement.setDBUnassigned or
DB2PreparedStatement.setJccDBUnassignedAtName.
v If you are using setObject to assign the value:
– To assign the default value of the target column to the input parameter,
call PreparedStatement.setObject with
DB2PreparedStatement.DB_PARAMETER_DEFAULT as the assigned value.
– To mark the input parameter as unassigned, call
PreparedStatement.setObject with
DB2PreparedStatement.DB_PARAMETER_UNASSIGNED as the assigned value.
4. Execute the SQL statement.
The following code assigns the default values of the target columns to the third
and fifth parameters in an INSERT statement. The numbers to the right of selected
statements correspond to the previously described steps.
import java.sql.*;
import com.ibm.db2.jcc.*;
Connection conn;
...
PreparedStatement p = conn.prepareStatement(
1
"INSERT INTO DEPARTMENT " +
"(DEPTNO, DEPTNAME, MGRNO, ADMRDEPT, LOCATION) " +
"VALUES (?,?,?,?,?)");
p.setString(1, "X00");
p.setString(2, "FACILITIES");
p.setString(4, "A00");
((com.ibm.db2.jcc.DB2PreparedStatement)p).setDBDefault(3);
2,3
((com.ibm.db2.jcc.DB2PreparedStatement)p).setDBDefault(5);
int uCount = p.executeUpdate();
4
...
p.close();
// Close PreparedStatement
The following code uses the PreparedStatement.setObject method and
DB2PreparedStatement constants to perform the same function as in the previous
example. The numbers to the right of selected statements correspond to the
previously described steps.
import java.sql.*;
import com.ibm.db2.jcc.*;
Connection conn;
...
PreparedStatement p = conn.prepareStatement(
"INSERT INTO DEPARTMENT " +
"(DEPTNO, DEPTNAME, MGRNO, ADMRDEPT, LOCATION) " +
"VALUES (?,?,?,?,?)");
p.setString(1, "X00");
p.setString(2, "FACILITIES");
82
Application Programming Guide and Reference for Java
1
p.setString(4, "A00");
p.setObject(3, DB2PreparedStatement.DB_PARAMETER_DEFAULT);
3
p.setObject(5, DB2PreparedStatement.DB_PARAMETER_DEFAULT);
int uCount = p.executeUpdate();
4
...
p.close();
// Close PreparedStatement
In these examples, use of the method DB2PreparedStatement.setDBDefault or the
constant DB2PreparedStatement.DB_PARAMETER_DEFAULT simplifies programming of
the INSERT operation. If DB2PreparedStatement.setDBDefault or
DB2PreparedStatement.DB_PARAMETER_DEFAULT is not used, up to 32 different
PreparedStatement objects are necessary to cover all combinations of default and
non-default input values.
Using DB2ResultSet methods or DB2PreparedStatement
constants to provide extended parameter information
Use DB2ResultSet methods or ResultSet methods with DB2PreparedStatement
constants to assign default values to target columns in a DB2ResultSet.
Follow these steps to update a ResultSet with extended client information.
1. Create a PreparedStatement object.
2.
3.
4.
5.
The SQL statement is a SELECT statement.
Invoke PreparedStatement.setXXX methods to pass values to any input
parameters.
Invoke the PreparedStatement.executeQuery method to obtain the result table
from the SELECT statement in a ResultSet object.
Position the cursor to the row that you want to update or insert.
Update columns in the ResultSet row.
v If you are not using updateObject to update a value:
– To assign the default value to the target column of the ResultSet, cast the
ResultSet to a DB2ResultSet, and call DB2ResultSet.updateDBDefault.
v If you are using updateObject to assign the value:
– To assign the default value to the target column of the ResultSet, call
ResultSet.updateObject with
DB2PreparedStatement.DB_PARAMETER_DEFAULT as the assigned value.
6. Execute ResultSet.updateRow if you are updating an existing row, or
ResultSet.insertRow if you are inserting a new row.
The following code inserts a row into a ResultSet with the default value in the
second column, and does not modify the value in the first column. The numbers to
the right of selected statements correspond to the previously described steps.
import java.sql.*;
import com.ibm.db2.jcc.*;
Connection conn;
...
PreparedStatement p = conn.prepareStatement (
"SELECT MGRNO, LOCATION " +
"FROM DEPARTMENT");
ResultSet rs = p.executeQuery ();
rs.next ();
rs.moveToInsertRow();
((DB2ResultSet)rs).updateDBDefault (2);
rs.insertRow();
1
3
4
5
6
Chapter 3. JDBC application programming
83
...
rs.close();
p.close();
// Close ResultSet
// Close PreparedStatement
The following code uses the ResultSet interface with DB2PreparedStatement
constants to perform the same function as in the previous example. The numbers
to the right of selected statements correspond to the previously described steps.
import java.sql.*;
import com.ibm.db2.jcc.*;
Connection conn;
...
PreparedStatement p = conn.prepareStatement (
1
"SELECT MGRNO, LOCATION " +
"FROM DEPARTMENT");
ResultSet rs = p.executeQuery ();
3
rs.next ();
rs.moveToInsertRow();
4
rs.updateObject (2,
5
DB2PreparedStatement.DB_PARAMETER_DEFAULT);
rs.insertRow();
6
...
rs.close();
// Close ResultSet
p.close();
// Close PreparedStatement
XML data in JDBC applications
In JDBC applications, you can store data in XML columns and retrieve data from
XML columns.
In database tables, the XML built-in data type is used to store XML data in a
column as a structured set of nodes in a tree format.
JDBC applications can send XML data to the data server or retrieve XML data from
the data server in one of the following forms:
v As textual XML data
v As binary XML data, if the data server supports it
In JDBC applications, you can:
v Store an entire XML document in an XML column using setXXX methods.
v Retrieve an entire XML document from an XML column using getXXX methods.
v Retrieve a sequence from a document in an XML column by using the SQL
XMLQUERY function to retrieve the sequence into a serialized sequence in the
database, and then using getXXX methods to retrieve the data into an application
variable.
v Retrieve a sequence from a document in an XML column as a user-defined table
by using the SQL XMLTABLE function to define the result table and retrieve it.
Then use getXXX methods to retrieve the data from the result table into
application variables.
JDBC 4.0 java.sql.SQLXML objects can be used to retrieve and update data in XML
columns. Invocations of metadata methods, such as
ResultSetMetaData.getColumnTypeName return the integer value
java.sql.Types.SQLXML for an XML column type.
84
Application Programming Guide and Reference for Java
Related concepts
“XML column updates in JDBC applications”
“XML data retrieval in JDBC applications” on page 87
Related reference
“Data types that map to database data types in Java applications” on page 211
XML column updates in JDBC applications
In a JDBC application, you can update or insert data into XML columns of a table
at a DB2 data server using XML textual data. You can update or insert data into
XML columns of a table using binary XML data (data that is in the Extensible
Dynamic Binary XML DB2 Client/Server Binary XML Format), if the data server
supports binary XML data.
The following table lists the methods and corresponding input data types that you
can use to put data in XML columns.
Table 19. Methods and data types for updating XML columns
Method
Input data type
PreparedStatement.setAsciiStream
InputStream
PreparedStatement.setBinaryStream
InputStream
PreparedStatement.setBlob
Blob
PreparedStatement.setBytes
byte[]
PreparedStatement.setCharacterStream
Reader
PreparedStatement.setClob
Clob
PreparedStatement.setObject
byte[], Blob, Clob, SQLXML, DB2Xml (deprecated), InputStream,
Reader, String
PreparedStatement.setSQLXML1
SQLXML
PreparedStatement.setString
String
Note:
1. This method requires JDBC 4.0 or later.
The encoding of XML data can be derived from the data itself, which is known as
internally encoded data, or from external sources, which is known as externally
encoded data. XML data that is sent to the database server as binary data is treated
as internally encoded data. XML data that is sent to the data source as character
data is treated as externally encoded data.
External encoding for Java applications is always Unicode encoding.
Externally encoded data can have internal encoding. That is, the data might be sent
to the data source as character data, but the data contains encoding information.
The data source handles incompatibilities between internal and external encoding
as follows:
v If the data source is DB2 Database for Linux, UNIX, and Windows, the database
source generates an error if the external and internal encoding are incompatible,
unless the external and internal encoding are Unicode. If the external and
internal encoding are Unicode, the database source ignores the internal
encoding.
v If the database source is DB2 for z/OS, the database source ignores the internal
encoding.
Chapter 3. JDBC application programming
85
Character data in XML columns is stored in UTF-8 encoding. The database source
handles conversion of the data from its internal or external encoding to UTF-8.
Example: The following example demonstrates inserting data from an SQLXML
object into an XML column. The data is String data, so the database source treats
the data as externally encoded.
public void insertSQLXML()
{
Connection con = DriverManager.getConnection(url);
SQLXML info = con.createSQLXML();
// Create an SQLXML object
PreparedStatement insertStmt = null;
String infoData =
"<customerinfo xmlns=""http://posample.org"" " +
"Cid=""1000"">...</customerinfo>";
info.setString(infoData);
// Populate the SQLXML object
int cid = 1000;
try {
sqls = "INSERT INTO CUSTOMER (CID, INFO) VALUES (?, ?)";
insertStmt = con.prepareStatement(sqls);
insertStmt.setInt(1, cid);
insertStmt.setSQLXML(2, info);
// Assign the SQLXML object value
// to an input parameter
if (insertStmt.executeUpdate() != 1) {
System.out.println("insertSQLXML: No record inserted.");
}
}
catch (IOException ioe) {
ioe.printStackTrace();
}
catch (SQLException sqle) {
System.out.println("insertSQLXML: SQL Exception: " +
sqle.getMessage());
System.out.println("insertSQLXML: SQL State: " +
sqle.getSQLState());
System.out.println("insertSQLXML: SQL Error Code: " +
sqle.getErrorCode());
}
}
Example: The following example demonstrates inserting data from a file into an
XML column. The data is inserted as binary data, so the database server honors the
internal encoding.
public void insertBinStream(Connection conn)
{
PreparedStatement insertStmt = null;
String sqls = null;
int cid = 0;
Statement stmt=null;
try {
sqls = "INSERT INTO CUSTOMER (CID, INFO) VALUES (?, ?)";
insertStmt = conn.prepareStatement(sqls);
insertStmt.setInt(1, cid);
File file = new File(fn);
insertStmt.setBinaryStream(2,
new FileInputStream(file), (int)file.length());
if (insertStmt.executeUpdate() != 1) {
System.out.println("insertBinStream: No record inserted.");
}
}
catch (IOException ioe) {
86
Application Programming Guide and Reference for Java
ioe.printStackTrace();
}
catch (SQLException sqle) {
System.out.println("insertBinStream: SQL Exception: " +
sqle.getMessage());
System.out.println("insertBinStream: SQL State: " +
sqle.getSQLState());
System.out.println("insertBinStream: SQL Error Code: " +
sqle.getErrorCode());
}
}
Example: The following example demonstrates inserting binary XML data from a
file into an XML column.
...
SQLXML info = conn.createSQLXML();
OutputStream os = info.setBinaryStream ();
FileInputStream fis = new FileInputStream("c7.xml");
int read;
while ((read = fis.read ()) != -1) {
os.write (read);
}
PreparedStatement insertStmt = null;
String sqls = null;
int cid = 1015;
sqls = "INSERT INTO MyCustomer (Cid, Info) VALUES (?, ?)";
insertStmt = conn.prepareStatement(sqls);
insertStmt.setInt(1, cid);
insertStmt.setSQLXML(2, info);
insertStmt.executeUpdate();
Related reference
“Data types that map to database data types in Java applications” on page 211
XML data retrieval in JDBC applications
In JDBC applications, you use ResultSet.getXXX or ResultSet.getObject methods
to retrieve data from XML columns.
In a JDBC application, you can retrieve data from XML columns in a DB2 table as
XML textual data. You can retrieve data from XML columns in a table as binary
XML data (data that is in the Extensible Dynamic Binary XML DB2 Client/Server
Binary XML Format), if the data server supports binary XML data.
You can use one of the following techniques to retrieve XML data:
v Use the ResultSet.getSQLXML method to retrieve the data. Then use a
SQLXML.getXXX method to retrieve the data into a compatible output data type.
This technique requires JDBC 4.0 or later.
For example, you can retrieve data by using the SQLXML.getBinaryStream
method or the SQLXML.getSource method.
v Use a ResultSet.getXXX method other than ResultSet.getObject to retrieve the
data into a compatible data type.
v Use the ResultSet.getObject method to retrieve the data, and then cast it to the
DB2Xml type and assign it to a DB2Xml object. Then use a DB2Xml.getDB2XXX or
DB2Xml.getDB2XmlXXX method to retrieve the data into a compatible output data
type.
You need to use this technique if you are not using a version of the IBM Data
Server Driver for JDBC and SQLJ that supports JDBC 4.0.
Chapter 3. JDBC application programming
87
The following table lists the ResultSet methods and corresponding output data
types for retrieving XML data.
Table 20. ResultSet methods and data types for retrieving XML data
Method
Output data type
ResultSet.getAsciiStream
InputStream
ResultSet.getBinaryStream
InputStream
ResultSet.getBytes
byte[]
ResultSet.getCharacterStream
Reader
ResultSet.getObject
Object
ResultSet.getSQLXML
SQLXML
ResultSet.getString
String
The following table lists the methods that you can call to retrieve data from a
java.sql.SQLXML or a com.ibm.db2.jcc.DB2Xml object, and the corresponding
output data types and type of encoding in the XML declarations.
Table 21. SQLXML and DB2Xml methods, data types, and added encoding specifications
Method
Output data type
Type of XML internal encoding declaration added
SQLXML.getBinaryStream
InputStream
None
SQLXML.getCharacterStream
Reader
None
1
None
SQLXML.getSource
Source
SQLXML.getString
String
None
DB2Xml.getDB2AsciiStream
InputStream
None
DB2Xml.getDB2BinaryStream
InputStream
None
DB2Xml.getDB2Bytes
byte[]
None
DB2Xml.getDB2CharacterStream
Reader
None
DB2Xml.getDB2String
String
None
DB2Xml.getDB2XmlAsciiStream
InputStream
US-ASCII
DB2Xml.getDB2XmlBinaryStream
InputStream
Specified by getDB2XmlBinaryStream targetEncoding
parameter
DB2Xml.getDB2XmlBytes
byte[]
Specified by DB2Xml.getDB2XmlBytes targetEncoding
parameter
DB2Xml.getDB2XmlCharacterStream
Reader
ISO-10646-UCS-2
DB2Xml.getDB2XmlString
String
ISO-10646-UCS-2
Note:
1. The class that is returned is specified by the invoker of getSource, but the class must extend
javax.xml.transform.Source.
If the application executes the XMLSERIALIZE function on the data that is to be
returned, after execution of the function, the data has the data type that is specified
in the XMLSERIALIZE function, not the XML data type. Therefore, the driver
handles the data as the specified type and ignores any internal encoding
declarations.
88
Application Programming Guide and Reference for Java
Example: The following example demonstrates retrieving data from an XML
column into an SQLXML object, and then using the SQLXML.getString method to
retrieve the data into a string.
public void fetchToSQLXML(long cid, java.sql.Connection conn)
{
System.out.println(">> fetchToSQLXML: Get XML data as an SQLXML object " +
"using getSQLXML");
PreparedStatement selectStmt = null;
String sqls = null, stringDoc = null;
ResultSet rs = null;
try{
sqls = "SELECT info FROM customer WHERE cid = " + cid;
selectStmt = conn.prepareStatement(sqls);
rs = selectStmt.executeQuery();
// Get metadata
// Column type for XML column is the integer java.sql.Types.OTHER
ResultSetMetaData meta = rs.getMetaData();
int colType = meta.getColumnType(1);
System.out.println("fetchToSQLXML: Column type = " + colType);
while (rs.next()) {
// Retrieve the XML data with getSQLXML.
// Then write it to a string with
// explicit internal ISO-10646-UCS-2 encoding.
java.sql.SQLXML xml = rs.getSQLXML(1);
System.out.println (xml.getString());
}
rs.close();
}
catch (SQLException sqle) {
System.out.println("fetchToSQLXML: SQL Exception: " +
sqle.getMessage());
System.out.println("fetchToSQLXML: SQL State: " +
sqle.getSQLState());
System.out.println("fetchToSQLXML: SQL Error Code: " +
sqle.getErrorCode());
}
}
Example: The following example demonstrates retrieving data from an XML
column into an SQLXML object, and then using the SQLXML.getBinaryStream method
to retrieve the data as binary data into an InputStream.
String sql = "SELECT INFO FROM Customer WHERE Cid=’1000’";
PreparedStatement pstmt = con.prepareStatement(sql);
ResultSet resultSet = pstmt.executeQuery();
// Get the result XML as a binary stream
SQLXML sqlxml = resultSet.getSQLXML(1);
InputStream binaryStream = sqlxml.getBinaryStream();
Example: The following example demonstrates retrieving data from an XML
column into a String variable.
public void fetchToString(long cid, java.sql.Connection conn)
{
System.out.println(">> fetchToString: Get XML data " +
"using getString");
PreparedStatement selectStmt = null;
String sqls = null, stringDoc = null;
ResultSet rs = null;
try{
sqls = "SELECT info FROM customer WHERE cid = " + cid;
selectStmt = conn.prepareStatement(sqls);
rs = selectStmt.executeQuery();
Chapter 3. JDBC application programming
89
// Get metadata
// Column type for XML column is the integer java.sql.Types.OTHER
ResultSetMetaData meta = rs.getMetaData();
int colType = meta.getColumnType(1);
System.out.println("fetchToString: Column type = " + colType);
while (rs.next()) {
stringDoc = rs.getString(1);
System.out.println("Document contents:");
System.out.println(stringDoc);
}
catch (SQLException sqle) {
System.out.println("fetchToString: SQL Exception: " +
sqle.getMessage());
System.out.println("fetchToString: SQL State: " +
sqle.getSQLState());
System.out.println("fetchToString: SQL Error Code: " +
sqle.getErrorCode());
}
}
Example: The following example demonstrates retrieving data from an XML
column into a DB2Xml object, and then using the DB2Xml.getDB2XmlString method
to retrieve the data into a string with an added XML declaration with an
ISO-10646-UCS-2 encoding specification.
public void fetchToDB2Xml(long cid, java.sql.Connection conn)
{
System.out.println(">> fetchToDB2Xml: Get XML data as a DB2XML object " +
"using getObject");
PreparedStatement selectStmt = null;
String sqls = null, stringDoc = null;
ResultSet rs = null;
try{
sqls = "SELECT info FROM customer WHERE cid = " + cid;
selectStmt = conn.prepareStatement(sqls);
rs = selectStmt.executeQuery();
// Get metadata
// Column type for XML column is the integer java.sql.Types.OTHER
ResultSetMetaData meta = rs.getMetaData();
int colType = meta.getColumnType(1);
System.out.println("fetchToDB2Xml: Column type = " + colType);
while (rs.next()) {
// Retrieve the XML data with getObject, and cast the object
// as a DB2Xml object. Then write it to a string with
// explicit internal ISO-10646-UCS-2 encoding.
com.ibm.db2.jcc.DB2Xml xml =
(com.ibm.db2.jcc.DB2Xml) rs.getObject(1);
System.out.println (xml.getDB2XmlString());
}
rs.close();
}
catch (SQLException sqle) {
System.out.println("fetchToDB2Xml: SQL Exception: " +
sqle.getMessage());
System.out.println("fetchToDB2Xml: SQL State: " +
sqle.getSQLState());
System.out.println("fetchToDB2Xml: SQL Error Code: " +
sqle.getErrorCode());
}
}
90
Application Programming Guide and Reference for Java
Related reference
“Data types that map to database data types in Java applications” on page 211
Invocation of routines with XML parameters in Java
applications
Java applications can call stored procedures at DB2 Database for Linux, UNIX, and
Windows or DB2 for z/OS data sources that have XML parameters.
For native SQL procedures, XML parameters in the stored procedure definition
have the XML type. For external stored procedures and user-defined functions on
DB2 Database for Linux, UNIX, and Windows data sources, XML parameters in the
routine definition have the XML AS CLOB type. When you call a stored procedure
or user-defined function that has XML parameters, you need to use a compatible
data type in the invoking statement.
To call a routine with XML input parameters from a JDBC program, use
parameters of the java.sql.SQLXML or com.ibm.db2.jcc.DB2Xml type. To register
XML output parameters, register the parameters as the java.sql.Types.SQLXML or
com.ibm.db2.jcc.DB2Types.XML type. (The com.ibm.db2.jcc.DB2Xml and
com.ibm.db2.jcc.DB2Types.XML types are deprecated.)
Example: JDBC program that calls a stored procedure that takes three XML
parameters: an IN parameter, an OUT parameter, and an INOUT parameter. This
example requires JDBC 4.0.
java.sql.SQLXML in_xml = xmlvar;
java.sql.SQLXML out_xml = null;
java.sql.SQLXML inout_xml = xmlvar;
// Declare an input, output, and
// INOUT XML parameter
Connection con;
CallableStatement cstmt;
ResultSet rs;
...
cstmt = con.prepareCall("CALL SP_xml(?,?,?)");
// Create a CallableStatement object
cstmt.setObject (1, in_xml);
// Set input parameter
cstmt.setObject (3, inout_xml);
// Set inout parameter
cstmt.registerOutParameter (2, java.sql.Types.SQLXML);
// Register out and input parameters
cstmt.registerOutParameter (3, java.sql.Types.SQLXML);
cstmt.executeUpdate();
// Call the stored procedure
out_xml = cstmt.getSQLXML(2);
// Get the OUT parameter value
inout_xml = cstmt.getSQLXML(3);
// Get the INOUT parameter value
System.out.println("Parameter values from SP_xml call: ");
System.out.println("Output parameter value ");
MyUtilities.printString(out_xml.getString());
// Use the SQLXML.getString
// method to convert the out_xml
// value to a string for printing.
// Call a user-defined method called
// printString (not shown) to print
// the value.
System.out.println("INOUT parameter value ");
MyUtilities.printString(inout_xml.getString());
// Use the SQLXML.getString
// method to convert the inout_xml
// value to a string for printing.
// Call a user-defined method called
// printString (not shown) to print
// the value.
Chapter 3. JDBC application programming
91
To call a routine with XML parameters from an SQLJ program, use parameters of
the java.sql.SQLXML or com.ibm.db2.jcc.DB2Xml type.
Example: SQLJ program that calls a stored procedure that takes three XML
parameters: an IN parameter, an OUT parameter, and an INOUT parameter. This
example requires JDBC 4.0.
java.sql.SQLXML in_xml = xmlvar;
java.sql.SQLXML out_xml = null;
java.sql.SQLXML inout_xml = xmlvar;
// Declare an input, output, and
// INOUT XML parameter
...
#sql [myConnCtx] {CALL SP_xml(:IN in_xml,
:OUT out_xml,
:INOUT inout_xml)};
// Call the stored procedure
System.out.println("Parameter values from SP_xml call: ");
System.out.println("Output parameter value ");
MyUtilities.printString(out_xml.getString());
// Use the SQLXML.getString
// method toconvert the out_xml value
// to a string for printing.
// Call a user-defined method called
// printString (not shown) to print
// the value.
System.out.println("INOUT parameter value ");
MyUtilities.printString(inout_xml.getString());
// Use the SQLXML.getString
// method to convert the inout_xml
// value to a string for printing.
// Call a user-defined method called
// printString (not shown) to print
// the value.
Binary XML format in Java applications
The IBM Data Server Driver for JDBC and SQLJ can send XML data to the data
server or retrieve XML data from the data server as binary XML data (data that is
in the Extensible Dynamic Binary XML DB2 Client/Server Binary XML Format).
The data server must provide support for binary XML data.
The IBM Data Server Driver for JDBC and SQLJ presents binary XML data to the
application only through XML object interfaces. The user does not see the data in
the binary XML format.
You use the property xmlFormat to control whether the data format is textual XML
format or binary XML format. You set xmlFormat to XML_FORMAT_BINARY (1)
to enable binary XML format. XML_FORMAT_BINARY is the default if the data
server supports binary XML format. The format of XML data is transparent to the
application. Storage and retrieval of binary XML data requires version 4.9 or later
of the IBM Data Server Driver for JDBC and SQLJ. If you are using binary XML
data in SQLJ applications, you also need version 4.9 or later of the sqlj4.zip
package.
When binary XML data is used, the XML data that is passed to the IBM Data
Server Driver for JDBC and SQLJ cannot refer to external entities, internal entities,
or internal DTDs. External DTDs are supported only if those DTDs were
previously registered in the data source.
There is no setXXX method defined on the Connection interface for the xmlFormat
property. Therefore, to set the xmlFormat value when you use the Connection
92
Application Programming Guide and Reference for Java
interface, you need to specify xmlFormat as a property when you execute the
DriverManager.getConnection method. For example:
properties.put("xmlFormat", "1");
DriverManager.getConnection(url, properties);
Binary XML format is most efficient for cases in which the input or output data is
in a non-textual representation, such as SAX, StAX, or DOM. For example, these
methods retrieve XML data in non-textual representations:
v getSource(SAXSource.class)
v getSource(StAXSource.class)
v getSource(DOMSource.class)
These methods update XML columns with data in non-textual representations:
v setResult(SAXResult.class)
v setResult(StAXResult.class)
v setResult(DOMResult.class)
The SAX representation is the most efficient way to retrieve data that is in the
binary XML format because the data does not undergo extra conversions from
binary format to textual format.
Suppose that you set xmlFormat to XML_FORMAT_BINARY (1). In the following
JDBC example, the IBM Data Server Driver for JDBC and SQLJ retrieves data in
the binary XML format, application uses the SAX parser to parse the retrieved
data.
...
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("SELECT XMLCOL FROM XMLTABLE");
ContentHandler handler = new MyContentHandler();
while (rs.next()) {
SQLXML sqlxml = rs.getSQLXML(1);
SAXSource source = sqlxml.getSource(SAXSource.class);
XMLReader reader = source.getXMLReader();
reader.setContentHandler(handler);
reader.parse(source.getInputSource());
}
...
The following SQLJ example performs the same actions.
#sql iterator SqlXmlIter(java.sql.SQLXML);
{
...
SqlXmlIter SQLXMLiter = null;
java.sql.SQLXML outSqlXml = null;
ContentHandler handler = new MyContentHandler();
#sql [ctx] SQLXmlIter = {SELECT XMLCOL FROM XMLTABLE};
#sql {FETCH :SqlXmlIter INTO :outSqlXml};
while (!SQLXMLIter.endFetch()) {
SAXSource source = outSqlXml.getSource(SAXSource.class);
XMLReader reader = source.getXMLReader();
reader.setContentHandler(handler);
reader.parse(source.getInputSource());
#sql {FETCH :SqlXmlIter INTO :outSqlXml};
}
...
}
Chapter 3. JDBC application programming
93
Java support for XML schema registration and removal
The IBM Data Server Driver for JDBC and SQLJ provides methods that let you
write Java application programs to register and remove XML schemas and their
components.
The methods are:
DB2Connection.registerDB2XMLSchema
Registers an XML schema in DB2, using one or more XML schema documents.
There are two forms of this method: one form for XML schema documents that
are input from InputStream objects, and one form for XML schema documents
that are in a String.
DB2Connection.deregisterDB2XMLObject
Removes an XML schema definition from DB2.
DB2Connection.updateDB2XmlSchema
Replaces the XML schema documents in a registered XML schema with the
XML schema documents from another registered XML schema. Optionally
drops the XML schema whose contents are copied. This method is available
only for connections to DB2 Database for Linux, UNIX, and Windows.
Before you can invoke these methods, the stored procedures that support these
methods must be installed on the DB2 database server.
Example: Registration of an XML schema: The following example demonstrates the
use of registerDB2XmlSchema to register an XML schema in DB2 using a single
XML schema document (customer.xsd) that is read from an input stream. The SQL
schema name for the registered schema is SYSXSR. The xmlSchemaLocations value is
null, so DB2 will not find this XML schema on an invocation of
DSN_XMLVALIDATE that supplies a non-null XML schema location value. No
additional properties are registered.
public static void registerSchema(
Connection con,
String schemaName)
throws SQLException {
// Define the registerDB2XmlSchema parameters
String[] xmlSchemaNameQualifiers = new String[1];
String[] xmlSchemaNames = new String[1];
String[] xmlSchemaLocations = new String[1];
InputStream[] xmlSchemaDocuments = new InputStream[1];
int[] xmlSchemaDocumentsLengths = new int[1];
java.io.InputStream[] xmlSchemaDocumentsProperties = new InputStream[1];
int[] xmlSchemaDocumentsPropertiesLengths = new int[1];
InputStream xmlSchemaProperties;
int xmlSchemaPropertiesLength;
//Set the parameter values
xmlSchemaLocations[0] = "";
FileInputStream fi = null;
xmlSchemaNameQualifiers[0] = "SYSXSR";
xmlSchemaNames[0] = schemaName;
try {
fi = new FileInputStream("customer.xsd");
xmlSchemaDocuments[0] = new BufferedInputStream(fi);
} catch (FileNotFoundException e) {
e.printStackTrace();
}
try {
xmlSchemaDocumentsLengths[0] = (int) fi.getChannel().size();
System.out.println(xmlSchemaDocumentsLengths[0]);
} catch (IOException e1) {
e1.printStackTrace();
94
Application Programming Guide and Reference for Java
}
xmlSchemaDocumentsProperties[0] = null;
xmlSchemaDocumentsPropertiesLengths[0] = 0;
xmlSchemaProperties = null;
xmlSchemaPropertiesLength = 0;
DB2Connection ds = (DB2Connection) con;
// Invoke registerDB2XmlSchema
ds.registerDB2XmlSchema(
xmlSchemaNameQualifiers,
xmlSchemaNames,
xmlSchemaLocations,
xmlSchemaDocuments,
xmlSchemaDocumentsLengths,
xmlSchemaDocumentsProperties,
xmlSchemaDocumentsPropertiesLengths,
xmlSchemaProperties,
xmlSchemaPropertiesLength,
false);
}
Example: Removal of an XML schema: The following example demonstrates the use of
deregisterDB2XmlObject to remove an XML schema from DB2. The SQL schema
name for the registered schema is SYSXSR.
public static void deregisterSchema(
Connection con,
String schemaName)
throws SQLException {
// Define and assign values to the deregisterDB2XmlObject parameters
String xmlSchemaNameQualifier = "SYSXSR";
String xmlSchemaName = schemaName;
DB2Connection ds = (DB2Connection) con;
// Invoke deregisterDB2XmlObject
ds.deregisterDB2XmlObject(
xmlSchemaNameQualifier,
xmlSchemaName);
}
Example: Update of an XML schema: The following example applies only to
connections to DB2 Database for Linux, UNIX, and Windows. It demonstrates the
use of updateDB2XmlSchema to update the contents of an XML schema with the
contents of another XML schema. The schema that is copied is kept in the
repository. The SQL schema name for both registered schemas is SYSXSR.
public static void updateSchema(
Connection con,
String schemaNameTarget,
String schemaNameSource)
throws SQLException {
// Define and assign values to the updateDB2XmlSchema parameters
String xmlSchemaNameQualifierTarget = "SYSXSR";
String xmlSchemaNameQualifierSource = "SYSXSR";
String xmlSchemaNameTarget = schemaNameTarget;
String xmlSchemaNameSource = schemaNameSource;
boolean dropSourceSchema = false;
DB2Connection ds = (DB2Connection) con;
// Invoke updateDB2XmlSchema
ds.updateDB2XmlSchema(
xmlSchemaNameQualifierTarget,
xmlSchemaNameTarget,
xmlSchemaNameQualifierSource,
xmlSchemaNameSource,
dropSourceSchema);
}
Chapter 3. JDBC application programming
95
Inserting data from file reference variables into tables in JDBC
applications
You can use file reference variable objects with IBM Data Server Driver for JDBC
and SQLJ type 2 connectivity on DB2 for z/OS Version 9 or later to stream LOB or
XML input data.
You need to store your LOB or XML input data in HFS files.
Use of file reference variables eliminates the need to materialize the LOB or XML
data in memory before the data is stored in tables. To use file reference variables to
store LOB or XML data in tables, follow these steps.
1. Invoke the Connection.prepareStatement method to create a PreparedStatement
object from an INSERT statement.
The parameter markers in the INSERT statement represent XML or LOB values.
2. Execute constructors for file reference variable objects of the appropriate types.
The following table lists the types of data in the input files and the appropriate
constructors.
Input data type
Constructor
BLOB
com.ibm.db2.jcc.DB2BlobFileReference
CLOB
com.ibm.db2.jcc.DB2ClobFileReference
XML AS BLOB
com.ibm.db2.jcc.DB2XmlAsBlobFileReference
XML AS CLOB
com.ibm.db2.jcc.DB2XmlAsClobFileReference
The first parameter in each constructor must specify the absolute path name for
an existing HFS file.
3. If you are performing single-row INSERT operations, repeat these steps for
each row that you want to insert:
a. Invoke DB2PreparedStatement.setXXX to pass values to the input variables.
Alternatively, you can use PreparedStatement.setObject methods.
The following table lists the types of data in the input files and the
appropriate DB2PreparedStatement.setXXX methods to use for each data
type.
Input data type
DB2PreparedStatement.setXXX method
BLOB
setDB2BlobFileReference
CLOB
setDB2ClobFileReference
XML AS BLOB
setDB2XmlAsBlobFileReference
XML AS CLOB
setDB2XmlAsClobFileReference
If you use DB2PreparedStatement methods, you need to cast the
PreparedStatement object that you created in step 1 to a
DB2PreparedStatement object when you execute a
DB2PreparedStatement.setXXX method.
You can assign NULL values to input parameters in any of the following
ways:
v Using DB2PreparedStatement.setXXX methods, with null as the fileRef
parameter value.
96
Application Programming Guide and Reference for Java
v Using PreparedStatement.setObject, with null as the x (second)
parameter value and the appropriate value from
com.ibm.db2.jcc.DB2Types for the targetJdbcType (third) parameter value.
v Using PreparedStatement.setNull, with the appropriate value from
com.ibm.db2.jcc.DB2Types for the JdbcType (second) parameter value.
b. Invoke the PreparedStatement.execute or
PreparedStatement.executeUpdate method to update the table with the
variable values.
4. If you are performing multi-row INSERT operations, execute these steps:
a. Repeat these steps for every row that you want to insert:
1) Invoke DB2PreparedStatement.setXXX to pass values to the input
variables. Alternatively, you can use PreparedStatement.setObject
methods.
2) Invoke the PreparedStatement.addBatch method after you set the values
for a row of the table.
b. Invoke the PreparedStatement.executeBatch method to update the table
with the variable values.
5. Invoke the PreparedStatement.close method to close the PreparedStatement
object when you have finished using that object.
Examples
The following code inserts a single row into a table. The code inserts values from
CLOB and BLOB file reference variables into CLOB and BLOB columns and a
NULL value into an XML column. The numbers to the right of selected statements
correspond to the previously-described steps.
Connection conn;
...
PreparedStatement pstmt =
conn.prepareStatement(
"INSERT INTO TEST02TB(RECID,CLOBCOL,BLOBCOL,XMLCOL) VALUES(’003’,?,?,?)");
// Create a PreparedStatement object
1
com.ibm.db2.jcc.DB2ClobFileReference clobFileRef =
new com.ibm.db2.jcc.DB2ClobFileReference("/u/usrt001/jcc/test/TEXT.FILE","Cp037");
com.ibm.db2.jcc.DB2BlobFileReference blobFileRef =
new com.ibm.db2.jcc.DB2BlobFileReference("/u/usrt001/jcc/test/BINARY.FILE");
com.ibm.db2.jcc.DB2XmlAsBlobFileReference xmlAsBlobFileRef =
new com.ibm.db2.jcc.DB2XmlAsBlobFileReference(
"/u/usrt001/jcc/test/XML.FILE");
// Execute constructors for the file reference
2
// variable objects
((com.ibm.db2.jcc.DB2PreparedStatement)pstmt).setDB2ClobFileReference(1,clobFileRef);
((com.ibm.db2.jcc.DB2PreparedStatement)pstmt).setDB2BlobFileReference(2,blobFileRef);
pstmt.setNull(3,com.ibm.db2.jcc.DB2Types.XML_AS_BLOB_FILE);
// Assign values to the CLOB and BLOB parameters.3a
// Assign a null value to the XML parameter.
int numUpd = pstmt.executeUpdate();
// Perform the update
3b
pstmt.close();
// Close the PreparedStatement object
5
The following code uses multi-row INSERT to insert two rows in a table. The code
inserts values from XML AS CLOB and XML AS BLOB file reference variables into
XML columns. The numbers to the right of selected statements correspond to the
previously-described steps.
Connection conn;
...
PreparedStatement pstmt =
conn.prepareStatement(
Chapter 3. JDBC application programming
97
"INSERT INTO TEST03TB(RECID,XMLCLOBCOL,XMLBLOBCOL) VALUES(’003’,?,?)");
// Create a PreparedStatement object
1
com.ibm.db2.jcc.DB2XmlAsClobFileReference xmlAsClobFileRef1 =
new com.ibm.db2.jcc.DB2XmlAsClobFileReference("/u/usrt001/jcc/test/XMLCLOB1.FILE","Cp037");
com.ibm.db2.jcc.DB2XmlAsBlobFileReference xmlAsBlobFileRef1 =
new com.ibm.db2.jcc.DB2XmlAsBlobFileReference("/u/usrt001/jcc/test/XMLBLOB1.FILE");
com.ibm.db2.jcc.DB2XmlAsClobFileReference xmlAsClobFileRef2 =
new com.ibm.db2.jcc.DB2XmlAsClobFileReference("/u/usrt001/jcc/test/XMLCLOB2.FILE","Cp037");
com.ibm.db2.jcc.DB2XmlAsBlobFileReference xmlAsBlobFileRef2 =
new com.ibm.db2.jcc.DB2XmlAsBlobFileReference("/u/usrt001/jcc/test/XMLBLOB2.FILE");
// Execute constructors for the file reference
2
// variable objects
((com.ibm.db2.jcc.DB2PreparedStatement)pstmt).setDB2ClobFileReference(1,xmlAsClobFileRef1);
((com.ibm.db2.jcc.DB2PreparedStatement)pstmt).setDB2BlobFileReference(2,xmlAsBlobFileRef1);
// Assign first set of values to the
4ai
// XML parameters
pstmt.addBatch();
// Add the first input parameters to the batch
4aii
((com.ibm.db2.jcc.DB2PreparedStatement)pstmt).setDB2ClobFileReference(1,xmlAsClobFileRef2);
((com.ibm.db2.jcc.DB2PreparedStatement)pstmt).setDB2BlobFileReference(2,xmlAsBlobFileRef2);
// Assign second set of values to the
4ai
// XML parameters
pstmt.addBatch();
// Add the second input parameters to the batch 4aii
int [] numUpd = pstmt.executeBatch();
// Perform the update
4b
pstmt.close();
// Close the PreparedStatement object
5
Transaction control in JDBC applications
In JDBC applications, as in other types of SQL applications, transaction control
involves explicitly or implicitly committing and rolling back transactions, and
setting the isolation level for transactions.
IBM Data Server Driver for JDBC and SQLJ isolation levels
The IBM Data Server Driver for JDBC and SQLJ supports a number of isolation
levels, which correspond to database server isolation levels.
JDBC isolation levels can be set for a unit of work within a JDBC program, using
the Connection.setTransactionIsolation method. The default isolation level can
be set with the defaultIsolationLevel property.
The following table shows the values of level that you can specify in the
Connection.setTransactionIsolation method and their DB2 database server
equivalents.
Table 22. Equivalent JDBC and DB2 isolation levels
JDBC value
DB2 isolation level
java.sql.Connection.TRANSACTION_SERIALIZABLE
Repeatable read
java.sql.Connection.TRANSACTION_REPEATABLE_READ
Read stability
java.sql.Connection.TRANSACTION_READ_COMMITTED
Cursor stability
java.sql.Connection.TRANSACTION_READ_UNCOMMITTED
Uncommitted read
The following table shows the values of level that you can specify in the
Connection.setTransactionIsolation method and their IBM Informix equivalents.
Table 23. Equivalent JDBC and IBM Informix isolation levels
JDBC value
IBM Informix isolation level
java.sql.Connection.TRANSACTION_SERIALIZABLE
Repeatable read
98
Application Programming Guide and Reference for Java
Table 23. Equivalent JDBC and IBM Informix isolation levels (continued)
JDBC value
IBM Informix isolation level
java.sql.Connection.TRANSACTION_REPEATABLE_READ
Repeatable read
java.sql.Connection.TRANSACTION_READ_COMMITTED
Committed read
java.sql.Connection.TRANSACTION_READ_UNCOMMITTED
Dirty read
com.ibm.db2.jcc.DB2Connection.TRANSACTION_IDS_CURSOR_STABILITY
IBM Informix cursor stability
com.ibm.db2.jcc.DB2Connection.TRANSACTION_IDS_LAST_COMMITTED
Committed read, last committed
Related concepts
“JDBC connection objects” on page 20
Committing or rolling back JDBC transactions
In JDBC, to commit or roll back transactions explicitly, use the commit or rollback
methods.
For example:
Connection con;
...
con.commit();
If autocommit mode is on, the database manager performs a commit operation
after every SQL statement completes. To set autocommit mode on, invoke the
Connection.setAutoCommit(true) method. To set autocommit mode off, invoke the
Connection.setAutoCommit(false) method. To determine whether autocommit
mode is on, invoke the Connection.getAutoCommit method.
Connections that participate in distributed transactions cannot invoke the
setAutoCommit(true) method.
When you change the autocommit state, the database manager executes a commit
operation, if the application is not already on a transaction boundary.
While a connection is participating in a distributed or global transaction, the
associated application cannot issue the commit or rollback methods.
While a connection is participating in a global transaction, the associated
application cannot invoke the setAutoCommit(true) method.
Related concepts
“Savepoints in JDBC applications” on page 68
Related tasks
“Disconnecting from data sources in JDBC applications” on page 110
“Making batch updates in JDBC applications” on page 28
Default JDBC autocommit modes
The default autocommit mode depends on the data source to which the JDBC
application connects.
Autocommit default for DB2 data sources
For connections to DB2 data sources, the default autocommit mode is true.
Chapter 3. JDBC application programming
99
Autocommit default for IBM Informix data sources
For connections to IBM Informix data sources, the default autocommit mode
depends on the type of data source. The following table shows the defaults.
Table 24. Default autocommit modes for IBM Informix data sources
Type of data source
Default autocommit mode for local
transactions
Default autocommit mode for global
transactions
ANSI-compliant database
true
false
Non-ANSI-compliant database
without logging
false
not applicable
Non-ANSI-compliant database with
logging
true
false
Exceptions and warnings under the IBM Data Server Driver for JDBC
and SQLJ
In JDBC applications, SQL errors throw exceptions, which you handle using
try/catch blocks. SQL warnings do not throw exceptions, so you need to invoke
methods to check whether warnings occurred after you execute SQL statements.
The IBM Data Server Driver for JDBC and SQLJ provides the following classes and
interfaces, which provide information about errors and warnings.
SQLException
The SQLException class for handling errors. All JDBC methods throw an instance of
SQLException when an error occurs during their execution. According to the JDBC
specification, an SQLException object contains the following information:
v An int value that contains an error code. SQLException.getErrorCode retrieves
this value.
v A String object that contains the SQLSTATE, or null. SQLException.getSQLState
retrieves this value.
v A String object that contains a description of the error, or null.
SQLException.getMessage retrieves this value.
v A pointer to the next SQLException, or null. SQLException.getNextException
retrieves this value.
When a JDBC method throws a single SQLException, that SQLException might be
caused by an underlying Java exception that occurred when the IBM Data Server
Driver for JDBC and SQLJ processed the method. In this case, the SQLException
wraps the underlying exception, and you can use the SQLException.getCause
method to retrieve information about the error.
DB2Diagnosable
The IBM Data Server Driver for JDBC and SQLJ-only interface
com.ibm.db2.jcc.DB2Diagnosable extends the SQLException class. The
DB2Diagnosable interface gives you more information about errors that occur when
the data source is accessed. If the JDBC driver detects an error, DB2Diagnosable
gives you the same information as the standard SQLException class. However, if
the database server detects the error, DB2Diagnosable adds the following methods,
which give you additional information about the error:
100
Application Programming Guide and Reference for Java
getSqlca
Returns an DB2Sqlca object with the following information:
v An SQL error code
v The SQLERRMC values
v The SQLERRP value
v The SQLERRD values
v The SQLWARN values
v The SQLSTATE
getThrowable
Returns a java.lang.Throwable object that caused the SQLException, or null, if
no such object exists.
printTrace
Prints diagnostic information.
SQLException subclasses
If you are using JDBC 4.0 or later, you can obtain more specific information than
an SQLException provides by catching the following exception classes:
v SQLNonTransientException
An SQLNonTransientException is thrown when an SQL operation that failed
previously cannot succeed when the operation is retried, unless some corrective
action is taken. The SQLNonTransientException class has these subclasses:
– SQLFeatureNotSupportedException
– SQLNonTransientConnectionException
– SQLDataException
– SQLIntegrityConstraintViolationException
– SQLInvalidAuthorizationSpecException
– SQLSyntaxException
v SQLTransientException
An SQLTransientException is thrown when an SQL operation that failed
previously might succeed when the operation is retried, without intervention
from the application. A connection is still valid after an SQLTransientException
is thrown. The SQLTransientException class has these subclasses:
– SQLTransientConnectionException
– SQLTransientRollbackException
– SQLTimeoutException
v SQLRecoverableException
An SQLRecoverableException is thrown when an operation that failed previously
might succeed if the application performs some recovery steps, and retries the
transaction. A connection is no longer valid after an SQLRecoverableException is
thrown.
v SQLClientInfoException
A SQLClientInfoException is thrown by the Connection.setClientInfo method
when one or more client properties cannot be set. The SQLClientInfoException
indicates which properties cannot be set.
BatchUpdateException
A BatchUpdateException object contains the following items about an error that
occurs during execution of a batch of SQL statements:
v A String object that contains a description of the error, or null.
Chapter 3. JDBC application programming
101
v A String object that contains the SQLSTATE for the failing SQL statement, or
null
v An integer value that contains the error code, or zero
v An integer array of update counts for SQL statements in the batch, or null
v A pointer to an SQLException object, or null
One BatchUpdateException is thrown for the entire batch. At least one
SQLException object is chained to the BatchUpdateException object. The
SQLException objects are chained in the same order as the corresponding
statements were added to the batch. To help you match SQLException objects to
statements in the batch, the error description field for each SQLException object
begins with this string:
Error for batch element #n:
n is the number of the statement in the batch.
SQL warnings during batch execution do not throw BatchUpdateExceptions. To
obtain information about warnings, use the Statement.getWarnings method on the
object on which you ran the executeBatch method. You can then retrieve an error
description, SQLSTATE, and error code for each SQLWarning object.
SQLWarning
The IBM Data Server Driver for JDBC and SQLJ accumulates warnings when SQL
statements return positive SQLCODEs, and when SQL statements return 0
SQLCODEs with non-zero SQLSTATEs.
Calling getWarnings retrieves an SQLWarning object.
Important: When a call to Statement.executeUpdate or
PreparedStatement.executeUpdate affects no rows, the IBM Data Server Driver for
JDBC and SQLJ generates an SQLWarning with error code +100.
When a call to ResultSet.next returns no rows, the IBM Data Server Driver for
JDBC and SQLJ does not generate an SQLWarning.
A generic SQLWarning object contains the following information:
v A String object that contains a description of the warning, or null
v A String object that contains the SQLSTATE, or null
v An int value that contains an error code
v A pointer to the next SQLWarning, or null
Under the IBM Data Server Driver for JDBC and SQLJ, like an SQLException object,
an SQLWarning object can also contain DB2-specific information. The DB2-specific
information for an SQLWarning object is the same as the DB2-specific information
for an SQLException object.
Handling an SQLException under the IBM Data Server Driver
for JDBC and SQLJ
As in all Java programs, error handling for JDBC applications is done using
try/catch blocks. Methods throw exceptions when an error occurs, and the code in
the catch block handles those exceptions.
The basic steps for handling an SQLException in a JDBC program that runs under
the IBM Data Server Driver for JDBC and SQLJ are:
102
Application Programming Guide and Reference for Java
1. Give the program access to the com.ibm.db2.jcc.DB2Diagnosable interface and
the com.ibm.db2.jcc.DB2Sqlca class. You can fully qualify all references to
them, or you can import them:
import com.ibm.db2.jcc.DB2Diagnosable;
import com.ibm.db2.jcc.DB2Sqlca;
2. Optional: During a connection to a data server, set the
retrieveMessagesFromServerOnGetMessage property to true if you want full
message text from an SQLException.getMessage call.
3. Optional: During a IBM Data Server Driver for JDBC and SQLJ type 2
connectivity connection to a DB2 for z/OS data source, set the
extendedDiagnosticLevel property to EXTENDED_DIAG_MESSAGE_TEXT (241) if you
want extended diagnostic information similar to the information that is
provided by the SQL GET DIAGNOSTICS statement from an
SQLException.getMessage call.
4. Put code that can generate an SQLException in a try block.
5. In the catch block, perform the following steps in a loop:
a. Test whether you have retrieved the last SQLException. If not, continue to
the next step.
b. Optional: For an SQL statement that executes on an IBM Informix data
source, execute the
com.ibm.db2.jcc.DB2Statement.getIDSSQLStatementOffSet method to
determine which columns have syntax errors.
DB2Statement.getIDSSQLStatementOffSet returns the offset into the SQL
statement of the first syntax error.
c. Optional: For an SQL statement that executes on an IBM Informix data
source, execute the SQLException.getCause method to retrieve any ISAM
error messages.
1) If the Throwable that is returned by SQLException.getCause is not null,
perform one of the following sets of steps:
v Issue SQLException.printStackTrace to print an error message that
includes the ISAM error message text. The ISAM error message text is
preceded by the string "Caused by:".
v Retrieve the error code and message text for the ISAM message:
a) Test whether the Throwable is an instance of an SQLException. If
so, retrieve the SQL error code from that SQLException.
b) Execute the Throwable.getMessage method to retrieve the text of
the ISAM message.
d. Check whether any IBM Data Server Driver for JDBC and SQLJ-only
information exists by testing whether the SQLException is an instance of
DB2Diagnosable. If so:
1) Cast the object to a DB2Diagnosable object.
2) Optional: Invoke the DB2Diagnosable.printTrace method to write all
SQLException information to a java.io.PrintWriter object.
3) Invoke the DB2Diagnosable.getThrowable method to determine
whether an underlying java.lang.Throwable caused the SQLException.
4) Invoke the DB2Diagnosable.getSqlca method to retrieve the DB2Sqlca
object.
5) Invoke the DB2Sqlca.getSqlCode method to retrieve an SQL error code
value.
Chapter 3. JDBC application programming
103
6) Invoke the DB2Sqlca.getSqlErrmc method to retrieve a string that
contains all SQLERRMC values, or invoke the
DB2Sqlca.getSqlErrmcTokens method to retrieve the SQLERRMC
values in an array.
7) Invoke the DB2Sqlca.getSqlErrp method to retrieve the SQLERRP
value.
8) Invoke the DB2Sqlca.getSqlErrd method to retrieve the SQLERRD
values in an array.
9) Invoke the DB2Sqlca.getSqlWarn method to retrieve the SQLWARN
values in an array.
10) Invoke the DB2Sqlca.getSqlState method to retrieve the SQLSTATE
value.
11) Invoke the DB2Sqlca.getMessage method to retrieve error message text
from the data source.
e. Invoke the SQLException.getNextException method to retrieve the next
SQLException.
The following code demonstrates how to obtain IBM Data Server Driver for JDBC
and SQLJ-specific information from an SQLException that is provided with the IBM
Data Server Driver for JDBC and SQLJ. The numbers to the right of selected
statements correspond to the previously-described steps.
Figure 20. Processing an SQLException under the IBM Data Server Driver for JDBC and
SQLJ
import java.sql.*;
import com.ibm.db2.jcc.DB2Diagnosable;
import com.ibm.db2.jcc.DB2Sqlca;
java.io.PrintWriter printWriter;
// Import JDBC API package
// Import packages for DB2
1
// SQLException support
// For dumping all SQLException
// information
String url = "jdbc:db2://myhost:9999/myDB:" +
2
"retrieveMessagesFromServerOnGetMessage=true;";
// Set properties to retrieve full message
// text
String user = "db2adm";
String password = "db2adm";
java.sql.Connection con =
java.sql.DriverManager.getConnection (url, user, password)
// Connect to a DB2 for z/OS data source
...
try {
// Code that could generate SQLExceptions
...
} catch(SQLException sqle) {
while(sqle != null) {
// Check whether there are more
// SQLExceptions to process
//=====> Optional IBM Data Server Driver for JDBC and SQLJ-only
// error processing
if (sqle instanceof DB2Diagnosable) {
// Check if IBM Data Server Driver for JDBC and SQLJ-only
// information exists
com.ibm.db2.jcc.DB2Diagnosable diagnosable =
(com.ibm.db2.jcc.DB2Diagnosable)sqle;
diagnosable.printTrace (printWriter, "");
java.lang.Throwable throwable =
diagnosable.getThrowable();
if (throwable != null) {
// Extract java.lang.Throwable information
104
Application Programming Guide and Reference for Java
4
5a
5d
5d1
5d2
5d3
// such as message or stack trace.
...
}
DB2Sqlca sqlca = diagnosable.getSqlca();
5d4
// Get DB2Sqlca object
if (sqlca != null) {
// Check that DB2Sqlca is not null
int sqlCode = sqlca.getSqlCode(); // Get the SQL error code 5d5
String sqlErrmc = sqlca.getSqlErrmc();
5d6
// Get the entire SQLERRMC
String[] sqlErrmcTokens = sqlca.getSqlErrmcTokens();
// You can also retrieve the
// individual SQLERRMC tokens
String sqlErrp = sqlca.getSqlErrp();
5d7
// Get the SQLERRP
int[] sqlErrd = sqlca.getSqlErrd();
5d8
// Get SQLERRD fields
char[] sqlWarn = sqlca.getSqlWarn();
5d9
// Get SQLWARN fields
String sqlState = sqlca.getSqlState();
5d10
// Get SQLSTATE
String errMessage = sqlca.getMessage();
5d11
// Get error message
System.err.println ("Server error message: " + errMessage);
System.err.println ("--------------- SQLCA ---------------");
System.err.println ("Error code: " + sqlCode);
System.err.println ("SQLERRMC: " + sqlErrmc);
If (sqlErrmcTokens != null) {
for (int i=0; i< sqlErrmcTokens.length; i++) {
System.err.println (" token " + i + ": " + sqlErrmcTokens[i]);
}
}
System.err.println ( "SQLERRP: " + sqlErrp );
System.err.println (
"SQLERRD(1): " + sqlErrd[0] + "\n" +
"SQLERRD(2): " + sqlErrd[1] + "\n" +
"SQLERRD(3): " + sqlErrd[2] + "\n" +
"SQLERRD(4): " + sqlErrd[3] + "\n" +
"SQLERRD(5): " + sqlErrd[4] + "\n" +
"SQLERRD(6): " + sqlErrd[5] );
System.err.println (
"SQLWARN1: " + sqlWarn[0] + "\n" +
"SQLWARN2: " + sqlWarn[1] + "\n" +
"SQLWARN3: " + sqlWarn[2] + "\n" +
"SQLWARN4: " + sqlWarn[3] + "\n" +
"SQLWARN5: " + sqlWarn[4] + "\n" +
"SQLWARN6: " + sqlWarn[5] + "\n" +
"SQLWARN7: " + sqlWarn[6] + "\n" +
"SQLWARN8: " + sqlWarn[7] + "\n" +
"SQLWARN9: " + sqlWarn[8] + "\n" +
"SQLWARNA: " + sqlWarn[9] );
System.err.println ("SQLSTATE: " + sqlState);
// portion of SQLException
}
sqle=sqle.getNextException();
// Retrieve next SQLException
5e
}
}
Chapter 3. JDBC application programming
105
Related tasks
“Handling an SQLWarning under the IBM Data Server Driver for JDBC and SQLJ”
“Handling SQL errors in an SQLJ application” on page 169
“Handling SQL warnings in an SQLJ application” on page 170
Related reference
“Error codes issued by the IBM Data Server Driver for JDBC and SQLJ” on page
441
Handling an SQLWarning under the IBM Data Server Driver for
JDBC and SQLJ
Unlike SQL errors, SQL warnings do not cause JDBC methods to throw exceptions.
Instead, the Connection, Statement, PreparedStatement, CallableStatement, and
ResultSet classes contain getWarnings methods, which you need to invoke after
you execute SQL statements to determine whether any SQL warnings were
generated.
The basic steps for retrieving SQL warning information are:
1. Optional: During connection to the database server, set properties that affect
SQLWarning objects.
If you want full message text from a data server when you execute
SQLWarning.getMessage calls, set the retrieveMessagesFromServerOnGetMessage
property to true.
If you are using IBM Data Server Driver for JDBC and SQLJ type 2 connectivity
to a DB2 for z/OS data source, and you want extended diagnostic information
that is similar to the information that is provided by the SQL GET
DIAGNOSTICS statement when you execute SQLWarning.getMessage calls, set
the extendedDiagnosticLevel property to EXTENDED_DIAG_MESSAGE_TEXT (241).
2. Immediately after invoking a method that connects to a database server or
executes an SQL statement, invoke the getWarnings method to retrieve an
SQLWarning object.
3. Perform the following steps in a loop:
a. Test whether the SQLWarning object is null. If not, continue to the next step.
b. Invoke the SQLWarning.getMessage method to retrieve the warning
description.
c. Invoke the SQLWarning.getSQLState method to retrieve the SQLSTATE
value.
d. Invoke the SQLWarning.getErrorCode method to retrieve the error code
value.
e. If you want DB2-specific warning information, perform the same steps that
you perform to get DB2-specific information for an SQLException.
f. Invoke the SQLWarning.getNextWarning method to retrieve the next
SQLWarning.
The following code illustrates how to obtain generic SQLWarning information. The
numbers to the right of selected statements correspond to the previously-described
steps.
106
Application Programming Guide and Reference for Java
String url = "jdbc:db2://myhost:9999/myDB:" +
1
"retrieveMessagesFromServerOnGetMessage=true;";
// Set properties to retrieve full message
// text
String user = "db2adm";
String password = "db2adm";
java.sql.Connection con =
java.sql.DriverManager.getConnection (url, user, password)
// Connect to a DB2 for z/OS data source
Statement stmt;
ResultSet rs;
SQLWarning sqlwarn;
...
stmt = con.createStatement();
// Create a Statement object
rs = stmt.executeQuery("SELECT * FROM EMPLOYEE");
// Get the result table from the query
sqlwarn = stmt.getWarnings();
// Get any warnings generated
2
while (sqlwarn != null) {
// While there are warnings, get and
3a
// print warning information
System.out.println ("Warning description: " + sqlwarn.getMessage());
3b
System.out.println ("SQLSTATE: " + sqlwarn.getSQLState());
3c
System.out.println ("Error code: " + sqlwarn.getErrorCode());
3d
sqlwarn=sqlwarn.getNextWarning();
// Get next SQLWarning
3f
}
Figure 21. Example of processing an SQLWarning
Related tasks
“Handling an SQLException under the IBM Data Server Driver for JDBC and
SQLJ” on page 102
Retrieving information from a BatchUpdateException
When an error occurs during execution of a statement in a batch, processing
continues. However, executeBatch throws a BatchUpdateException.
To retrieve information from the BatchUpdateException, follow these steps:
1. Use the BatchUpdateException.getUpdateCounts method to determine the
number of rows that each SQL statement in the batch updated before the
exception was thrown.
getUpdateCount returns an array with an element for each statement in the
batch. An element has one of the following values:
n
The number of rows that the statement updated.
Statement.SUCCESS_NO_INFO
This value is returned if the number of updated rows cannot be
determined. The number of updated rows cannot be determined if the
following conditions are true:
v The application is connected to a subsystem that is in DB2 for z/OS
Version 8 new-function mode, or later.
v The application is using Version 3.1 or later of the IBM Data Server
Driver for JDBC and SQLJ.
v The IBM Data Server Driver for JDBC and SQLJ uses multi-row
INSERT operations to execute batch updates.
Statement.EXECUTE_FAILED
This value is returned if the statement did not execute successfully.
2. If the batched statement can return automatically generated keys:
Chapter 3. JDBC application programming
107
a. Cast the BatchUpdateException to a
com.ibm.db2.jcc.DBBatchUpdateException.
b. Call the DBBatchUpdateException.getDBGeneratedKeys method to retrieve an
array of ResultSet objects that contains the automatically generated keys for
each execution of the batched SQL statement.
c. Test whether each ResultSet in the array is null.
Each ResultSet contains:
v If the ResultSet is not null, it contains the automatically generated keys
for an execution of the batched SQL statement.
v If the ResultSet is null, execution of the batched statement failed.
3. Use SQLException methods getMessage, getSQLState, and getErrorCode to
retrieve the description of the error, the SQLSTATE, and the error code for the
first error.
4. Use the BatchUpdateException.getNextException method to get a chained
SQLException.
5. In a loop, execute the getMessage, getSQLState, getErrorCode, and
getNextException method calls to obtain information about an SQLException
and get the next SQLException.
The following code fragment demonstrates how to obtain the fields of a
BatchUpdateException and the chained SQLException objects for a batched
statement that returns automatically generated keys. The example assumes that
there is only one column in the automatically generated key, and that there is
always exactly one key value, whose data type is numeric. The numbers to the
right of selected statements correspond to the previously-described steps.
try {
// Batch updates
} catch(BatchUpdateException buex) {
System.err.println("Contents of BatchUpdateException:");
System.err.println(" Update counts: ");
int [] updateCounts = buex.getUpdateCounts();
1
for (int i = 0; i < updateCounts.length; i++) {
System.err.println(" Statement " + i + ":" + updateCounts[i]);
}
ResultSet[] resultList =
((DBBatchUpdateException)buex).getDBGeneratedKeys();
2
for (i = 0; i < resultList.length; i++)
{
if (resultList[i] == null)
continue; // Skip the ResultSet for which there was a failure
else {
rs.next();
java.math.BigDecimal idColVar = rs.getBigDecimal(1);
// Get automatically generated key
// value
System.out.println("Automatically generated key value = " + idColVar);
}
}
System.err.println(" Message: " + buex.getMessage());
3
System.err.println(" SQLSTATE: " + buex.getSQLState());
System.err.println(" Error code: " + buex.getErrorCode());
SQLException ex = buex.getNextException();
4
while (ex != null) {
5
System.err.println("SQL exception:");
System.err.println(" Message: " + ex.getMessage());
System.err.println(" SQLSTATE: " + ex.getSQLState());
108
Application Programming Guide and Reference for Java
System.err.println(" Error code: " + ex.getErrorCode());
ex = ex.getNextException();
}
}
Related tasks
“Making batch updates in JDBC applications” on page 28
Memory use for IBM Data Server Driver for IBM Data Server Driver for
JDBC and SQLJ type 2 connectivity on DB2 for z/OS
In general, applications that use IBM Data Server Driver for JDBC and SQLJ type 2
connectivity require more memory than applications that use IBM Data Server
Driver for JDBC and SQLJ type 4 connectivity.
With IBM Data Server Driver for JDBC and SQLJ type 4 connectivity, an
application receives data from the DB2 database server in network packets, and
receives only the data that is contained in a particular row and column of a table.
Applications that run under IBM Data Server Driver for JDBC and SQLJ type 2
connectivity on DB2 for z/OS generally require more memory. IBM Data Server
Driver for JDBC and SQLJ type 2 connectivity has a direct, native interface to DB2
for z/OS. For IBM Data Server Driver for JDBC and SQLJ type 2 connectivity, the
driver must provide memory in which DB2 for z/OS writes data. Because the
amount of data that is needed can vary from row to row, and the driver has no
information about how much memory is needed for each row, the driver must
allocate the maximum amount of memory that any row might need. This value is
determined from DESCRIBE information on the SELECT statement that generates
the result table. For example, when an application that uses IBM Data Server
Driver for JDBC and SQLJ type 2 connectivity selects a column that is defined as
VARCHAR(32000), the driver must allocate 32000 bytes for each row of the result
table.
The extra memory requirements can be particularly great for retrieval of LOB
columns, which can be defined with lengths of up to 2 GB, or for CAST
expressions that cast values to LOB types with large length attributes. Even when
you use a 64-bit JVM, all native connectivity to DB2 for z/OS is below the bar,
with 32-bit addressing limits. Although the maximum size of any row is defined as
approximately 2 GB, the practical maximum amount of available memory for use
by IBM Data Server Driver for JDBC and SQLJ type 2 connectivity is generally
significantly less. Therefore, applications that run under IBM Data Server Driver
for JDBC and SQLJ type 2 connectivity and involve LOBs with large length
attributes can fail with out-of-memory errors.
Two ways to alleviate excess memory use for LOB retrieval and manipulation are
to use progressive streaming or LOB locators. You enable progressive streaming or
LOB locator use by setting the progressiveStreaming property or the
fullyMaterializeLobData property.
Chapter 3. JDBC application programming
109
Related concepts
“LOBs in JDBC applications with the IBM Data Server Driver for JDBC and SQLJ”
on page 51
Related reference
“Properties for the IBM Data Server Driver for JDBC and SQLJ” on page 221
Disconnecting from data sources in JDBC applications
When you have finished with a connection to a data source, it is essential that you
close the connection to the data source. Doing this releases the Connection object's
database and JDBC resources immediately.
To close the connection to the data source, use the close method. For example:
Connection con;
...
con.close();
For a connection to a DB2 data source, if autocommit mode is not on, the
connection needs to be on a unit-of-work boundary before you close the
connection.
For a connection to an IBM Informix database, if the database supports logging,
and autocommit mode is not on, the connection needs to be on a unit-of-work
boundary before you close the connection.
Related concepts
“How JDBC applications connect to a data source” on page 11
110
Application Programming Guide and Reference for Java
Chapter 4. SQLJ application programming
Writing an SQLJ application has much in common with writing an SQL application
in any other language.
In general, you need to do the following things:
v Import the Java packages that contain SQLJ and JDBC methods.
v Declare variables for sending data to or retrieving data from DB2 tables.
v Connect to a data source.
v Execute SQL statements.
v Handle SQL errors and warnings.
v Disconnect from the data source.
Although the tasks that you need to perform are similar to those in other
languages, the way that you execute those tasks, and the order in which you
execute those tasks, is somewhat different.
Example of a simple SQLJ application
A simple SQLJ application demonstrates the basic elements that JDBC applications
need to include.
Figure 22. Simple SQLJ application
import sqlj.runtime.*;
import java.sql.*;
1
#sql context EzSqljCtx;
#sql iterator EzSqljNameIter (String LASTNAME);
3a
4a
public class EzSqlj {
public static void main(String args[])
throws SQLException
{
EzSqljCtx ctx = null;
String URLprefix = "jdbc:db2:";
String url;
url = new String(URLprefix + args[0]);
// Location name is an input parameter
String hvmgr="000010";
2
String hvdeptno="A00";
try {
3b
Class.forName("com.ibm.db2.jcc.DB2Driver");
} catch (Exception e)
{
throw new SQLException("Error in EzSqlj: Could not load the driver");
}
try
{
System.out.println("About to connect using url: " + url);
Connection con0 = DriverManager.getConnection(url);
3c
// Create a JDBC Connection
con0.setAutoCommit(false);
// set autocommit OFF
ctx = new EzSqljCtx(con0);
3d
try
{
© Copyright IBM Corp. 1998, 2011
111
EzSqljNameIter iter;
int count=0;
#sql [ctx] iter =
{SELECT LASTNAME FROM EMPLOYEE};
4b
// Create result table of the SELECT
while (iter.next()) {
4c
System.out.println(iter.LASTNAME());
// Retrieve rows from result table
count++;
}
System.out.println("Retrieved " + count + " rows of data");
iter.close();
// Close the iterator
}
catch( SQLException e )
5
{
System.out.println ("**** SELECT SQLException...");
while(e!=null) {
System.out.println ("Error msg: " + e.getMessage());
System.out.println ("SQLSTATE: " + e.getSQLState());
System.out.println ("Error code: " + e.getErrorCode());
e = e.getNextException(); // Check for chained exceptions
}
}
catch( Exception e )
{
System.out.println("**** NON-SQL exception
= " + e);
e.printStackTrace();
}
try
{
#sql [ctx]
4d
{UPDATE DEPARTMENT SET MGRNO=:hvmgr
WHERE DEPTNO=:hvdeptno};
// Update data for one department
6
#sql [ctx] {COMMIT};
// Commit the update
}
catch( SQLException e )
{
System.out.println ("**** UPDATE SQLException...");
System.out.println ("Error msg: " + e.getMessage() + ". SQLSTATE=" +
e.getSQLState() + " Error code=" + e.getErrorCode());
e.printStackTrace();
}
catch( Exception e )
{
System.out.println("**** NON-SQL exception
= " + e);
e.printStackTrace();
}
ctx.close();
7
}
catch(SQLException e)
{
System.out.println ("**** SQLException ...");
System.out.println ("Error msg: " + e.getMessage() + ". SQLSTATE=" +
e.getSQLState() + " Error code=" + e.getErrorCode());
e.printStackTrace();
}
catch(Exception e)
{
System.out.println ("**** NON-SQL exception = " + e);
e.printStackTrace();
}
}
Notes to Figure 22 on page 111:
112
Application Programming Guide and Reference for Java
Note
1
2
3a, 3b, 3c,
and 3d
Description
These statements import the java.sql package, which contains the JDBC core
API, and the sqlj.runtime package, which contains the SQLJ API. For
information on other packages or classes that you might need to access, see
"Java packages for SQLJ support".
String variables hvmgr and hvdeptno are host identifiers, which are equivalent
to DB2 host variables. See "Variables in SQLJ applications" for more
information.
These statements demonstrate how to connect to a data source using one of the
three available techniques. See "Connecting to a data source using SQLJ" for
more details.
Step 3b (loading the JDBC driver) is not necessary if you use JDBC 4.0.
4a , 4b, 4c, These statements demonstrate how to execute SQL statements in SQLJ.
and 4d
Statement 4a demonstrates the SQLJ equivalent of declaring an SQL cursor.
Statements 4b and 4c show one way of doing the SQLJ equivalent of executing
an SQL OPEN CURSOR and SQL FETCHes. Statement 4d shows how to do the
SQLJ equivalent of performing an SQL UPDATE. For more information, see
"SQL statements in an SQLJ application".
5
This try/catch block demonstrates the use of the SQLException class for SQL
error handling. For more information on handling SQL errors, see "Handling
SQL errors in an SQLJ application". For more information on handling SQL
warnings, see "Handling SQL warnings in an SQLJ application".
6
This is an example of a comment. For rules on including comments in SQLJ
programs, see "Comments in an SQLJ application".
7
This statement closes the connection to the data source. See "Closing the
connection to the data source in an SQLJ application".
Connecting to a data source using SQLJ
In an SQLJ application, as in any other DB2 application, you must be connected to
a data source before you can execute SQL statements.
You can use one of six techniques to connect to a data source in an SQLJ program.
Two use the JDBC DriverManager interface, two use the JDBC DataSource interface,
one uses a previously created connection context, and one uses the default
connection.
Related concepts
“How JDBC applications connect to a data source” on page 11
SQLJ connection technique 1: JDBC DriverManager interface
SQLJ connection technique 1 uses the JDBC DriverManager interface as the
underlying means for creating the connection.
To use SQLJ connection technique 1, follow these steps:
1. Execute an SQLJ connection declaration clause.
Doing this generates a connection context class. The simplest form of the
connection declaration clause is:
#sql context context-class-name;
The name of the generated connection context class is context-class-name.
2. Load a JDBC driver by invoking the Class.forName method.
v Invoke Class.forName this way:
Class.forName("com.ibm.db2.jcc.DB2Driver");
Chapter 4. SQLJ application programming
113
This step is unnecessary if you use the JDBC 4.0 driver.
3. Invoke the constructor for the connection context class that you created in step
1 on page 113.
Doing this creates a connection context object that you specify in each SQL
statement that you execute at the associated data source. The constructor
invocation statement needs to be in one of the following forms:
connection-context-class connection-context-object=
new connection-context-class(String url, boolean autocommit);
connection-context-class connection-context-object=
new connection-context-class(String url, String user,
String password, boolean autocommit);
connection-context-class connection-context-object=
new connection-context-class(String url, Properties info,
boolean autocommit);
The meanings of the parameters are:
url A string that specifies the location name that is associated with the data
source. That argument has one of the forms that are specified in "Connect
to a data source using the DriverManager interface with the IBM Data
Server Driver for JDBC and SQLJ". The form depends on which JDBC
driver you are using.
user and password
Specify a user ID and password for connection to the data source, if the
data source to which you are connecting requires them.
If the data source is a DB2 for z/OS system, and you do not specify these
parameters, DB2 uses the external security environment, such as the RACF
security environment, that was previously established for the user. For a
CICS connection, you cannot specify a user ID or password.
info
Specifies an object of type java.util.Properties that contains a set of
driver properties for the connection. For the IBM Data Server Driver for
JDBC and SQLJ, you can specify any of the properties listed in "Properties
for the IBM Data Server Driver for JDBC and SQLJ".
autocommit
Specifies whether you want the database manager to issue a COMMIT after
every statement. Possible values are true or false. If you specify false,
you need to do explicit commit operations.
The following code uses connection technique 1 to create a connection to location
NEWYORK. The connection requires a user ID and password, and does not require
autocommit. The numbers to the right of selected statements correspond to the
previously-described steps.
114
Application Programming Guide and Reference for Java
#sql context Ctx;
// Create connection context class Ctx
1
String userid="dbadm";
// Declare variables for user ID and password
String password="dbadm";
String empname;
// Declare a host variable
...
try {
// Load the JDBC driver
Class.forName("com.ibm.db2.jcc.DB2Driver");
2
}
catch (ClassNotFoundException e) {
e.printStackTrace();
}
Ctx myConnCtx=
3
new Ctx("jdbc:db2://sysmvs1.stl.ibm.com:5021/NEWYORK",
userid,password,false);
// Create connection context object myConnCtx
// for the connection to NEWYORK
#sql [myConnCtx] {SELECT LASTNAME INTO :empname FROM EMPLOYEE
WHERE EMPNO=’000010’};
// Use myConnCtx for executing an SQL statement
Figure 23. Using connection technique 1 to connect to a data source
SQLJ connection technique 2: JDBC DriverManager interface
SQLJ connection technique 2 uses the JDBC DriverManager interface as the
underlying means for creating the connection.
To use SQLJ connection technique 2, follow these steps:
1. Execute an SQLJ connection declaration clause.
Doing this generates a connection context class. The simplest form of the
connection declaration clause is:
#sql context context-class-name;
The name of the generated connection context class is context-class-name.
2. Load a JDBC driver by invoking the Class.forName method.
v Invoke Class.forName this way:
Class.forName("com.ibm.db2.jcc.DB2Driver");
This step is unnecessary if you use the JDBC 4.0 driver.
3. Invoke the JDBC DriverManager.getConnection method.
Doing this creates a JDBC connection object for the connection to the data
source. You can use any of the forms of getConnection that are specified in
"Connect to a data source using the DriverManager interface with the IBM Data
Server Driver for JDBC and SQLJ".
The meanings of the url, user, and password parameters are:
url A string that specifies the location name that is associated with the data
source. That argument has one of the forms that are specified in "Connect
to a data source using the DriverManager interface with the IBM Data
Server Driver for JDBC and SQLJ". The form depends on which JDBC
driver you are using.
user and password
Specify a user ID and password for connection to the data source, if the
data source to which you are connecting requires them.
If the data source is a DB2 for z/OS system, and you do not specify these
parameters, DB2 uses the external security environment, such as the RACF
Chapter 4. SQLJ application programming
115
security environment, that was previously established for the user. For a
CICS connection, you cannot specify a user ID or password.
4. Invoke the constructor for the connection context class that you created in step
1 on page 115
Doing this creates a connection context object that you specify in each SQL
statement that you execute at the associated data source. The constructor
invocation statement needs to be in the following form:
connection-context-class connection-context-object=
new connection-context-class(Connection JDBC-connection-object);
The JDBC-connection-object parameter is the Connection object that you created
in step 3 on page 115.
The following code uses connection technique 2 to create a connection to location
NEWYORK. The connection requires a user ID and password, and does not require
autocommit. The numbers to the right of selected statements correspond to the
previously-described steps.
#sql context Ctx;
// Create connection context class Ctx
1
String userid="dbadm";
// Declare variables for user ID and password
String password="dbadm";
String empname;
// Declare a host variable
...
try {
// Load the JDBC driver
Class.forName("com.ibm.db2.jcc.DB2Driver");
2
}
catch (ClassNotFoundException e) {
e.printStackTrace();
}
Connection jdbccon=
3
DriverManager.getConnection("jdbc:db2://sysmvs1.stl.ibm.com:5021/NEWYORK",
userid,password);
// Create JDBC connection object jdbccon
jdbccon.setAutoCommit(false); // Do not autocommit
Ctx myConnCtx=new Ctx(jdbccon);
4
// Create connection context object myConnCtx
// for the connection to NEWYORK
#sql [myConnCtx] {SELECT LASTNAME INTO :empname FROM EMPLOYEE
WHERE EMPNO=’000010’};
// Use myConnCtx for executing an SQL statement
Figure 24. Using connection technique 2 to connect to a data source
SQLJ connection technique 3: JDBC DataSource interface
SQLJ connection technique 3 uses the JDBC DataSource as the underlying means
for creating the connection.
To use SQLJ connection technique 3, follow these steps:
1. Execute an SQLJ connection declaration clause.
Doing this generates a connection context class. The simplest form of the
connection declaration clause is:
#sql context context-class-name;
The name of the generated connection context class is context-class-name.
2. If your system administrator created a DataSource object in a different program,
follow these steps. Otherwise, create a DataSource object and assign properties
to it.
a. Obtain the logical name of the data source to which you need to connect.
116
Application Programming Guide and Reference for Java
b. Create a context to use in the next step.
c. In your application program, use the Java Naming and Directory Interface
(JNDI) to get the DataSource object that is associated with the logical data
source name.
3. Invoke the JDBC DataSource.getConnection method.
Doing this creates a JDBC connection object for the connection to the data
source. You can use one of the following forms of getConnection:
getConnection();
getConnection(user, password);
The meanings of the user and password parameters are:
user and password
Specify a user ID and password for connection to the data source, if the
data source to which you are connecting requires them.
If the data source is a DB2 for z/OS system, and you do not specify these
parameters, DB2 uses the external security environment, such as the RACF
security environment, that was previously established for the user. For a
CICS connection, you cannot specify a user ID or password.
4. If the default autocommit mode is not appropriate, invoke the JDBC
Connection.setAutoCommit method.
Doing this indicates whether you want the database manager to issue a
COMMIT after every statement. The form of this method is:
setAutoCommit(boolean autocommit);
For environments other than the environments for CICS, stored procedures, and
user-defined functions, the default autocommit mode for a JDBC connection is
true. To disable autocommit, invoke setAutoCommit(false).
5. Invoke the constructor for the connection context class that you created in step
1 on page 116.
Doing this creates a connection context object that you specify in each SQL
statement that you execute at the associated data source. The constructor
invocation statement needs to be in the following form:
connection-context-class connection-context-object=
new connection-context-class(Connection JDBC-connection-object);
The JDBC-connection-object parameter is the Connection object that you created
in step 3.
The following code uses connection technique 3 to create a connection to a location
with logical name jdbc/sampledb. This example assumes that the system
administrator created and deployed a DataSource object that is available through
JNDI lookup. The numbers to the right of selected statements correspond to the
previously-described steps.
Chapter 4. SQLJ application programming
117
import java.sql.*;
import javax.naming.*;
import javax.sql.*;
...
#sql context CtxSqlj;
// Create connection context class CtxSqlj 1
Context ctx=new InitialContext();
2b
DataSource ds=(DataSource)ctx.lookup("jdbc/sampledb");
2c
Connection con=ds.getConnection();
3
String empname;
// Declare a host variable
...
con.setAutoCommit(false);
// Do not autocommit
4
CtxSqlj myConnCtx=new CtxSqlj(con);
5
// Create connection context object myConnCtx
#sql [myConnCtx] {SELECT LASTNAME INTO :empname FROM EMPLOYEE
WHERE EMPNO=’000010’};
// Use myConnCtx for executing an SQL statement
Figure 25. Using connection technique 3 to connect to a data source
SQLJ connection technique 4: JDBC DataSource interface
SQLJ connection technique 4 uses the JDBC DataSource as the underlying means
for creating the connection. This technique requires that the DataSource is
registered with JNDI.
To use SQLJ connection technique 4, follow these steps:
1. From your system administrator, obtain the logical name of the data source to
which you need to connect.
2. Execute an SQLJ connection declaration clause.
For this type of connection, the connection declaration clause needs to be of
this form:
#sql public static context context-class-name
with (dataSource="logical-name");
The connection context must be declared as public and static. logical-name is the
data source name that you obtained in step 1.
3. Invoke the constructor for the connection context class that you created in step
2.
Doing this creates a connection context object that you specify in each SQL
statement that you execute at the associated data source. The constructor
invocation statement needs to be in one of the following forms:
connection-context-class connection-context-object=
new connection-context-class();
connection-context-class connection-context-object=
new connection-context-class (String user,
String password);
The meanings of the user and password parameters are:
user and password
Specify a user ID and password for connection to the data source, if the
data source to which you are connecting requires them.
If the data source is a DB2 for z/OS system, and you do not specify these
parameters, DB2 uses the external security environment, such as the RACF
security environment, that was previously established for the user. For a
CICS connection, you cannot specify a user ID or password.
118
Application Programming Guide and Reference for Java
The following code uses connection technique 4 to create a connection to a location
with logical name jdbc/sampledb. The connection requires a user ID and password.
#sql public static context Ctx
with (dataSource="jdbc/sampledb");
2
// Create connection context class Ctx
String userid="dbadm";
// Declare variables for user ID and password
String password="dbadm";
String empname;
// Declare a host variable
...
Ctx myConnCtx=new Ctx(userid, password);
3
// Create connection context object myConnCtx
// for the connection to jdbc/sampledb
#sql [myConnCtx] {SELECT LASTNAME INTO :empname FROM EMPLOYEE
WHERE EMPNO=’000010’};
// Use myConnCtx for executing an SQL statement
Figure 26. Using connection technique 4 to connect to a data source
SQLJ connection technique 5: Use a previously created
connection context
SQLJ connection technique 5 uses a previously created connection context to
connect to the data source.
In general, one program declares a connection context class, creates connection
contexts, and passes them as parameters to other programs. A program that uses
the connection context invokes a constructor with the passed connection context
object as its argument.
Program CtxGen.sqlj declares connection context Ctx and creates instance oldCtx:
#sql context Ctx;
...
// Create connection context object oldCtx
Program test.sqlj receives oldCtx as a parameter and uses oldCtx as the argument
of its connection context constructor:
void useContext(sqlj.runtime.ConnectionContext oldCtx)
// oldCtx was created in CtxGen.sqlj
{
Ctx myConnCtx=
new Ctx(oldCtx);
// Create connection context object myConnCtx
// from oldCtx
#sql [myConnCtx] {SELECT LASTNAME INTO :empname FROM EMPLOYEE
WHERE EMPNO=’000010’};
// Use myConnCtx for executing an SQL statement
...
}
SQLJ connection technique 6: Use the default connection
SQLJ connection technique 6 uses the default connection to connect to the data
source. It should be used only in situations where the database thread is controlled
by another resource manager, such as the Java stored procedure environment.
You use the default connection by specifying your SQL statements without a
connection context object. When you use this technique, you do not need to load a
JDBC driver unless you explicitly use JDBC interfaces in your program.
The default connection context can be:
Chapter 4. SQLJ application programming
119
v The connection context that is associated with the data source that is bound to
the logical name jdbc/defaultDataSource
v An explicitly created connection context that has been set as the default
connection context with the ConnectionContext.setDefaultContext method. This
method of creating a default connection context is not recommended.
In a stored procedure that runs on DB2 for z/OS, or for a CICS or IMS application,
when you use the default connection, DB2 uses the implicit connection.
The following SQLJ execution clause does not have a connection context, so it uses
the default connection context.
#sql {SELECT LASTNAME INTO :empname FROM EMPLOYEE
WHERE EMPNO=’000010’}; // Use default connection for
// executing an SQL statement
Java packages for SQLJ support
Before you can execute SQLJ statements or invoke JDBC methods in your SQLJ
program, you need to be able to access all or parts of various Java packages that
contain support for those statements.
You can do that either by importing the packages or specific classes, or by using
fully-qualified class names. You might need the following packages or classes for
your SQLJ program:
sqlj.runtime
Contains the SQLJ run-time API.
java.sql
Contains the core JDBC API.
com.ibm.db2.jcc
Contains the driver-specific implementation of JDBC and SQLJ.
javax.naming
Contains methods for performing Java Naming and Directory Interface
(JNDI) lookup.
javax.sql
Contains methods for creating DataSource objects.
Variables in SQLJ applications
In DB2 programs in other languages, you use host variables to pass data between
the application program and DB2. In SQLJ programs, In SQLJ programs, you can
use host variables or host expressions.
A host expression begins with a colon (:). The colon is followed by an optional
parameter mode identifier (IN, OUT, or INOUT), which is followed by a
parenthesized expression clause.
Host variables and host expressions are case sensitive.
A complex expression is an array element or Java expression that evaluates to a
single value. A complex expression in an SQLJ clause must be surrounded by
parentheses.
The following examples demonstrate how to use host expressions.
120
Application Programming Guide and Reference for Java
Example: Declaring a Java identifier and using it in a SELECT statement:
In this example, the statement that begins with #sql has the same function as a
SELECT statement in other languages. This statement assigns the last name of the
employee with employee number 000010 to Java identifier empname.
String empname;
...
#sql [ctxt]
{SELECT LASTNAME INTO :empname FROM EMPLOYEE WHERE EMPNO=’000010’};
Example: Declaring a Java identifier and using it in a stored procedure call:
In this example, the statement that begins with #sql has the same function as an
SQL CALL statement in other languages. This statement uses Java identifier empno
as an input parameter to stored procedure A. The keyword IN, which precedes
empno, specifies that empno is an input parameter. For a parameter in a CALL
statement, IN is the default. The explicit or default qualifier that indicates how the
parameter is used (IN, OUT, or INOUT) must match the corresponding value in
the parameter definition that you specified in the CREATE PROCEDURE statement
for the stored procedure.
String empno = "0000010";
...
#sql [ctxt] {CALL A (:IN empno)};
Example: Using a complex expression as a host identifier:
This example uses complex expression (((int)yearsEmployed++/5)*500) as a host
expression.
#sql [ctxt] {UPDATE EMPLOYEE
SET BONUS=:(((int)yearsEmployed++/5)*500) WHERE EMPNO=:empID};
SQLJ performs the following actions when it processes a complex host expression:
v Evaluates each of the host expressions in the statement, from left to right, before
assigning their respective values to the database.
v Evaluates side effects, such as operations with postfix operators, according to
normal Java rules. All host expressions are fully evaluated before any of their
values are passed to DB2.
v Uses Java rules for rounding and truncation.
Therefore, if the value of yearsEmployed is 6 before the UPDATE statement is
executed, the value that is assigned to column BONUS by the UPDATE statement
is ((int)6/5)*500, or 500. After 500 is assigned to BONUS, the value of
yearsEmployed is incremented.
Restrictions on variable names: Two strings have special meanings in SQLJ
programs. Observe the following restrictions when you use these strings in your
SQLJ programs:
v The string __sJT_ is a reserved prefix for variable names that are generated by
SQLJ. Do not begin the following types of names with __sJT_:
– Host expression names
– Java variable names that are declared in blocks that include executable SQL
statements
– Names of parameters for methods that contain executable SQL statements
Chapter 4. SQLJ application programming
121
– Names of fields in classes that contain executable SQL statements, or in
classes with subclasses or enclosed classes that contain executable SQL
statements
v The string _SJ is a reserved suffix for resource files and classes that are
generated by SQLJ. Avoid using the string _SJ in class names and input source
file names.
Indicator variables in SQLJ applications
In SQLJ programs, you can use indicator variables to pass the NULL value to or
from a data server, to pass the default value for a column to the data server, or to
indicate that a host variable value is unassigned.
A host variable or host expression can be followed by an indicator variable. An
indicator variable begins with a colon (:) and has the data type short. For input, an
indicator variable indicates whether the corresponding host variable or host
expression has the default value, a non-null value, the null value, or is unassigned.
An unassigned variable in an SQL statement yields the same results as if the
variable and its target column were not in the SQL statement. For output, the
indicator variable indicates where the corresponding host variable or host
expression has a non-null value or a null value.
In SQLJ programs, indicator variables that indicate a null value perform the same
function as assigning the Java null value to a table column. However, you need to
use an indicator variable to retrieve the SQL NULL value from a table into a host
variable.
You can use indicator variables that assign the default value or the unassigned
value to columns to simplify the coding in your applications. For example, if a
table has four columns, and you might need to update any combination of those
columns, without the use of default indicator variables or unassigned indicator
variables, you need 15 UPDATE statements to perform all possible combinations of
updates. With default indicator variables and unassigned indicator variables, you
can use one UPDATE statement with all four columns in the SET statement to
perform all possible updates. You use the indicator variables to indicate which
columns you want to set to their default values, and which columns you do not
want to update.
For input, SQLJ supports the use of indicator variables for INSERT, UPDATE, or
MERGE statements.
If you customize your SQLJ application, you can assign one of the following values
to an indicator variable in an SQLJ application to specify the type of the
corresponding input host variable.
Indicator value
Equivalent constant
Meaning of value
-1
sqlj.runtime.ExecutionContext.DBNull
Null
-5
sqlj.runtime.ExecutionContext.DBDefault
Default
-7
sqlj.runtime.ExecutionContext.DBUnassigned
Unassigned
short-value >=0
sqlj.runtime.ExecutionContext.DBNonNull
Non-null
-2, -3, -4, -6
122
Application Programming Guide and Reference for Java
If you do not customize the application, you can assign one of the following values
to an indicator variable to specify the type of the corresponding input host
variable.
Indicator value
Equivalent constant
Meaning of value
-1
sqlj.runtime.ExecutionContext.DBNull
Null
sqlj.runtime.ExecutionContext.DBNonNull
Non-null
-7 <= short-value < -1
0
short-value >0
For output, SQLJ supports the use of indicator variables for the following
statements:
v CALL with OUT or INOUT parameters
v FETCH iterator INTO host-variable
v SELECT ... INTO host-variable-1,...host-variable-n
SQLJ assigns one of the following values to an indicator variable to indicate
whether an SQL NULL value was retrieved into the corresponding host variable.
Indicator value
Equivalent constant
Meaning of value
-1
sqlj.runtime.ExecutionContext.DBNull
Retrieved value is SQL NULL
0
Retrieved value is not SQL NULL
You cannot use indicator variables to update result sets. To assign null values or
default values to result sets, or to indicate that columns are unassigned, call
ResultSet.updateObject on the underlying JDBC ResultSet objects of the SQLJ
iterators.
The following examples demonstrate how to use indicator variables.
All examples require that the data server supports extended indicators.
Example of using indicators to assign the default value to columns during an INSERT:
In this example, the MGRNO and LOCATION columns need to be set to their
default values. To do this, the code performs these steps:
1. Assigns the value ExecutionContext.DBNonNull to the indicator variables
(deptInd, dNameInd, rptDeptInd) for the input host variables (dept, dName,
rptDept) that send non-default values to the target columns.
2. Assigns the value ExecutionContext.DBDefault to the indicator variables
(mgrInd, locnInd) for the input host variables (mgr, locn) that send default
values to the target columns.
3. Executes an INSERT statement with the host variable and indicator variable
pairs as input.
The numbers to the right of selected statements correspond to the previously
described steps.
import
...
String
String
String
sqlj.runtime.*;
dept = "F01";
dName = "SHIPPING";
rptDept = "A00";
Chapter 4. SQLJ application programming
123
String mgr, locn = null;
short deptInd, dNameInd, mgrInd, rptDeptInd, locnInd;
// Set indicator variables for dept, dName, rptDept to non-null
deptInd = dNameInd = rptDeptInd = ExecutionContext.DBNonNull;
1
mgrInd = ExecutionContext.DBDefault;
2
locnInd = ExecutionContext.DBDefault;
#sql [ctxt]
3
{INSERT INTO DEPARTMENT
(DEPTNO, DEPTNAME, MGRNO, ADMRDEPT, LOCATION)
VALUES (:dept :deptInd, :dName :dNameInd,:mgr :mgrInd,
:rptDept :rptDeptInd, :locn :locnInd)};
Example of using indicators to assign the default value to leave column values unassigned
during an UPDATE:
In this example, in rows for department F01, the MGRNO column needs to be set
to its default value, the DEPTNAME column value needs to be changed to
RECEIVING, and the DEPTNO, DEPTNAME, ADMRDEPT, and LOCATION
columns need to remain unchanged. To do this, the code performs these steps:
1. Assigns the new value for the DEPTNAME column to the dName input host
variable.
2. Assigns the value ExecutionContext.DBDefault to the indicator variable
(mgrInd) for the input host variable (mgr) that sends the default value to the
target column.
3. Assigns the value ExecutionContext.DBUnassigned to the indicator variables
(deptInd, dNameInd, rptDeptInd, and locnInd) for the input host variables
(dept, dName, rptDept, and locn) that need to remain unchanged by the
UPDATE operation.
4. Executes an UPDATE statement with the host variable and indicator variable
pairs as input.
The numbers to the right of selected statements correspond to the previously
described steps.
import sqlj.runtime.*;
...
String dept = null;
String dName = "RECEIVING";
String rptDept = null;
String mgr, locn = null;
short deptInd, dNameInd, mgrInd, rptDeptInd, locnInd;
dNameInd = ExecutionContext.DBNonNull;
mgrInd = ExecutionContext.DBDefault;
deptInd = rptDeptInd = locnInd = ExecutionContext.DBUnassigned;
#sql [ctxt]
{UPDATE DEPARTMENT
SET DEPTNO = :dept :deptInd,
DEPTNAME = :dName :dNameInd,
MGRNO = :mgr :mgrInd,
ADMRDEPT = :rptDept :rptDeptInd,
LOCATION = :locn :locnInd
WHERE DEPTNO = "F01"
};
1
2
3
4
Example of using indicators to retrieve NULL values from columns:
In this example, the HIREDATE column can return the NULL value. To handle this
case, the code performs these steps:
1. Defines an indicator variable to indicate when the NULL value is returned from
HIREDATE.
124
Application Programming Guide and Reference for Java
2. Executes FETCH statements with the host variable and indicator variable pairs
as output.
3. Checks the indicator variable to determine whether a NULL value was
returned.
The numbers to the right of selected statements correspond to the previously
described steps.
import sqlj.runtime.*;
...
#sql iterator ByPos(String, Date);
{
...
ByPos positer;
String name = null;
Date hrdate = null;
short indhrdate = null;
#sql [ctxt] positer =
{SELECT LASTNAME, HIREDATE FROM
// Declare positioned iterator ByPos
// Declare object of ByPos class
// Declare host variables
1
// Declare indicator variable
EMPLOYEE};
// Assign the result table of the SELECT
// to iterator object positer
#sql {FETCH :positer INTO :name, :hrdate :indhrdate };
2
// Retrieve the first row
while (!positer.endFetch())
// Check whether the FETCH returned a row
{ if(indhrdate == ExecutionContext.DBNonNull {
3
System.out.println(name + " was hired in " +
hrdate); }
else {
System.out.println(name + " has no hire date "); }
#sql {FETCH :positer INTO :name, :hrdate };
// Fetch the next row
}
positer.close();
// Close the iterator
5
}
Example of assigning default values to result set columns:
In this example, the HIREDATE column in a result set needs to be set to its default
value. To do this, the code performs these steps:
1. Retrieves the underlying ResultSet from the iterator that holds the retrieved
data.
2. Executes the ResultSet.updateObject method with the
DB2PreparedStatement.DB_PARAMETER_DEFAULT constant to assign the default
value to the result set column.
The numbers to the right of selected statements correspond to the previously
described steps.
#sql public iterator sensitiveUpdateIter
implements sqlj.runtime.Scrollable, sqlj.runtime.ForUpdate
with (sensitivity=sqlj.runtime.ResultSetIterator.SENSITIVE,
updateColumns="LASTNAME, HIREDATE") (String, Date);
String name;
Date hrdate;
// Declare host variables
sensitiveUpdateIter iter = null;
#sql [ctx] iter = { SELECT LASTNAME, HIREDATE FROM EMPLOYEE};
iter.next();
java.sql.ResultSet rs = iter.getResultSet();
rs.updateString("LASTNAME", "FORREST");
1
Chapter 4. SQLJ application programming
125
rs.updateObject
(2, com.ibm.db2.jcc.DB2PreparedStatement.DB_PARAMETER_DEFAULT);); 2,3
rs.updateRow();
iter.close();
Comments in an SQLJ application
To document your SQLJ program, you need to include comments. To do that, use
Java comments. Java comments are denoted by /* */ or //.
You can include Java comments outside SQLJ clauses, wherever the Java language
permits them. Within an SQLJ clause, you can use Java comments in the following
places:
v Within a host expression (/* */ or //).
v Within an SQL statement in an executable clause, if the data source supports a
comment within the SQL statement (/* */ or --).
/* and */ pairs in an SQL statement can be nested.
SQL statement execution in SQLJ applications
You execute SQL statements in a traditional SQL program to create tables, update
data in tables, retrieve data from the tables, call stored procedures, or commit or
roll back transactions. In an SQLJ program, you also execute these statements,
within SQLJ executable clauses.
An executable clause can have one of the following general forms:
#sql [connection-context] {sql-statement};
#sql [connection-context,execution-context] {sql-statement};
#sql [execution-context] {sql-statement};
execution-context specification
In an executable clause, you should always specify an explicit connection
context, with one exception: you do not specify an explicit connection context
for a FETCH statement. You include an execution context only for specific
cases. See "Control the execution of SQL statements in SQLJ" for information
about when you need an execution context.
connection-context specification
In an executable clause, if you do not explicitly specify a connection context,
the executable clause uses the default connection context.
Creating and modifying database objects in an SQLJ
application
Use SQLJ executable clauses to execute data definition statements (CREATE,
ALTER, DROP, GRANT, REVOKE) or to execute INSERT, searched or positioned
UPDATE, and searched or positioned DELETE statements.
The following executable statements demonstrate an INSERT, a searched UPDATE,
and a searched DELETE:
#sql [myConnCtx] {INSERT INTO DEPARTMENT VALUES
("X00","Operations 2","000030","E01",NULL)};
#sql [myConnCtx] {UPDATE DEPARTMENT
SET MGRNO="000090" WHERE MGRNO="000030"};
#sql [myConnCtx] {DELETE FROM DEPARTMENT
WHERE DEPTNO="X00"};
126
Application Programming Guide and Reference for Java
Performing positioned UPDATE and DELETE operations in an
SQLJ application
As in DB2 applications in other languages, performing positioned UPDATEs and
DELETEs with SQLJ is an extension of retrieving rows from a result table.
The basic steps are:
1. Declare the iterator.
The iterator can be positioned or named. For positioned UPDATE or DELETE
operations, declare the iterator as updatable, using one or both of the following
clauses:
implements sqlj.runtime.ForUpdate
This clause causes the generated iterator class to include methods for
using updatable iterators. This clause is required for programs with
positioned UPDATE or DELETE operations.
with (updateColumns="column-list")
This clause specifies a comma-separated list of the columns of the result
table that the iterator will update. This clause is optional.
You need to declare the iterator as public, so you need to follow the rules for
declaring and using public iterators in the same file or different files.
If you declare the iterator in a file by itself, any SQLJ source file that has
addressability to the iterator and imports the generated class can retrieve data
and execute positioned UPDATE or DELETE statements using the iterator.
The authorization ID under which a positioned UPDATE or DELETE statement
executes depends on whether the statement executes statically or dynamically.
If the statement executes statically, the authorization ID is the owner of the plan
or package that includes the statement. If the statement executes dynamically
the authorization ID is determined by the DYNAMICRULES behavior that is in
effect. For the IBM Data Server Driver for JDBC and SQLJ, the behavior is
always DYNAMICRULES BIND.
2. Disable autocommit mode for the connection.
If autocommit mode is enabled, a COMMIT operation occurs every time the
positioned UPDATE statement executes, which causes the iterator to be
destroyed unless the iterator has the with (holdability=true) attribute.
Therefore, you need to turn autocommit off to prevent COMMIT operations
until you have finished using the iterator. If you want a COMMIT to occur
after every update operation, an alternative way to keep the iterator from being
destroyed after each COMMIT operation is to declare the iterator with
(holdability=true).
3. Create an instance of the iterator class.
This is the same step as for a non-updatable iterator.
4. Assign the result table of a SELECT to an instance of the iterator.
This is the same step as for a non-updatable iterator. The SELECT statement
must not include a FOR UPDATE clause.
5. Retrieve and update rows.
For a positioned iterator, do this by performing the following actions in a loop:
a. Execute a FETCH statement in an executable clause to obtain the current
row.
b. Test whether the iterator is pointing to a row of the result table by invoking
the PositionedIterator.endFetch method.
Chapter 4. SQLJ application programming
127
c. If the iterator is pointing to a row of the result table, execute an SQL
UPDATE... WHERE CURRENT OF :iterator-object statement in an executable
clause to update the columns in the current row. Execute an SQL DELETE...
WHERE CURRENT OF :iterator-object statement in an executable clause to
delete the current row.
For a named iterator, do this by performing the following actions in a loop:
a. Invoke the next method to move the iterator forward.
b. Test whether the iterator is pointing to a row of the result table by checking
whether next returns true.
c. Execute an SQL UPDATE... WHERE CURRENT OF iterator-object statement
in an executable clause to update the columns in the current row. Execute
an SQL DELETE... WHERE CURRENT OF iterator-object statement in an
executable clause to delete the current row.
6. Close the iterator.
Use the close method to do this.
The following code shows how to declare a positioned iterator and use it for
positioned UPDATEs. The numbers to the right of selected statements correspond
to the previously described steps.
First, in one file, declare positioned iterator UpdByPos, specifying that you want to
use the iterator to update column SALARY:
import java.math.*;
// Import this class for BigDecimal data type
#sql public iterator UpdByPos implements sqlj.runtime.ForUpdate
1
with(updateColumns="SALARY") (String, BigDecimal);
Figure 27. Example of declaring a positioned iterator for a positioned UPDATE
Then, in another file, use UpdByPos for a positioned UPDATE, as shown in the
following code fragment:
128
Application Programming Guide and Reference for Java
import
import
import
import
sqlj.runtime.*;
java.sql.*;
java.math.*;
UpdByPos;
// Import files for SQLJ and JDBC APIs
// Import this class for BigDecimal data type
// Import the generated iterator class that
// was created by the iterator declaration clause
// for UpdByName in another file
#sql context HSCtx;
// Create a connnection context class HSCtx
public static void main (String args[])
{
try {
Class.forName("com.ibm.db2.jcc.DB2Driver");
}
catch (ClassNotFoundException e) {
e.printStackTrace();
}
Connection HSjdbccon=
DriverManager.getConnection("jdbc:db2:SANJOSE");
// Create a JDBC connection object
HSjdbccon.setAutoCommit(false);
// Set autocommit off so automatic commits
2
// do not destroy the cursor between updates
HSCtx myConnCtx=new HSCtx(HSjdbccon);
// Create a connection context object
UpdByPos upditer; // Declare iterator object of UpdByPos class
3
String empnum;
// Declares host variable to receive EMPNO
BigDecimal sal;
// and SALARY column values
#sql [myConnCtx]
upditer = {SELECT EMPNO, SALARY FROM EMPLOYEE
4
WHERE WORKDEPT=’D11’};
// Assign result table to iterator object
#sql {FETCH :upditer INTO :empnum,:sal};
5a
// Move cursor to next row
while (!upditer.endFetch())
5b
// Check if on a row
{
#sql [myConnCtx] {UPDATE EMPLOYEE SET SALARY=SALARY*1.05
WHERE CURRENT OF :upditer};
5c
// Perform positioned update
System.out.println("Updating row for " + empnum);
#sql {FETCH :upditer INTO :empnum,:sal};
// Move cursor to next row
}
upditer.close();
// Close the iterator
6
#sql [myConnCtx] {COMMIT};
// Commit the changes
myConnCtx.close();
// Close the connection context
}
Figure 28. Example of performing a positioned UPDATE with a positioned iterator
The following code shows how to declare a named iterator and use it for
positioned UPDATEs. The numbers to the right of selected statements correspond
to the previously described steps.
First, in one file, declare named iterator UpdByName, specifying that you want to use
the iterator to update column SALARY:
import java.math.*;
// Import this class for BigDecimal data type
#sql public iterator UpdByName implements sqlj.runtime.ForUpdate
1
with(updateColumns="SALARY") (String EmpNo, BigDecimal Salary);
Figure 29. Example of declaring a named iterator for a positioned UPDATE
Chapter 4. SQLJ application programming
129
Then, in another file, use UpdByName for a positioned UPDATE, as shown in the
following code fragment:
import
import
import
import
sqlj.runtime.*;
java.sql.*;
java.math.*;
UpdByName;
// Import files for SQLJ and JDBC APIs
// Import this class for BigDecimal data type
// Import the generated iterator class that
// was created by the iterator declaration clause
// for UpdByName in another file
#sql context HSCtx;
// Create a connnection context class HSCtx
public static void main (String args[])
{
try {
Class.forName("com.ibm.db2.jcc.DB2Driver");
}
catch (ClassNotFoundException e) {
e.printStackTrace();
}
Connection HSjdbccon=
DriverManager.getConnection("jdbc:db2:SANJOSE");
// Create a JDBC connection object
HSjdbccon.setAutoCommit(false);
// Set autocommit off so automatic commits 2
// do not destroy the cursor between updates
HSCtx myConnCtx=new HSCtx(HSjdbccon);
// Create a connection context object
UpdByName upditer;
3
// Declare iterator object of UpdByName class
String empnum;
// Declare host variable to receive EmpNo
// column values
#sql [myConnCtx]
upditer = {SELECT EMPNO, SALARY FROM EMPLOYEE
4
WHERE WORKDEPT=’D11’};
// Assign result table to iterator object
while (upditer.next())
5a,5b
// Move cursor to next row and
// check ifon a row
{
empnum = upditer.EmpNo(); // Get employee number from current row
#sql [myConnCtx]
{UPDATE EMPLOYEE SET SALARY=SALARY*1.05
WHERE CURRENT OF :upditer};
5c
// Perform positioned update
System.out.println("Updating row for " + empnum);
}
upditer.close();
// Close the iterator
6
#sql [myConnCtx] {COMMIT};
// Commit the changes
myConnCtx.close();
// Close the connection context
}
Figure 30. Example of performing a positioned UPDATE with a named iterator
130
Application Programming Guide and Reference for Java
Related concepts
“Iterators as passed variables for positioned UPDATE or DELETE operations in an
SQLJ application”
“Data retrieval in SQLJ applications” on page 137
Authorization IDs and dynamic SQL (DB2 SQL)
Related tasks
“Creating and modifying database objects in an SQLJ application” on page 126
“Connecting to a data source using SQLJ” on page 113
Iterators as passed variables for positioned UPDATE or DELETE
operations in an SQLJ application
SQLJ allows iterators to be passed between methods as variables.
An iterator that is used for a positioned UPDATE or DELETE statement can be
identified only at runtime. The same SQLJ positioned UPDATE or DELETE
statement can be used with different iterators at runtime. If you specify a value of
YES for -staticpositioned when you customize your SQLJ application as part of the
program preparation process, the SQLJ customizer prepares positioned UPDATE or
DELETE statements to execute statically. In this case, the customizer must
determine which iterators belong with which positioned UPDATE or DELETE
statements. The SQLJ customizer does this by matching iterator data types to data
types in the UPDATE or DELETE statements. However, if there is not a unique
mapping of tables in UPDATE or DELETE statements to iterator classes, the SQLJ
customizer cannot determine exactly which iterators and UPDATE or DELETE
statements go together. The SQLJ customizer must arbitrarily pair iterators with
UPDATE or DELETE statements, which can sometimes result in SQL errors. The
following code fragments illustrate this point.
#sql iterator GeneralIter implements sqlj.runtime.ForUpdate
( String );
public static void main ( String args[] )
{
...
GeneralIter iter1 = null;
#sql [ctxt] iter1 = { SELECT CHAR_COL1 FROM TABLE1 };
GeneralIter iter2 = null;
#sql [ctxt] iter2 = { SELECT CHAR_COL2 FROM TABLE2 };
...
doUpdate ( iter1 );
}
public static void doUpdate ( GeneralIter iter )
{
#sql [ctxt] { UPDATE TABLE1 ... WHERE CURRENT OF :iter };
}
Figure 31. Static positioned UPDATE that fails
In this example, only one iterator is declared. Two instances of that iterator are
declared, and each is associated with a different SELECT statement that retrieves
data from a different table. During customization and binding with
-staticpositioned YES, SQLJ creates two DECLARE CURSOR statements, one for
each SELECT statement, and attempts to bind an UPDATE statement for each
cursor. However, the bind process fails with SQLCODE -509 when UPDATE TABLE1
Chapter 4. SQLJ application programming
131
... WHERE CURRENT OF :iter is bound for the cursor for SELECT CHAR_COL2 FROM
TABLE2 because the table for the UPDATE does not match the table for the cursor.
You can avoid a bind time error for a program like the one in Figure 31 on page
131 by specifying the bind option SQLERROR(CONTINUE). However, this
technique has the drawback that it causes the DB2 database manager to build a
package, regardless of the SQL errors that are in the program. A better technique is
to write the program so that there is a one-to-one mapping between tables in
positioned UPDATE or DELETE statements and iterator classes. Figure 32 shows
an example of how to do this.
#sql iterator Table2Iter(String);
#sql iterator Table1Iter(String);
public static void main ( String args[] )
{
...
Table2Iter iter2 = null;
#sql [ctxt] iter2 = { SELECT CHAR_COL2 FROM TABLE2 };
Table1Iter iter1 = null;
#sql [ctxt] iter1 = { SELECT CHAR_COL1 FROM TABLE1 };
...
doUpdate(iter1);
}
public static void doUpdate ( Table1Iter
{
...
#sql [ctxt] { UPDATE TABLE1 ... WHERE
...
}
public static void doUpdate ( Table2Iter
{
...
#sql [ctxt] { UPDATE TABLE2 ... WHERE
...
}
iter )
CURRENT OF :iter };
iter )
CURRENT OF :iter };
Figure 32. Static positioned UPDATE that succeeds
With this method of coding, each iterator class is associated with only one table.
Therefore, the DB2 bind process can always associate the positioned UPDATE
statement with a valid iterator.
Making batch updates in SQLJ applications
The IBM Data Server Driver for JDBC and SQLJ supports batch updates in SQLJ.
With batch updates, instead of updating rows of a table one at a time, you can
direct SQLJ to execute a group of updates at the same time.
You can include the following types of statements in a batch update:
v Searched INSERT, UPDATE, or DELETE, or MERGE statements
v CREATE, ALTER, DROP, GRANT, or REVOKE statements
v CALL statements with input parameters only
Unlike JDBC, SQLJ allows heterogeneous batches that contain statements with
input parameters or host expressions. You can therefore combine any of the
following items in an SQLJ batch:
v Instances of the same statement
v Different statements
132
Application Programming Guide and Reference for Java
v Statements with different numbers of input parameters or host expressions
v Statements with different data types for input parameters or host expressions
v Statements with no input parameters or host expressions
For all cases except homogeneous batches of INSERT statements, when an error
occurs during execution of a statement in a batch, the remaining statements are
executed, and a BatchUpdateException is thrown after all the statements in the
batch have executed.
For homogeneous batches of INSERT statements, the behavior is as follows:
v If you set atomicMultiRowInsert to DB2BaseDataSource.YES (1) when you run
db2sqljcustomize, and the target data server is DB2 for z/OS, when an error
occurs during execution of an INSERT statement in a batch, the remaining
statements are not executed, and a BatchUpdateException is thrown.
v If you do not set atomicMultiRowInsert to DB2BaseDataSource.YES (1) when you
run db2sqljcustomize, or the target data server is not DB2 for z/OS, when an
error occurs during execution of an INSERT statement in a batch, the remaining
statements are executed, and a BatchUpdateException is thrown after all the
statements in the batch have executed.
To obtain information about warnings, use the ExecutionContext.getWarnings
method on the ExecutionContext that you used to submit statements to be
batched. You can then retrieve an error description, SQLSTATE, and error code for
each SQLWarning object.
When a batch is executed implicitly because the program contains a statement that
cannot be added to the batch, the batch is executed before the new statement is
processed. If an error occurs during execution of the batch, the statement that
caused the batch to execute does not execute.
The basic steps for creating, executing, and deleting a batch of statements are:
1. Disable AutoCommit for the connection.
Do this so that you can control whether to commit changes to already-executed
statements when an error occurs during batch execution.
2. Acquire an execution context.
All statements that execute in a batch must use this execution context.
3. Invoke the ExecutionContext.setBatching(true) method to create a batch.
Subsequent batchable statements that are associated with the execution context
that you created in step 2 are added to the batch for later execution.
If you want to batch sets of statements that are not batch compatible in parallel,
you need to create an execution context for each set of batch compatible
statements.
4. Include SQLJ executable clauses for SQL statements that you want to batch.
These clauses must include the execution context that you created in step 2.
If an SQLJ executable clause has input parameters or host expressions, you can
include the statement in the batch multiple times with different values for the
input parameters or host expressions.
To determine whether a statement was added to an existing batch, was the first
statement in a new batch, or was executed inside or outside a batch, invoke the
ExecutionContext.getUpdateCount method. This method returns one of the
following values:
Chapter 4. SQLJ application programming
133
ExecutionContext.ADD_BATCH_COUNT
This is a constant that is returned if the statement was added to an existing
batch.
ExecutionContext.NEW_BATCH_COUNT
This is a constant that is returned if the statement was the first statement in
a new batch.
ExecutionContext.EXEC_BATCH_COUNT
This is a constant that is returned if the statement was part of a batch, and
the batch was executed.
Other integer
This value is the number of rows that were updated by the statement. This
value is returned if the statement was executed rather than added to a
batch.
5. Execute the batch explicitly or implicitly.
v Invoke the ExecutionContext.executeBatch method to execute the batch
explicitly.
executeBatch returns an integer array that contains the number of rows that
were updated by each statement in the batch. The order of the elements in
the array corresponds to the order in which you added statements to the
batch.
v Alternatively, a batch executes implicitly under the following circumstances:
– You include a batchable statement in your program that is not compatible
with statements that are already in the batch. In this case, SQLJ executes
the statements that are already in the batch and creates a new batch that
includes the incompatible statement.
– You include a statement in your program that is not batchable. In this
case, SQLJ executes the statements that are already in the batch. SQLJ also
executes the statement that is not batchable.
– After you invoke the ExecutionContext.setBatchLimit(n) method, you
add a statement to the batch that brings the number of statements in the
batch to n or greater. n can have one of the following values:
ExecutionContext.UNLIMITED_BATCH
This constant indicates that implicit execution occurs only when SQLJ
encounters a statement that is batchable but incompatible, or not
batchable. Setting this value is the same as not invoking
setBatchLimit.
ExecutionContext.AUTO_BATCH
This constant indicates that implicit execution occurs when the
number of statements in the batch reaches a number that is set by
SQLJ.
Positive integer
When this number of statements have been added to the batch, SQLJ
executes the batch implicitly. However, the batch might be executed
before this many statements have been added if SQLJ encounters a
statement that is batchable but incompatible, or not batchable.
To determine the number of rows that were updated by a batch that was
executed implicitly, invoke the ExecutionContext.getBatchUpdateCounts
method. getBatchUpdateCounts returns an integer array that contains the
number of rows that were updated by each statement in the batch. The order
134
Application Programming Guide and Reference for Java
of the elements in the array corresponds to the order in which you added
statements to the batch. Each array element can be one of the following
values:
-2 This value indicates that the SQL statement executed successfully, but the
number of rows that were updated could not be determined.
-3 This value indicates that the SQL statement failed.
Other integer
This value is the number of rows that were updated by the statement.
6. Optionally, when all statements have been added to the batch, disable batching.
Do this by invoking the ExecutionContext.setBatching(false) method. When
you disable batching, you can still execute the batch implicitly or explicitly, but
no more statements are added to the batch. Disabling batching is useful when a
batch already exists, and you want to execute a batch compatible statement,
rather than adding it to the batch.
If you want to clear a batch without executing it, invoke the
ExecutionContext.cancel method.
7. If batch execution was implicit, perform a final, explicit executeBatch to ensure
that all statements have been executed.
Example
The following example demonstrates batching of UPDATE statements. The
numbers to the right of selected statements correspond to the previously described
steps.
#sql iterator GetMgr(String);
// Declare positioned iterator
...
{
GetMgr deptiter;
// Declare object of GetMgr class
String mgrnum = null;
// Declare host variable for manager number
int raise = 400;
// Declare raise amount
int currentSalary;
// Declare current salary
String url, username, password;
// Declare url, user ID, password
...
TestContext c1 = new TestContext (url, username, password, false); 1
ExecutionContext ec = new ExecutionContext();
2
ec.setBatching(true);
3
#sql [c1] deptiter =
{SELECT MGRNO FROM DEPARTMENT};
// Assign the result table of the SELECT
// to iterator object deptiter
#sql {FETCH :deptiter INTO :mgrnum};
// Retrieve the first manager number
while (!deptiter.endFetch()) {
// Check whether the FETCH returned a row
#sql [c1]
{SELECT SALARY INTO :currentSalary FROM EMPLOYEE
WHERE EMPNO=:mgrnum};
#sql [c1, ec]
4
{UPDATE EMPLOYEE SET SALARY=:(currentSalary+raise)
WHERE EMPNO=:mgrnum};
#sql {FETCH :deptiter INTO :mgrnum };
// Fetch the next row
}
ec.executeBatch();
5
ec.setBatching(false);
6
#sql [c1] {COMMIT};
deptiter.close();
// Close the iterator
c1.close();
// Close the connection
}
Chapter 4. SQLJ application programming
135
The following example demonstrates batching of INSERT statements. Suppose that
ATOMICTBL is defined like this:
CREATE TABLE ATOMICTBL(
INTCOL INTEGER NOT NULL UNIQUE,
CHARCOL VARCHAR(10))
Also suppose that the table already has a row with the values 2 and "val2".
Because of the uniqueness constraint on INTCOL, when the following code is
executed, the second INSERT statement in the batch fails.
If the target data server is DB2 for z/OS, and this application is customized
without atomicMultiRowInsert set to DB2BaseDataSource.YES, the batch INSERT is
non-atomic, so the first set of values is inserted in the table. However, if the
application is customized with atomicMultiRowInsert set to
DB2BaseDataSource.YES, the batch INSERT is atomic, so the first set of values is not
inserted.
The numbers to the right of selected statements correspond to the previously
described steps.
...
TestContext ctx = new TestContext (url, username, password, false); 1
ctx.getExecutionContext().setBatching(true);
2,3
try {
for (int i = 1; i<= 2; ++i) {
if (i == 1) {
intVar = 3;
strVar = "val1";
{
if (i == 2) {
intVar = 1;
strVar = "val2";
}
#sql [ctx] {INSERT INTO ATOMICTBL values(:intVar, :strVar)};
4
}
int[] counts = ctx.getExecutionContext().executeBatch();
5
for (int i = 0; i<counts.length; ++i) {
System.out.println(" count[" + i + "]:" + counts[i]);
}
}
catch (SQLException e) {
System.out.println(" Exception Caught: " + e.getMessage());
SQLException excp = null;
if (e instanceof SQLException)
{
System.out.println(" SQLCode: " + ((SQLException)e).getErrorCode() + "
Message: " + e.getMessage() );
excp = ((SQLException)e).getNextException();
while ( excp != null ) {
System.out.println(" SQLCode: " + ((SQLException)excp).getErrorCode() +
" Message: " + excp.getMessage() );
excp = excp.getNextException();
}
}
}
136
Application Programming Guide and Reference for Java
Related tasks
“Connecting to a data source using SQLJ” on page 113
“Controlling the execution of SQL statements in SQLJ” on page 155
Related reference
“sqlj.runtime.SQLNullException class” on page 345
“db2sqljcustomize - SQLJ profile customizer” on page 454
Data retrieval in SQLJ applications
SQLJ applications use a result set iterator to retrieve result sets. Like a cursor, a
result set iterator can be non-scrollable or scrollable.
Just as in DB2 applications in other languages, if you want to retrieve a single row
from a table in an SQLJ application, you can write a SELECT INTO statement with
a WHERE clause that defines a result table that contains only that row:
#sql [myConnCtx] {SELECT DEPTNO INTO :hvdeptno
FROM DEPARTMENT WHERE DEPTNAME="OPERATIONS"};
However, most SELECT statements that you use create result tables that contain
many rows. In DB2 applications in other languages, you use a cursor to select the
individual rows from the result table. That cursor can be non-scrollable, which
means that when you use it to fetch rows, you move the cursor serially, from the
beginning of the result table to the end. Alternatively, the cursor can be scrollable,
which means that when you use it to fetch rows, you can move the cursor
forward, backward, or to any row in the result table.
This topic discusses how to use non-scrollable iterators. For information on using
scrollable iterators, see "Use scrollable iterators in an SQLJ application".
A result set iterator is a Java object that you use to retrieve rows from a result
table. Unlike a cursor, a result set iterator can be passed as a parameter to a
method.
The basic steps in using a result set iterator are:
1. Declare the iterator, which results in an iterator class
2. Define an instance of the iterator class.
3. Assign the result table of a SELECT to an instance of the iterator.
4. Retrieve rows.
5. Close the iterator.
There are two types of iterators: positioned iterators and named iterators. Postitioned
iterators extend the interface sqlj.runtime.PositionedIterator. Positioned
iterators identify the columns of a result table by their position in the result table.
Named iterators extend the interface sqlj.runtime.NamedIterator. Named iterators
identify the columns of the result table by result table column names.
Using a named iterator in an SQLJ application
Use a named iterator to refer to each of the columns in a result table by name.
The steps in using a named iterator are:
1. Declare the iterator.
You declare any result set iterator using an iterator declaration clause. This causes
an iterator class to be created that has the same name as the iterator. For a
named iterator, the iterator declaration clause specifies the following
information:
Chapter 4. SQLJ application programming
137
v The name of the iterator
v A list of column names and Java data types
v Information for a Java class declaration, such as whether the iterator is
public or static
v A set of attributes, such as whether the iterator is holdable, or whether its
columns can be updated
When you declare a named iterator for a query, you specify names for each of
the iterator columns. Those names must match the names of columns in the
result table for the query. An iterator column name and a result table column
name that differ only in case are considered to be matching names. The named
iterator class that results from the iterator declaration clause contains accessor
methods. There is one accessor method for each column of the iterator. Each
accessor method name is the same as the corresponding iterator column name.
You use the accessor methods to retrieve data from columns of the result table.
You need to specify Java data types in the iterators that closely match the
corresponding DB2 column data types. See "Java, JDBC, and SQL data types"
for a list of the best mappings between Java data types and DB2 data types.
You can declare an iterator in a number of ways. However, because a Java class
underlies each iterator, you need to ensure that when you declare an iterator,
the underlying class obeys Java rules. For example, iterators that contain a
with-clause must be declared as public. Therefore, if an iterator needs to be
public, it can be declared only where a public class is allowed. The following
list describes some alternative methods of declaring an iterator:
v As public, in a source file by itself
This method lets you use the iterator declaration in other code modules, and
provides an iterator that works for all SQLJ applications. In addition, there
are no concerns about having other top-level classes or public classes in the
same source file.
v As a top-level class in a source file that contains other top-level class
definitions
Java allows only one public, top-level class in a code module. Therefore, if
you need to declare the iterator as public, such as when the iterator includes
a with-clause, no other classes in the code module can be declared as public.
v As a nested static class within another class
Using this alternative lets you combine the iterator declaration with other
class declarations in the same source file, declare the iterator and other
classes as public, and make the iterator class visible to other code modules or
packages. However, when you reference the iterator from outside the nesting
class, you must fully-qualify the iterator name with the name of the nesting
class.
v As an inner class within another class
When you declare an iterator in this way, you can instantiate it only within
an instance of the nesting class. However, you can declare the iterator and
other classes in the file as public.
You cannot cast a JDBC ResultSet to an iterator if the iterator is declared as
an inner class. This restriction does not apply to an iterator that is declared
as a static nested class. See "Use SQLJ and JDBC in the same application" for
more information on casting a ResultSet to a iterator.
2. Create an instance of the iterator class.
You declare an object of the named iterator class to retrieve rows from a result
table.
138
Application Programming Guide and Reference for Java
3. Assign the result table of a SELECT to an instance of the iterator.
To assign the result table of a SELECT to an iterator, you use an SQLJ
assignment clause. The format of the assignment clause for a named iterator is:
#sql context-clause iterator-object={select-statement};
See "SQLJ assignment-clause" and "SQLJ context-clause" for more information.
4. Retrieve rows.
Do this by invoking accessor methods in a loop. Accessor methods have the
same names as the corresponding columns in the iterator, and have no
parameters. An accessor method returns the value from the corresponding
column of the current row in the result table. Use the NamedIterator.next()
method to move the cursor forward through the result table.
To test whether you have retrieved all rows, check the value that is returned
when you invoke the next method. next returns a boolean with a value of
false if there is no next row.
5. Close the iterator.
Use the NamedIterator.close method to do this.
The following code demonstrates how to declare and use a named iterator. The
numbers to the right of selected statements correspond to the previously-described
steps.
#sql
iterator ByName(String LastName, Date HireDate);
// Declare named iterator ByName
1
{
...
ByName nameiter;
// Declare object of ByName class
2
#sql [ctxt]
nameiter={SELECT LASTNAME, HIREDATE FROM EMPLOYEE};
3
// Assign the result table of the SELECT
// to iterator object nameiter
while (nameiter.next())
// Move the iterator through the result 4
// table and test whether all rows retrieved
{
System.out.println( nameiter.LastName() + " was hired on "
+ nameiter.HireDate());
// Use accessor methods LastName and
// HireDate to retrieve column values
}
nameiter.close();
// Close the iterator
5
}
Figure 33. Example of using a named iterator
Related tasks
“Performing positioned UPDATE and DELETE operations in an SQLJ application”
on page 127
“Using a positioned iterator in an SQLJ application”
Using a positioned iterator in an SQLJ application
Use a positioned iterator to refer to columns in a result table by their position in
the result set.
The steps in using a positioned iterator are:
1. Declare the iterator.
You declare any result set iterator using an iterator declaration clause. This causes
an iterator class to be created that has the same name and attributes as the
iterator. For a positioned iterator, the iterator declaration clause specifies the
following information:
Chapter 4. SQLJ application programming
139
v The name of the iterator
v A list of Java data types
v Information for a Java class declaration, such as whether the iterator is
public or static
v A set of attributes, such as whether the iterator is holdable, or whether its
columns can be updated
The data type declarations represent columns in the result table and are
referred to as columns of the result set iterator. The columns of the result set
iterator correspond to the columns of the result table, in left-to-right order. For
example, if an iterator declaration clause has two data type declarations, the
first data type declaration corresponds to the first column in the result table,
and the second data type declaration corresponds to the second column in the
result table.
You need to specify Java data types in the iterators that closely match the
corresponding DB2 column data types. See "Java, JDBC, and SQL data types"
for a list of the best mappings between Java data types and DB2 data types.
You can declare an iterator in a number of ways. However, because a Java class
underlies each iterator, you need to ensure that when you declare an iterator,
the underlying class obeys Java rules. For example, iterators that contain a
with-clause must be declared as public. Therefore, if an iterator needs to be
public, it can be declared only where a public class is allowed. The following
list describes some alternative methods of declaring an iterator:
v As public, in a source file by itself
This is the most versatile method of declaring an iterator. This method lets
you use the iterator declaration in other code modules, and provides an
iterator that works for all SQLJ applications. In addition, there are no
concerns about having other top-level classes or public classes in the same
source file.
v As a top-level class in a source file that contains other top-level class
definitions
Java allows only one public, top-level class in a code module. Therefore, if
you need to declare the iterator as public, such as when the iterator includes
a with-clause, no other classes in the code module can be declared as public.
v As a nested static class within another class
Using this alternative lets you combine the iterator declaration with other
class declarations in the same source file, declare the iterator and other
classes as public, and make the iterator class visible from other code modules
or packages. However, when you reference the iterator from outside the
nesting class, you must fully-qualify the iterator name with the name of the
nesting class.
v As an inner class within another class
When you declare an iterator in this way, you can instantiate it only within
an instance of the nesting class. However, you can declare the iterator and
other classes in the file as public.
You cannot cast a JDBC ResultSet to an iterator if the iterator is declared as
an inner class. This restriction does not apply to an iterator that is declared
as a static nested class. See "Use SQLJ and JDBC in the same application" for
more information on casting a ResultSet to a iterator.
2. Create an instance of the iterator class.
You declare an object of the positioned iterator class to retrieve rows from a
result table.
140
Application Programming Guide and Reference for Java
3. Assign the result table of a SELECT to an instance of the iterator.
To assign the result table of a SELECT to an iterator, you use an SQLJ
assignment clause. The format of the assignment clause for a positioned iterator
is:
#sql context-clause iterator-object={select-statement};
4. Retrieve rows.
Do this by executing FETCH statements in executable clauses in a loop. The
FETCH statements looks the same as a FETCH statements in other languages.
To test whether you have retrieved all rows, invoke the
PositionedIterator.endFetch method after each FETCH. endFetch returns a
boolean with the value true if the FETCH failed because there are no rows to
retrieve.
5. Close the iterator.
Use the PositionedIterator.close method to do this.
The following code demonstrates how to declare and use a positioned iterator. The
numbers to the right of selected statements correspond to the previously-described
steps.
#sql iterator ByPos(String,Date); // Declare positioned iterator ByPos 1
{
...
ByPos positer;
// Declare object of ByPos class
2
String name = null;
// Declare host variables
Date hrdate;
#sql [ctxt] positer =
{SELECT LASTNAME, HIREDATE FROM EMPLOYEE};
3
// Assign the result table of the SELECT
// to iterator object positer
#sql {FETCH :positer INTO :name, :hrdate };
4
// Retrieve the first row
while (!positer.endFetch())
// Check whether the FETCH returned a row
{ System.out.println(name + " was hired in " +
hrdate);
#sql {FETCH :positer INTO :name, :hrdate };
// Fetch the next row
}
positer.close();
// Close the iterator
5
}
Figure 34. Example of using a positioned iterator
Related concepts
“Data retrieval in SQLJ applications” on page 137
Related tasks
“Performing positioned UPDATE and DELETE operations in an SQLJ application”
on page 127
“Using a named iterator in an SQLJ application” on page 137
Multiple open iterators for the same SQL statement in an SQLJ
application
With the IBM Data Server Driver for JDBC and SQLJ, your application can have
multiple concurrently open iterators for a single SQL statement in an SQLJ
application. With this capability, you can perform one operation on a table using
one iterator while you perform a different operation on the same table using
another iterator.
Chapter 4. SQLJ application programming
141
For IBM Data Server Driver for JDBC and SQLJ type 2 connectivity to DB2 for
z/OS, support for multiple open iterators on a single SQL statement must be
enabled. To do that, set the db2.jcc.allowSqljDuplicateStaticQueries configuration
property to YES or true.
When you use concurrently open iterators in an application, you should close
iterators when you no longer need them to prevent excessive storage consumption
in the Java heap.
The following examples demonstrate how to perform the same operations on a
table without concurrently open iterators on a single SQL statement and with
concurrently open iterators on a single SQL statement. These examples use the
following iterator declaration:
import java.math.*;
#sql public iterator
MultiIter(String EmpNo, BigDecimal Salary);
Without the capability for multiple, concurrently open iterators for a single SQL
statement, if you want to select employee and salary values for a specific employee
number, you need to define a different SQL statement for each employee number,
as shown in Figure 35.
MultiIter iter1 = null;
// Iterator instance for retrieving
// data for first employee
// Employee number for first employee
String EmpNo1 = "000100";
#sql [ctx] iter1 =
{SELECT EMPNO, SALARY FROM EMPLOYEE
//
MultiIter iter2 = null;
//
//
String EmpNo2 = "000200";
//
#sql [ctx] iter2 =
{SELECT EMPNO, SALARY FROM EMPLOYEE
//
// Process with iter1
// Process with iter2
iter1.close();
//
iter2.close();
WHERE EMPNO = :EmpNo1};
Assign result table to first iterator
Iterator instance for retrieving
data for second employee
Employee number for second employee
WHERE EMPNO = :EmpNo2};
Assign result table to second iterator
Close the iterators
Figure 35. Example of concurrent table operations using iterators with different SQL
statements
Figure 36 on page 143 demonstrates how you can perform the same operations
when you have the capability for multiple, concurrently open iterators for a single
SQL statement.
142
Application Programming Guide and Reference for Java
...
MultiIter iter1 = openIter("000100"); // Invoke openIter to assign the result table
// (for employee 100) to the first iterator
MultiIter iter2 = openIter("000200"); // Invoke openIter to assign the result
// table to the second iterator
// iter1 stays open when iter2 is opened
// Process with iter1
// Process with iter2
...
iter1.close();
// Close the iterators
iter2.close();
...
public MultiIter openIter(String EmpNo)
// Method to assign a result table
// to an iterator instance
{
MultiIter iter;
#sql [ctxt] iter =
{SELECT EMPNO, SALARY FROM EMPLOYEE WHERE EMPNO = :EmpNo};
return iter;
// Method returns an iterator instance
}
Figure 36. Example of concurrent table operations using iterators with the same SQL
statement
Multiple open instances of an iterator in an SQLJ application
Multiple instances of an iterator can be open concurrently in a single SQLJ
application. One application for this ability is to open several instances of an
iterator that uses host expressions. Each instance can use a different set of host
expression values.
The following example shows an application with two concurrently open instances
of an iterator.
...
ResultSet myFunc(String empid) // Method to open an iterator and get a resultSet
{
MyIter iter;
#sql iter = {SELECT * FROM EMPLOYEE WHERE EMPNO = :empid};
return iter.getResultSet();
}
// An application can call this method to get a resultSet for each
// employee ID. The application can process each resultSet separately.
...
ResultSet rs1 = myFunc("000100"); // Get employee record for employee ID 000100
...
ResultSet rs2 = myFunc("000200"); // Get employee record for employee ID 000200
Figure 37. Example of opening more than one instance of an iterator in a single application
As with any other iterator, you need to remember to close this iterator after the last
time you use it to prevent excessive storage consumption.
Using scrollable iterators in an SQLJ application
In addition to moving forward, one row at a time, through a result table, you
might want to move backward or go directly to a specific row. The IBM Data
Server Driver for JDBC and SQLJ provides this capability.
Chapter 4. SQLJ application programming
143
An iterator in which you can move forward, backward, or to a specific row is
called a scrollable iterator. A scrollable iterator in SQLJ is equivalent to the result
table of a database cursor that is declared as SCROLL.
Like a scrollable cursor, a scrollable iterator can be insensitive or sensitive. A
sensitive scrollable iterator can be static or dynamic. Insensitive means that changes
to the underlying table after the iterator is opened are not visible to the iterator.
Insensitive iterators are read-only. Sensitive means that changes that the iterator or
other processes make to the underlying table are visible to the iterator. Asensitive
means that if the cursor is a read-only cursor, it behaves as an insensitive cursor. If
it is not a read-only cursor, it behaves as a sensitive cursor.
If a scrollable iterator is static, the size of the result table and the order of the rows
in the result table do not change after the iterator is opened. This means that you
cannot insert into result tables, and if you delete a row of a result table, a delete
hole occurs. If you update a row of the result table so that the row no longer
qualifies for the result table, an update hole occurs. Fetching from a hole results in
an SQLException.
Important: Like static scrollable cursors in any other language, SQLJ static
scrollable iterators use declared temporary tables for their internal processing. This
means that before you can execute any applications that contain static scrollable
iterators, your database administrator needs to create a temporary database and
temporary table spaces for those declared temporary tables.
If a scrollable iterator is dynamic, the size of the result table and the order of the
rows in the result table can change after the iterator is opened. Rows that are
inserted or deleted with INSERT and DELETE statements that are executed by the
same application process are immediately visible. Rows that are inserted or deleted
with INSERT and DELETE statements that are executed by other application
processes are visible after the changes are committed.
Important: DB2 Database for Linux, UNIX, and Windows servers do not support
dynamic scrollable cursors. You can use dynamic scrollable iterators in your SQLJ
applications only if those applications access data on DB2 for z/OS servers, at
Version 9 or later.
Important:
To create and use a scrollable iterator, you need to follow these steps:
1. Specify an iterator declaration clause that includes the following clauses:
v implements sqlj.runtime.Scrollable
This indicates that the iterator is scrollable.
v with (sensitivity=INSENSITIVE|SENSITIVE|ASENSITIVE) or with
(sensitivity=SENSITIVE, dynamic=true|false)
sensitivity=INSENSITIVE|SENSITIVE|ASENSITIVE indicates whether update or
delete operations on the underlying table can be visible to the iterator. The
default sensitivity is INSENSITIVE.
dynamic=true|false indicates whether the size of the result table or the order
of the rows in the result table can change after the iterator is opened. The
default value of dynamic is false.
The iterator can be a named or positioned iterator.
Example: The following iterator declaration clause declares a positioned,
sensitive, dynamic, scrollable iterator:
144
Application Programming Guide and Reference for Java
#sql public iterator ByPos
implements sqlj.runtime.Scrollable
with (sensitivity=SENSITIVE, dynamic=true)
(String);
Example: The following iterator declaration clause declares a named,
insensitive, scrollable iterator:
#sql public iterator ByName
implements sqlj.runtime.Scrollable
with (sensitivity=INSENSITIVE) (String EmpNo);
Restriction: You cannot use a scrollable iterator to select columns with the
following data types from a table on a DB2 Database for Linux, UNIX, and
Windows server:
v LONG VARCHAR
v LONG VARGRAPHIC
v BLOB
v CLOB
v XML
v A distinct type that is based on any of the previous data types in this list
v A structured type
2. Create an iterator object, which is an instance of your iterator class.
3. If you want to give the SQLJ runtime environment a hint about the initial fetch
direction, use the setFetchDirection(int direction) method. direction can be
FETCH_FORWARD or FETCH_REVERSE. If you do not invoke setFetchDirection, the
fetch direction is FETCH_FORWARD.
4. For each row that you want to access:
For a named iterator, perform the following steps:
a. Position the cursor using one of the methods listed in the following table.
Table 25. sqlj.runtime.Scrollable methods for positioning a scrollable cursor
Method
first
last
Positions the cursor
1
On the first row of the result table
1
previous
On the last row of the result table
1,2
On the previous row of the result table
On the next row of the result table
next
absolute(int n)
1,3
If n>0, on row n of the result table. If n<0, and m is
the number of rows in the result table, on row m+n+1
of the result table.
relative(int n)1,4
If n>0, on the row that is n rows after the current row.
If n<0, on the row that is n rows before the current
row. If n=0, on the current row.
afterLast1
After the last row in the result table
beforeFirst
1
Before the first row in the result table
Notes:
1. This method does not apply to connections to IBM Informix.
2. If the cursor is after the last row of the result table, this method positions the cursor on
the last row.
3. If the absolute value of n is greater than the number of rows in the result table, this
method positions the cursor after the last row if n is positive, or before the first row if n
is negative.
4. Suppose that m is the number of rows in the result table and x is the current row
number in the result table. If n>0 and x+n>m, the iterator is positioned after the last row.
If n<0 and x+n<1, the iterator is positioned before the first row.
Chapter 4. SQLJ application programming
145
b. If you need to know the current cursor position, use the getRow, isFirst,
isLast, isBeforeFirst, or isAfterLast method to obtain this information.
If you need to know the current fetch direction, invoke the
getFetchDirection method.
c. Use accessor methods to retrieve the current row of the result table.
d. If update or delete operations by the iterator or by other means are visible
in the result table, invoke the getWarnings method to check whether the
current row is a hole.
For a positioned iterator, perform the following steps:
a. Use a FETCH statement with a fetch orientation clause to position the
iterator and retrieve the current row of the result table. Table 26 lists the
clauses that you can use to position the cursor.
Table 26. FETCH clauses for positioning a scrollable cursor
Method
FIRST
LAST
Positions the cursor
1
On the first row of the result table
1
PRIOR
On the last row of the result table
1,2
On the previous row of the result table
NEXT
On the next row of the result table
ABSOLUTE(n)
1,3
If n>0, on row n of the result table. If n<0, and m is
the number of rows in the result table, on row m+n+1
of the result table.
RELATIVE(n)1,4
If n>0, on the row that is n rows after the current row.
If n<0, on the row that is n rows before the current
row. If n=0, on the current row.
AFTER1,5
After the last row in the result table
BEFORE
1,5
Before the first row in the result table
Notes:
1. This value is not supported for connections to IBM Informix
2. If the cursor is after the last row of the result table, this method positions the cursor on
the last row.
3. If the absolute value of n is greater than the number of rows in the result table, this
method positions the cursor after the last row if n is positive, or before the first row if n
is negative.
4. Suppose that m is the number of rows in the result table and x is the current row
number in the result table. If n>0 and x+n>m, the iterator is positioned after the last row.
If n<0 and x+n<1, the iterator is positioned before the first row.
5. Values are not assigned to host expressions.
b. If update or delete operations by the iterator or by other means are visible
in the result table, invoke the getWarnings method to check whether the
current row is a hole.
5. Invoke the close method to close the iterator.
The following code demonstrates how to use a named iterator to retrieve the
employee number and last name from all rows from the employee table in reverse
order. The numbers to the right of selected statements correspond to the
previously-described steps.
146
Application Programming Guide and Reference for Java
#sql context Ctx;
// Create connection context class Ctx
#sql iterator ScrollIter implements sqlj.runtime.Scrollable
1
(String EmpNo, String LastName);
{
...
Ctx ctxt =
new Ctx("jdbc:db2://sysmvs1.stl.ibm.com:5021/NEWYORK",
userid,password,false);
// Create connection context object ctxt
// for the connection to NEWYORK
ScrollIter scrliter;
2
#sql [ctxt]
scrliter={SELECT EMPNO, LASTNAME FROM EMPLOYEE};
scrliter.afterLast();
while (scrliter.previous())
4a
{
System.out.println(scrliter.EmpNo() + " "
4c
+ scrliter.LastName());
}
scrliter.close();
5
}
Related concepts
“Data retrieval in SQLJ applications” on page 137
Temporary table space storage requirements (DB2 Installation Guide)
Related tasks
“Using a named iterator in an SQLJ application” on page 137
“Using a positioned iterator in an SQLJ application” on page 139
Calling stored procedures in SQLJ applications
To call a stored procedure, you use an executable clause that contains an SQL
CALL statement.
You can execute the CALL statement with host identifier parameters. You can
execute the CALL statement with literal parameters only if the DB2 server on
which the CALL statement runs supports execution of the CALL statement
dynamically.
The basic steps in calling a stored procedure are:
1. Assign values to input (IN or INOUT) parameters.
2. Call the stored procedure.
3. Process output (OUT or INOUT) parameters.
4. If the stored procedure returns multiple result sets, retrieve those result sets.
The following code illustrates calling a stored procedure that has three input
parameters and three output parameters. The numbers to the right of selected
statements correspond to the previously-described steps.
Chapter 4. SQLJ application programming
147
String FirstName="TOM";
// Input parameters
1
String LastName="NARISINST";
String Address="IBM";
int CustNo;
// Output parameters
String Mark;
String MarkErrorText;
...
#sql [myConnCtx] {CALL ADD_CUSTOMER(:IN FirstName,
2
:IN LastName,
:IN Address,
:OUT CustNo,
:OUT Mark,
:OUT MarkErrorText)};
// Call the stored procedure
System.out.println("Output parameters from ADD_CUSTOMER call: ");
System.out.println("Customer number for " + LastName + ": " + CustNo); 3
System.out.println(Mark);
If (MarkErrorText != null)
System.out.println(" Error messages:" + MarkErrorText);
Figure 38. Example of calling a stored procedure in an SQLJ application
Related concepts
“Retrieving multiple result sets from a stored procedure in an SQLJ application”
Retrieving multiple result sets from a stored procedure in an
SQLJ application
Some stored procedures return one or more result sets to the calling program by
including the DYNAMIC RESULT SETS n clause in the definition, with n>0, and
opening cursors that are defined with the WITH RETURN clause. The calling
program needs to retrieve the contents of those result sets.
To retrieve the rows from those result sets, you execute these steps:
1. Acquire an execution context for retrieving the result set from the stored
procedure.
2. Associate the execution context with the CALL statement for the stored
procedure.
Do not use this execution context for any other purpose until you have
retrieved and processed the last result set.
3. For each result set:
a. Use the ExecutionContext method getNextResultSet to retrieve the result
set.
b. If you do not know the contents of the result set, use ResultSetMetaData
methods to retrieve this information.
c. Use an SQLJ result set iterator or JDBC ResultSet to retrieve the rows from
the result set.
Result sets are returned to the calling program in the same order that their cursors
are opened in the stored procedure. When there are no more result sets to retrieve,
getNextResultSet returns a null value.
getNextResultSet has two forms:
getNextResultSet();
getNextResultSet(int current);
When you invoke the first form of getNextResultSet, SQLJ closes the
currently-open result set and advances to the next result set. When you invoke the
148
Application Programming Guide and Reference for Java
second form of getNextResultSet, the value of current indicates what SQLJ does
with the currently-open result set before it advances to the next result set:
java.sql.Statement.CLOSE_CURRENT_RESULT
Specifies that the current ResultSet object is closed when the next ResultSet
object is returned.
java.sql.Statement.KEEP_CURRENT_RESULT
Specifies that the current ResultSet object stays open when the next ResultSet
object is returned.
java.sql.Statement.CLOSE_ALL_RESULTS
Specifies that all open ResultSet objects are closed when the next ResultSet
object is returned.
The following code calls a stored procedure that returns multiple result sets. For
this example, it is assumed that the caller does not know the number of result sets
to be returned or the contents of those result sets. It is also assumed that
autoCommit is false. The numbers to the right of selected statements correspond to
the previously-described steps.
ExecutionContext execCtx=myConnCtx.getExecutionContext();
1
#sql [myConnCtx, execCtx] {CALL MULTRSSP()};
2
// MULTRSSP returns multiple result sets
ResultSet rs;
while ((rs = execCtx.getNextResultSet()) != null)
3a
{
ResultSetMetaData rsmeta=rs.getMetaData();
3b
int numcols=rsmeta.getColumnCount();
while (rs.next())
3c
{
for (int i=1; i<=numcols; i++)
{
String colval=rs.getString(i);
System.out.println("Column " + i + "value is " + colval);
}
}
}
Figure 39. Retrieving result sets from a stored procedure
LOBs in SQLJ applications with the IBM Data Server Driver for
JDBC and SQLJ
With the IBM Data Server Driver for JDBC and SQLJ, you can retrieve LOB data
into Clob or Blob host expressions or update CLOB, BLOB, or DBCLOB columns
from Clob or Blob host expressions. You can also declare iterators with Clob or
Blob data types to retrieve data from CLOB, BLOB, or DBCLOB columns.
Retrieving or updating LOB data: To retrieve data from a BLOB column, declare
an iterator that includes a data type of Blob or byte[]. To retrieve data from a
CLOB or DBCLOB column, declare an iterator in which the corresponding column
has a Clob data type.
To update data in a BLOB column, use a host expression with data type Blob. To
update data in a CLOB or DBCLOB column, use a host expression with data type
Clob.
Progressive streaming or LOB locators: In SQLJ applications, you can use
progressive streaming, also known as dynamic data format, or LOB locators in the
same way that you use them in JDBC applications.
Chapter 4. SQLJ application programming
149
Java data types for retrieving or updating LOB column data in
SQLJ applications
When the deferPrepares property is set to true, and the IBM Data Server Driver for
JDBC and SQLJ processes an uncustomized SQLJ statement that includes host
expressions, the driver might need to do extra processing to determine data types.
This extra processing can impact performance.
For IBM Data Server Driver for JDBC and SQLJ type 2 connectivity to DB2 for
z/OS, when the JDBC driver processes a CALL statement, the driver cannot
determine the parameter data types.
When the JDBC driver cannot immediately determine the data type of a parameter
that is used with a LOB column, you need to choose a parameter data type that is
compatible with the LOB data type.
Input parameters for BLOB columns
For input parameters for BLOB columns, you can use either of the following
techniques:
v Use a java.sql.Blob input variable, which is an exact match for a BLOB column:
java.sql.Blob blobData;
#sql {CALL STORPROC(:IN blobData)};
Before you can use a java.sql.Blob input variable, you need to create a
java.sql.Blob object, and then populate that object.
For example, if you are using IBM Data Server Driver for JDBC and SQLJ type 2
connectivity on DB2 for z/OS, you can use the IBM Data Server Driver for JDBC
and SQLJ-only method com.ibm.db2.jcc.t2zos.DB2LobFactory.createBlob to
create a java.sql.Blob object and populate the object with byte[] data:
byte[] byteArray = {0, 1, 2, 3};
java.sql.Blob blobData =
com.ibm.db2.jcc.t2zos.DB2LobFactory.createBlob(byteArray);
v Use an input parameter of type of sqlj.runtime.BinaryStream. A
sqlj.runtime.BinaryStream object is compatible with a BLOB data type. For
example:
java.io.ByteArrayInputStream byteStream =
new java.io.ByteArrayInputStream(byteData);
int numBytes = byteData.length;
sqlj.runtime.BinaryStream binStream =
new sqlj.runtime.BinaryStream(byteStream, numBytes);
#sql {CALL STORPROC(:IN binStream)};
You cannot use this technique for INOUT parameters.
Output parameters for BLOB columns
For output or INOUT parameters for BLOB columns, you can use the following
technique:
v Declare the output parameter or INOUT variable with a java.sql.Blob data type:
java.sql.Blob blobData = null;
#sql CALL STORPROC (:OUT blobData)};
java.sql.Blob blobData = null;
#sql CALL STORPROC (:INOUT blobData)};
150
Application Programming Guide and Reference for Java
Input parameters for CLOB columns
For input parameters for CLOB columns, you can use one of the following
techniques:
v Use a java.sql.Clob input variable, which is an exact match for a CLOB column:
#sql CALL STORPROC(:IN clobData)};
Before you can use a java.sql.Clob input variable, you need to create a
java.sql.Clob object, and then populate that object.
For example, if you are using IBM Data Server Driver for JDBC and SQLJ type 2
connectivity on DB2 for z/OS, you can use the IBM Data Server Driver for JDBC
and SQLJ-only method com.ibm.db2.jcc.t2zos.DB2LobFactory.createClob to
create a java.sql.Clob object and populate the object with String data:
String stringVal = "Some Data";
java.sql.Clob clobData =
com.ibm.db2.jcc.t2zos.DB2LobFactory.createClob(stringVal);
v Use one of the following types of stream IN parameters:
– A sqlj.runtime.CharacterStream input parameter:
java.lang.String charData;
java.io.StringReader reader = new java.io.StringReader(charData);
sqlj.runtime.CharacterStream charStream =
new sqlj.runtime.CharacterStream (reader, charData.length);
#sql {CALL STORPROC(:IN charStream)};
– A sqlj.runtime.UnicodeStream parameter, for Unicode UTF-16 data:
byte[] charDataBytes = charData.getBytes("UnicodeBigUnmarked");
java.io.ByteArrayInputStream byteStream =
new java.io.ByteArrayInputStream(charDataBytes);
sqlj.runtime.UnicodeStream uniStream =
new sqlj.runtime.UnicodeStream(byteStream, charDataBytes.length );
#sql {CALL STORPROC(:IN uniStream)};
– A sqlj.runtime.AsciiStream parameter, for ASCII data:
byte[] charDataBytes = charData.getBytes("US-ASCII");
java.io.ByteArrayInputStream byteStream =
new java.io.ByteArrayInputStream (charDataBytes);
sqlj.runtime.AsciiStream asciiStream =
new sqlj.runtime.AsciiStream (byteStream, charDataBytes.length);
#sql {CALL STORPROC(:IN asciiStream)};
For these calls, you need to specify the exact length of the input data. You
cannot use this technique for INOUT parameters.
v Use a java.lang.String input parameter:
java.lang.String charData;
#sql {CALL STORPROC(:IN charData)};
Output parameters for CLOB columns
For output or INOUT parameters for CLOB columns, you can use one of the
following techniques:
v Use a java.sql.Clob output variable, which is an exact match for a CLOB column:
java.sql.Clob clobData = null;
#sql CALL STORPROC(:OUT clobData)};
v Use a java.lang.String output variable:
java.lang.String charData = null;
#sql CALL STORPROC(:OUT charData)};
Chapter 4. SQLJ application programming
151
This technique should be used only if you know that the length of the retrieved
data is less than or equal to 32KB. Otherwise, the data is truncated.
Output parameters for DBCLOB columns
DBCLOB output or INOUT parameters for stored procedures are not supported.
SQLJ and JDBC in the same application
You can combine SQLJ clauses and JDBC calls in a single program.
To do this effectively, you need to be able to do the following things:
v Use a JDBC Connection to build an SQLJ ConnectionContext, or obtain a JDBC
Connection from an SQLJ ConnectionContext.
v Use an SQLJ iterator to retrieve data from a JDBC ResultSet or generate a JDBC
ResultSet from an SQLJ iterator.
Building an SQLJ ConnectionContext from a JDBC Connection: To do that:
1. Execute an SQLJ connection declaration clause to create a ConnectionContext
class.
2. Load the driver or obtain a DataSource instance.
3. Invoke the SQLJ DriverManager.getConnection or DataSource.getConnection
method to obtain a JDBC Connection.
4. Invoke the ConnectionContext constructor with the Connection as its argument
to create the ConnectionContext object.
Obtaining a JDBC Connection from an SQLJ ConnectionContext: To do this,
1. Execute an SQLJ connection declaration clause to create a ConnectionContext
class.
2. Load the driver or obtain a DataSource instance.
3. Invoke the ConnectionContext constructor with the URL of the driver and any
other necessary parameters as its arguments to create the ConnectionContext
object.
4. Invoke the JDBC ConnectionContext.getConnection method to create the JDBC
Connection object.
See "Connect to a data source using SQLJ" for more information on SQLJ
connections.
Retrieving JDBC result sets using SQLJ iterators: Use the iterator conversion
statement to manipulate a JDBC result set as an SQLJ iterator. The general form of
an iterator conversion statement is:
#sql iterator={CAST :result-set};
Before you can successfully cast a result set to an iterator, the iterator must
conform to the following rules:
v The iterator must be declared as public.
v If the iterator is a positioned iterator, the number of columns in the result set
must match the number of columns in the iterator. In addition, the data type of
each column in the result set must match the data type of the corresponding
column in the iterator.
152
Application Programming Guide and Reference for Java
v If the iterator is a named iterator, the name of each accessor method must match
the name of a column in the result set. In addition, the data type of the object
that an accessor method returns must match the data type of the corresponding
column in the result set.
The code in Figure 40 builds and executes a query using a JDBC call, executes an
iterator conversion statement to convert the JDBC result set to an SQLJ iterator,
and retrieves rows from the result table using the iterator.
#sql public iterator ByName(String LastName, Date HireDate);
1
public void HireDates(ConnectionContext connCtx, String whereClause)
{
ByName nameiter;
// Declare object of ByName class
Connection conn=connCtx.getConnection();
// Create JDBC connection
Statement stmt = conn.createStatement();
String query = "SELECT LASTNAME, HIREDATE FROM EMPLOYEE";
query+=whereClause;
// Build the query
ResultSet rs = stmt.executeQuery(query);
#sql [connCtx] nameiter = {CAST :rs};
while (nameiter.next())
{
System.out.println( nameiter.LastName() + " was hired on "
+ nameiter.HireDate());
}
nameiter.close();
stmt.close();
2
3
4
5
}
Figure 40. Converting a JDBC result set to an SQLJ iterator
Notes to Figure 40:
Note
1
2
3
4
5
Description
This SQLJ clause creates the named iterator class ByName, which has accessor
methods LastName() and HireDate() that return the data from result table columns
LASTNAME and HIREDATE.
This statement and the following two statements build and prepare a query for
dynamic execution using JDBC.
This JDBC statement executes the SELECT statement and assigns the result table
to result set rs.
This iterator conversion clause converts the JDBC ResultSet rs to SQLJ iterator
nameiter, and the following statements use nameiter to retrieve values from the
result table.
The nameiter.close() method closes the SQLJ iterator and JDBC ResultSet rs.
Generating JDBC ResultSets from SQLJ iterators: Use the getResultSet method to
generate a JDBC ResultSet from an SQLJ iterator. Every SQLJ iterator has a
getResultSet method. After you access the ResultSet that underlies an iterator,
you need to fetch rows using only the ResultSet.
The code in Figure 41 on page 154 generates a positioned iterator for a query,
converts the iterator to a result set, and uses JDBC methods to fetch rows from the
table.
Chapter 4. SQLJ application programming
153
#sql iterator EmpIter(String, java.sql.Date);
{
...
EmpIter iter=null;
#sql [connCtx] iter=
{SELECT LASTNAME, HIREDATE FROM EMPLOYEE};
1
ResultSet rs=iter.getResultSet();
2
while (rs.next())
3
{ System.out.println(rs.getString(1) + " was hired in " +
rs.getDate(2));
}
rs.close();
4
}
Figure 41. Converting an SQLJ iterator to a JDBC ResultSet
Notes to Figure 41:
Note
1
2
3
4
Description
This SQLJ clause executes the SELECT statement, constructs an iterator object that
contains the result table for the SELECT statement, and assigns the iterator object
to variable iter.
The getResultSet() method accesses the ResultSet that underlies iterator iter.
The JDBC getString() and getDate() methods retrieve values from the ResultSet.
The next() method moves the cursor to the next row in the ResultSet.
The rs.close() method closes the SQLJ iterator as well as the ResultSet.
Rules and restrictions for using JDBC ResultSets in SQLJ applications: When you
write SQLJ applications that include JDBC result sets, observe the following rules
and restrictions:
v Before you can access the columns of a remote table by name, through either a
named iterator or an iterator that is converted to a JDBC ResultSet object, the
DB2 for z/OS DESCSTAT subsystem parameter must be set to YES.
v You cannot cast a ResultSet to an SQLJ iterator if the ResultSet and the iterator
have different holdability attributes.
A JDBC ResultSet or an SQLJ iterator can remain open after a COMMIT
operation. For a JDBC ResultSet, this characteristic is controlled by the IBM
Data Server Driver for JDBC and SQLJ property resultSetHoldability. For an
SQLJ iterator, this characteristic is controlled by the with holdability parameter
of the iterator declaration. Casting a ResultSet that has holdability to an SQLJ
iterator that does not, or casting a ResultSet that does not have holdability to an
SQLJ iterator that does, is not supported.
v Close the iterator or the underlying ResultSet object as soon as the program no
longer uses the iterator or ResultSet, and before the end of the program.
Closing the iterator also closes the ResultSet object. Closing the ResultSet object
also closes the iterator object. In general, it is best to close the object that is used
last.
v For the IBM Data Server Driver for JDBC and SQLJ, which supports scrollable
iterators and scrollable and updatable ResultSet objects, the following
restrictions apply:
– Scrollable iterators have the same restrictions as their underlying JDBC
ResultSet objects.
– You cannot cast a JDBC ResultSet that is not updatable to an SQLJ iterator
that is updatable.
154
Application Programming Guide and Reference for Java
Related reference
DESCRIBE FOR STATIC field (DESCSTAT subsystem parameter) (DB2
Installation Guide)
Controlling the execution of SQL statements in SQLJ
You can use selected methods of the SQLJ ExecutionContext class to control or
monitor the execution of SQL statements.
To use ExecutionContext methods, follow these steps:
1. Acquire the default execution context from the connection context.
There are two ways to acquire an execution context:
v Acquire the default execution context from the connection context. For
example:
ExecutionContext execCtx = connCtx.getExecutionContext();
v Create a new execution context by invoking the constructor for
ExecutionContext. For example:
ExecutionContext execCtx=new ExecutionContext();
2. Associate the execution context with an SQL statement.
To do that, specify an execution context after the connection context in the
execution clause that contains the SQL statement.
3. Invoke ExecutionContext methods.
Some ExecutionContext methods are applicable before the associated SQL
statement is executed, and some are applicable only after their associated SQL
statement is executed.
For example, you can use method getUpdateCount to count the number of rows
that are deleted by a DELETE statement after you execute the DELETE
statement.
The following code demonstrates how to acquire an execution context, and then
use the getUpdateCount method on that execution context to determine the number
of rows that were deleted by a DELETE statement. The numbers to the right of
selected statements correspond to the previously-described steps.
ExecutionContext execCtx=new ExecutionContext();
1
#sql [connCtx, execCtx] {DELETE FROM EMPLOYEE WHERE SALARY > 10000}; 2
System.out.println("Deleted " + execCtx.getUpdateCount() + " rows"); 3
Related tasks
“Handling SQL warnings in an SQLJ application” on page 170
ROWIDs in SQLJ with the IBM Data Server Driver for JDBC
and SQLJ
DB2 for z/OS and DB2 for i support the ROWID data type for a column in a table.
A ROWID is a value that uniquely identifies a row in a table.
Although IBM Informix also supports rowids, those rowids have the INTEGER
data type. You can select an IBM Informix rowid column into a variable with a
four-byte integer data type.
If you use columns with the ROWID data type in SQLJ programs, you need to
customize those programs.
Chapter 4. SQLJ application programming
155
JDBC 4.0 includes interface java.sql.RowId that you can use in iterators and in
CALL statement parameters. If you do not have JDBC 4.0, you can use the IBM
Data Server Driver for JDBC and SQLJ-only class com.ibm.db2.jcc.DB2RowID. For
an iterator, you can also use the byte[] object type to retrieve ROWID values.
The following code shows an example of an iterator that is used to select values
from a ROWID column:
#sql iterator PosIter(int,String,java.sql.RowId);
// Declare positioned iterator
// for retrieving ITEM_ID (INTEGER),
// ITEM_FORMAT (VARCHAR), and ITEM_ROWID (ROWID)
// values from table ROWIDTAB
{
PosIter positrowid;
// Declare object of PosIter class
java.sql.RowId rowid = null;
int id = 0;
String i_fmt = null;
// Declare host expressions
#sql [ctxt] positrowid =
{SELECT ITEM_ID, ITEM_FORMAT, ITEM_ROWID FROM ROWIDTAB
WHERE ITEM_ID=3};
// Assign the result table of the SELECT
// to iterator object positrowid
#sql {FETCH :positrowid INTO :id, :i_fmt, :rowid};
// Retrieve the first row
while (!positrowid.endFetch())
// Check whether the FETCH returned a row
{System.out.println("Item ID " + id + " Item format " +
i_fmt + " Item ROWID ");
MyUtilities.printBytes(rowid.getBytes());
// Use the getBytes method to
// convert the value to bytes for printing.
// Call a user-defined method called
// printBytes (not shown) to print
// the value.
#sql {FETCH :positrowid INTO :id, :i_fmt, :rowid};
// Retrieve the next row
}
positrowid.close();
// Close the iterator
}
Figure 42. Example of using an iterator to retrieve ROWID values
The following code shows an example of calling a stored procedure that takes
three ROWID parameters: an IN parameter, an OUT parameter, and an INOUT
parameter.
156
Application Programming Guide and Reference for Java
java.sql.RowId in_rowid = rowid;
java.sqlRowId out_rowid = null;
java.sql.RowId inout_rowid = rowid;
// Declare an IN, OUT, and
// INOUT ROWID parameter
...
#sql [myConnCtx] {CALL SP_ROWID(:IN in_rowid,
:OUT out_rowid,
:INOUT inout_rowid)};
// Call the stored procedure
System.out.println("Parameter values from SP_ROWID call: ");
System.out.println("OUT parameter value ");
MyUtilities.printBytes(out_rowid.getBytes());
// Use the getBytes method to
// convert the value to bytes for printing
// Call a user-defined method called
// printBytes (not shown) to print
// the value.
System.out.println("INOUT parameter value ");
MyUtilities.printBytes(inout_rowid.getBytes());
Figure 43. Example of calling a stored procedure with a ROWID parameter
TIMESTAMP WITH TIME ZONE values in SQLJ applications
DB2 for z/OS supports table columns with the TIMESTAMP WITH TIME ZONE
data type. IBM Data Server Driver for JDBC and SQLJ supports update into and
retrieval from a column with the TIMESTAMP WITH TIME ZONE data type in
SQLJ programs.
When you update or retrieve a TIMESTAMP WITH TIME ZONE value, or call a
stored procedure with a TIMESTAMP WITH TIME ZONE parameter, you need to
use host variables that are com.ibm.db2.jcc.DBTimestamp objects to retain the time
zone information. If you use java.sql.Timestamp objects to pass TIMESTAMP
WITH TIME ZONE values to and from the data server, you lose the time zone
information.
Because the com.ibm.db2.jcc.DBTimestamp class is a IBM Data Server Driver for
JDBC and SQLJ-only class, if you run an uncustomized SQLJ application that uses
com.ibm.db2.jcc.DBTimestamp objects, the application receives an SQLException.
Examples
Suppose that table TSTABLE has a single column, TSCOL, which has data type
TIMESTAMP WITH TIME ZONE. The following code assigns a timestamp value
with a time zone to the column, and retrieves the value from the column.
#sql iterator TSIter(com.ibm.db2.jcc.DBTimestamp TSVar);
{
...
java.util.TimeZone esttz = java.util.TimeZone.getTimeZone("EST");
// Set the time zone to GMT-5
java.util.Calendar estcal= java.util.Calendar.getInstance(esttz);
// Create a calendar instance
// with the EST time zone
java.sql.Timestamp ts =
java.sql.Timestamp.valueOf("2009-02-27 21:22:33.444444");
// Initialize a timestamp object
// with the datetime value that you
// want to put in the table
com.ibm.db2.jcc.DBTimestamp dbts =
Chapter 4. SQLJ application programming
157
new com.ibm.db2.jcc.DBTimestamp(ts,estcal);
// Create a datetime object that
// includes the time zone
#sql[ctx] {INSERT INTO TSTABLE (TSCOL) VALUES (:dbts)};
// Insert the datetime object in
// the table
#sql[ctx] {COMMIT};
TSIter iter = null;
#sql [ctx] iter = {SELECT TSCOL FROM TSTABLE};
// Assign the result table of the SELECT
while (iter.next()) {
System.out.println ("Timestamp = " +
((com.ibm.db2.jcc.DBTimestamp)iter.TSVar()).toDBString(true));
// Use accessor method TSVar to retrieve
// the TIMESTAMP WITH TIME ZONE value,
// cast it to a DBTimestamp value,
// and retrieve its string representation.
// Value retrieved:
// 2009-02-27 21:22:33.444444-05:00
}
}
Suppose that stored procedure TSSP has a single INOUT parameter, TSPARM,
which has data type TIMESTAMP WITH TIME ZONE. The following code calls
the stored procedure with a timestamp value that includes a time zone, and
retrieves a parameter value with a timestamp value that includes a time zone.
{
...
java.util.TimeZone esttz = java.util.TimeZone.getTimeZone("EST");
// Set the time zone to GMT-5
java.util.Calendar estcal= java.util.Calendar.getInstance(esttz);
// Create a calendar instance
// with the EST time zone
java.sql.Timestamp ts =
java.sql.Timestamp.valueOf("2009-02-27 21:22:33.444444");
// Initialize a timestamp object
// with the timestamp value that you
// want to pass to the stored procedure
com.ibm.db2.jcc.DBTimestamp dbts =
new com.ibm.db2.jcc.DBTimestamp(ts,estcal);
// Create a timestamp object that
// includes the time zone to
// pass to the stored procedure
#sql[ctx] { CALL TSSP (:INOUT dbts) };
System.out.println ("Output parameter: " + dbts.toDBString (true));
// Call the stored procedure with
// the timestamp value as input,
// and retrieve a timestamp value
// with a time zone in the same
// parameter
}
Distinct types in SQLJ applications
In an SQLJ program, you can create a distinct type using the CREATE DISTINCT
TYPE statement in an executable clause.
You can also use CREATE TABLE in an executable clause to create a table that
includes a column of that type. When you retrieve data from a column of that
type, or update a column of that type, you use Java host variables or expressions
with data types that correspond to the built-in types on which the distinct types
are based.
158
Application Programming Guide and Reference for Java
The following example creates a distinct type that is based on an INTEGER type,
creates a table with a column of that type, inserts a row into the table, and
retrieves the row from the table:
String empNumVar;
int shoeSizeVar;
...
#sql [myConnCtx] {CREATE DISTINCT TYPE SHOESIZE AS INTEGER WITH COMPARISONS};
// Create distinct type
#sql [myConnCtx] {COMMIT}; // Commit the create
#sql [myConnCtx] {CREATE TABLE EMP_SHOE
(EMPNO CHAR(6), EMP_SHOE_SIZE SHOESIZE)};
// Create table using distinct type
#sql [myConnCtx] {COMMIT}; // Commit the create
#sql [myConnCtx] {INSERT INTO EMP_SHOE
VALUES(’000010’,6)};
// Insert a row in the table
#sql [myConnCtx] {COMMIT}; // Commit the INSERT
#sql [myConnCtx] {SELECT EMPNO, EMP_SHOE_SIZE
INTO :empNumVar, :shoeSizeVar
FROM EMP_SHOE};
// Retrieve the row
System.out.println("Employee number: " + empNumVar +
" Shoe size: " + shoeSizeVar);
Figure 44. Defining and using a distinct type
Related reference
CREATE TYPE (DB2 SQL)
Savepoints in SQLJ applications
Under the IBM Data Server Driver for JDBC and SQLJ, you can include any form
of the SQL SAVEPOINT statement in your SQLJ program.
An SQL savepoint represents the state of data and schemas at a particular point in
time within a unit of work. SQL statements exist to set a savepoint, release a
savepoint, and restore data and schemas to the state that the savepoint represents.
The following example demonstrates how to set a savepoint, roll back to the
savepoint, and release the savepoint.
Figure 45. Setting, rolling back to, and releasing a savepoint in an SQLJ application
#sql context Ctx;
// Create connection context class Ctx
String empNumVar;
int shoeSizeVar;
...
try {
// Load the JDBC driver
Class.forName("com.ibm.db2.jcc.DB2Driver");
}
catch (ClassNotFoundException e) {
e.printStackTrace();
}
Connection jdbccon=
DriverManager.getConnection("jdbc:db2://sysmvs1.stl.ibm.com:5021/NEWYORK",
userid,password);
// Create JDBC connection object jdbccon
jdbccon.setAutoCommit(false); // Do not autocommit
Ctx ctxt=new Ctx(jdbccon);
// Create connection context object myConnCtx
// for the connection to NEWYORK
...
// Perform some SQL
#sql [ctxt] {COMMIT};
// Commit the transaction
Chapter 4. SQLJ application programming
159
// Commit the create
#sql [ctxt]
{INSERT INTO EMP_SHOE VALUES (’000010’, 6)};
// Insert a row
#sql [ctxt]
{SAVEPOINT SVPT1 ON ROLLBACK RETAIN CURSORS};
// Create a savepoint
...
#sql [ctxt]
{INSERT INTO EMP_SHOE VALUES (’000020’, 10)};
// Insert another row
#sql [ctxt] {ROLLBACK TO SAVEPOINT SVPT1};
// Roll back work to the point
// after the first insert
...
#sql [ctxt] {RELEASE SAVEPOINT SVPT1};
// Release the savepoint
ctx.close();
// Close the connection context
XML data in SQLJ applications
In SQLJ applications, you can store data in XML columns and retrieve data from
XML columns.
In DB2 tables, the XML built-in data type is used to store XML data in a column as
a structured set of nodes in a tree format.
SQLJ applications can send XML data to the data server or retrieve XML data from
the data server in one of the following forms:
v As textual XML data
v As binary XML data (data that is in the Extensible Dynamic Binary XML DB2
Client/Server Binary XML Format), if the data server supports it
In SQLJ applications, you can:
v Store an entire XML document in an XML column using INSERT, UPDATE, or
MERGE statements.
v Retrieve an entire XML document from an XML column using single-row
SELECT statements or iterators.
v Retrieve a sequence from a document in an XML column by using the SQL
XMLQUERY function to retrieve the sequence in the database, and then using
single-row SELECT statements or iterators to retrieve the serialized XML string
data into an application variable.
v You can update or retrieve XML data as textual XML data. Alternatively, for
connections to a data server that supports binary XML data, you can update or
retrieve XML data as binary XML data. You use the Datasource or Connection
property xmlFormat to control whether the data format is textual XML or binary
XML. The format of XML data is transparent to the application. Storage and
retrieval of binary XML data on a DB2 for z/OS data server requires version 4.9
or later of the IBM Data Server Driver for JDBC and SQLJ.
JDBC 4.0 java.sql.SQLXML objects can be used to retrieve and update data in XML
columns. Invocations of metadata methods, such as
ResultSetMetaData.getColumnType return the integer value java.sql.Types.SQLXML
for an XML column type.
160
Application Programming Guide and Reference for Java
Related concepts
“XML column updates in SQLJ applications”
“XML data retrieval in SQLJ applications” on page 163
XML column updates in SQLJ applications
In an SQLJ application, you can update or insert data into XML columns of a table
at a DB2 data server using XML textual data. You can update or insert data into
XML columns of a table using binary XML data (data that is in the Extensible
Dynamic Binary XML DB2 Client/Server Binary XML Format), if the data server
supports binary XML data.
The host expression data types that you can use to update XML columns are:
v java.sql.SQLXML (requires an SDK for Java Version 6 or later, and the IBM Data
Server Driver for JDBC and SQLJ version 4.0 or later)
v com.ibm.db2.jcc.DB2Xml (deprecated)
v String
v byte
v Blob
v Clob
v sqlj.runtime.AsciiStream
v sqlj.runtime.BinaryStream
v sqlj.runtime.CharacterStream
The encoding of XML data can be derived from the data itself, which is known as
internally encoded data, or from external sources, which is known as externally
encoded data. XML data that is sent to the database server as binary data is treated
as internally encoded data. XML data that is sent to the data source as character
data is treated as externally encoded data. The external encoding is the default
encoding for the JVM.
External encoding for Java applications is always Unicode encoding.
Externally encoded data can have internal encoding. That is, the data might be sent
to the data source as character data, but the data contains encoding information.
The data source handles incompatibilities between internal and external encoding
as follows:
v If the data source is DB2 Database for Linux, UNIX, and Windows, the data
source generates an error if the external and internal encoding are incompatible,
unless the external and internal encoding are Unicode. If the external and
internal encoding are Unicode, the data source ignores the internal encoding.
v If the data source is DB2 for z/OS, the data source ignores internal encoding.
Character data in XML columns is stored in UTF-8 encoding.
Example: Suppose that you use the following statement to insert data from String
host expression xmlString into an XML column in a table. xmlString is a character
type, so its external encoding is used, whether or not it has an internal encoding
specification.
#sql [ctx] {INSERT INTO CUSTACC VALUES (1, :xmlString)};
Example: Suppose that you copy the data from xmlString into a byte array with
CP500 encoding. The data contains an XML declaration with an encoding
declaration for CP500. Then you insert the data from the byte[] host expression
into an XML column in a table.
Chapter 4. SQLJ application programming
161
byte[] xmlBytes = xmlString.getBytes("CP500");
#sql[ctx] {INSERT INTO CUSTACC VALUES (4, :xmlBytes)};
A byte string is considered to be internally encoded data. The data is converted
from its internal encoding scheme to UTF-8, if necessary, and stored in its
hierarchical format on the data source.
Example: Suppose that you copy the data from xmlString into a byte array with
US-ASCII encoding. Then you construct an sqlj.runtime.AsciiStream host
expression, and insert data from the sqlj.runtime.AsciiStream host expression into
an XML column in a table on a data source.
byte[] b = xmlString.getBytes("US-ASCII");
java.io.ByteArrayInputStream xmlAsciiInputStream =
new java.io.ByteArrayInputStream(b);
sqlj.runtime.AsciiStream sqljXmlAsciiStream =
new sqlj.runtime.AsciiStream(xmlAsciiInputStream, b.length);
#sql[ctx] {INSERT INTO CUSTACC VALUES (4, :sqljXmlAsciiStream)};
sqljXmlAsciiStream is a stream type, so its internal encoding is used. The data is
converted from its internal encoding to UTF-8 encoding and stored in its
hierarchical form on the data source.
Example: sqlj.runtime.CharacterStream host expression: Suppose that you
construct an sqlj.runtime.CharacterStream host expression, and insert data from the
sqlj.runtime.CharacterStream host expression into an XML column in a table.
java.io.StringReader xmlReader =
new java.io.StringReader(xmlString);
sqlj.runtime.CharacterStream sqljXmlCharacterStream =
new sqlj.runtime.CharacterStream(xmlReader, xmlString.length());
#sql [ctx] {INSERT INTO CUSTACC VALUES (4, :sqljXmlCharacterStream)};
sqljXmlCharacterStream is a character type, so its external encoding is used,
whether or not it has an internal encoding specification.
Example: Suppose that you retrieve a document from an XML column into a
java.sql.SQLXML host expression, and insert the data into an XML column in a
table.
java.sql.ResultSet rs = s.executeQuery ("SELECT * FROM CUSTACC");
rs.next();
java.sql.SQLXML xmlObject = (java.sql.SQLXML)rs.getObject(2);
#sql [ctx] {INSERT INTO CUSTACC VALUES (6, :xmlObject)};
After you retrieve the data it is still in UTF-8 encoding, so when you insert the
data into another XML column, no conversion occurs.
Example: Suppose that you retrieve a document from an XML column into a
com.ibm.db2.jcc.DB2Xml host expression, and insert the data into an XML column
in a table.
java.sql.ResultSet rs = s.executeQuery ("SELECT * FROM CUSTACC");
rs.next();
com.ibm.db2.jcc.DB2Xml xmlObject = (com.ibm.db2.jcc.DB2Xml)rs.getObject(2);
#sql [ctx] {INSERT INTO CUSTACC VALUES (6, :xmlObject)};
After you retrieve the data it is still in UTF-8 encoding, so when you insert the
data into another XML column, no conversion occurs.
162
Application Programming Guide and Reference for Java
XML data retrieval in SQLJ applications
When you retrieve data from XML columns of a database table in an SQLJ
application, the output data must be explicitly or implicitly serialized.
The host expression or iterator data types that you can use to retrieve data from
XML columns are:
v java.sql.SQLXML (requires an SDK for Java Version 6 or later, and the IBM Data
Server Driver for JDBC and SQLJ version 4.0 or later)
v com.ibm.db2.jcc.DB2Xml (deprecated)
v String
v byte[]
v sqlj.runtime.AsciiStream
v sqlj.runtime.BinaryStream
v sqlj.runtime.CharacterStream
If the application does not call the XMLSERIALIZE function before data retrieval,
the data is converted from UTF-8 to the external application encoding for the
character data types, or the internal encoding for the binary data types. No XML
declaration is added. If the host expression is an object of the java.sql.SQLXML or
com.ibm.db2.jcc.DB2Xml type, you need to call an additional method to retrieve
the data from this object. The method that you call determines the encoding of the
output data and whether an XML declaration with an encoding specification is
added.
The following table lists the methods that you can call to retrieve data from a
java.sql.SQLXML or a com.ibm.db2.jcc.DB2Xml object, and the corresponding
output data types and type of encoding in the XML declarations.
Table 27. SQLXML and DB2Xml methods, data types, and added encoding specifications
Method
Output data type
Type of XML internal encoding declaration added
SQLXML.getBinaryStream
InputStream
None
SQLXML.getCharacterStream
Reader
None
SQLXML.getSource
Source
None
SQLXML.getString
String
None
DB2Xml.getDB2AsciiStream
InputStream
None
DB2Xml.getDB2BinaryStream
InputStream
None
DB2Xml.getDB2Bytes
byte[]
None
DB2Xml.getDB2CharacterStream
Reader
None
DB2Xml.getDB2String
String
None
DB2Xml.getDB2XmlAsciiStream
InputStream
US-ASCII
DB2Xml.getDB2XmlBinaryStream
InputStream
Specified by getDB2XmlBinaryStream targetEncoding
parameter
DB2Xml.getDB2XmlBytes
byte[]
Specified by DB2Xml.getDB2XmlBytes targetEncoding
parameter
DB2Xml.getDB2XmlCharacterStream
Reader
ISO-10646-UCS-2
DB2Xml.getDB2XmlString
String
ISO-10646-UCS-2
If the application executes the XMLSERIALIZE function on the data that is to be
returned, after execution of the function, the data has the data type that is specified
Chapter 4. SQLJ application programming
163
in the XMLSERIALIZE function, not the XML data type. Therefore, the driver
handles the data as the specified type and ignores any internal encoding
declarations.
Example: Suppose that you retrieve data from an XML column into a String host
expression.
#sql iterator XmlStringIter (int, String);
#sql [ctx] siter = {SELECT C1, CADOC from CUSTACC};
#sql {FETCH :siter INTO :row, :outString};
The String type is a character type, so the data is converted from UTF-8 to the
external encoding, which is the default JVM encoding, and returned without any
XML declaration.
Example: Suppose that you retrieve data from an XML column into a byte[] host
expression.
#sql iterator XmlByteArrayIter (int, byte[]);
XmlByteArrayIter biter = null;
#sql [ctx] biter = {SELECT c1, CADOC from CUSTACC};
#sql {FETCH :biter INTO :row, :outBytes};
The byte[] type is a binary type, so no data conversion from UTF-8 encoding
occurs, and the data is returned without any XML declaration.
Example: Suppose that you retrieve a document from an XML column into a
java.sql.SQLXML host expression, but you need the data in a binary stream.
#sql iterator SqlXmlIter (int, java.sql.SQLXML);
SqlXmlIter SQLXMLiter = null;
java.sql.SQLXML outSqlXml = null;
#sql [ctx] SqlXmlIter = {SELECT c1, CADOC from CUSTACC};
#sql {FETCH :SqlXmlIter INTO :row, :outSqlXml};
java.io.InputStream XmlStream = outSqlXml.getBinaryStream();
The FETCH statement retrieves the data into the SQLXML object in UTF-8
encoding. The SQLXML.getBinaryStream stores the data in a binary stream.
Example: Suppose that you retrieve a document from an XML column into a
com.ibm.db2.jcc.DB2Xml host expression, but you need the data in a byte string
with an XML declaration that includes an internal encoding specification for
UTF-8.
#sql iterator DB2XmlIter (int, com.ibm.db2.jcc.DB2Xml);
DB2XmlIter db2xmliter = null;
com.ibm.db2.jcc.DB2Xml outDB2Xml = null;
#sql [ctx] db2xmliter = {SELECT c1, CADOC from CUSTACC};
#sql {FETCH :db2xmliter INTO :row, :outDB2Xml};
byte[] byteArray = outDB2XML.getDB2XmlBytes("UTF-8");
The FETCH statement retrieves the data into the DB2Xml object in UTF-8
encoding. The getDB2XmlBytes method with the UTF-8 argument adds an XML
declaration with a UTF-8 encoding specification and stores the data in a byte array.
XMLCAST in SQLJ applications
Before you can use XMLCAST to cast a host variable to the XML data type in an
SQLJ application, you need to cast the host variable to the corresponding SQL data
type.
164
Application Programming Guide and Reference for Java
Example: The following code demonstrates a situation in which it is necessary to
cast a String host variable to an SQL character type, such as VARCHAR, before
you use XMLCAST to cast the value to the XML data type.
String xmlresult = null;
String varchar_hv = "San Jose";
...
#sql [con] {SELECT XMLCAST(CAST(:varchar_hv AS VARCHAR(32)) AS XML) INTO
:xmlresult FROM SYSIBM.SYSDUMMY1};
Inserting data from file reference variables into tables in SQLJ
applications
You can use file reference variable objects with IBM Data Server Driver for JDBC
and SQLJ type 2 connectivity on DB2 for z/OS Version 9 or later to stream LOB or
XML input data.
You need to store your LOB or XML input data in HFS files.
Use of file reference variables eliminates the need to materialize the LOB or XML
data in memory before the data is stored in tables. To use file reference variables to
store LOB or XML data in tables, follow these steps.
1. Execute constructors for file reference variable objects of the appropriate types.
The following table lists the types of data in the input files and the appropriate
constructors.
Input data type
Constructor
BLOB
com.ibm.db2.jcc.DB2BlobFileReference
CLOB
com.ibm.db2.jcc.DB2ClobFileReference
XML AS BLOB
com.ibm.db2.jcc.DB2XmlAsBlobFileReference
XML AS CLOB
com.ibm.db2.jcc.DB2XmlAsClobFileReference
The first parameter in each constructor must specify the absolute path name for
an existing HFS file.
2. Execute an INSERT statement with the file reference variable object as the input
host variable.
Suppose that a table is defined like this:
CREATE TABLE TEST02TB (
RECID INTEGER,
CLOBCOL CLOB(100M),
BLOBCOL(200M),
XMLCOL XML)
The following code uses file reference variables to insert a CLOB value, a BLOB
value, and an XML AS BLOB value into the table. The numbers to the right of
selected statements correspond to the previously described steps.
...
com.ibm.db2.jcc.DB2ClobFileReference clobFileRef =
1
new com.ibm.db2.jcc.DB2ClobFileReference("/u/usrt001/jcc/test/TEXT.FILE","Cp037");
com.ibm.db2.jcc.DB2BlobFileReference blobFileRef =
new com.ibm.db2.jcc.DB2BlobFileReference("/u/usrt001/jcc/test/BINARY.FILE");
com.ibm.db2.jcc.DB2XmlAsBlobFileReference xmlAsBlobFileRef =
new com.ibm.db2.jcc.DB2XmlAsBlobFileReference(
"/u/usrt001/jcc/test/XML.FILE");
// Execute constructors for the file reference
Chapter 4. SQLJ application programming
165
// variable objects
#sql [ctx] {"INSERT INTO TEST03TB(RECID,CLOBCOL,BLOBCOL,XMLCOL)
VALUES(’003’,:clobFileRef,:blobFileRef,:xmlAsBlobFileRef)};
2
SQLJ utilization of SDK for Java Version 5 function
Your SQLJ applications can use a number of functions that were introduced with
the SDK for Java Version 5.
Static import
The static import construct lets you access static members without qualifying those
members with the name of the class to which they belong. For SQLJ applications,
this means that you can use static members in host expressions without qualifying
them.
Example: Suppose that you want to declare a host expression of this form:
double r = cos(PI * E);
cos, PI, and E are members of the java.lang.Math class. To declare r without
explicitly qualifying cos, PI, and E, include the following static import statement in
your program:
import static java.lang.Math.*;
Annotations
Java annotations are a means for adding metadata to Java programs that can also
affect the way that those programs are treated by tools and libraries. Annotations
are declared with annotation type declarations, which are similar to interface
declarations. Java annotations can appear in the following types of classes or
interfaces:
v Class declaration
v Interface declaration
v Nested class declaration
v Nested interface declaration
You cannot include Java annotations directly in SQLJ programs, but you can
include annotations in Java source code, and then include that source code in your
SQLJ programs.
Example: Suppose that you declare the following marker annotation in a program
called MyAnnot.java:
public @interface MyAnot { }
You also declare the following marker annotation in a program called
MyAnnot2.java:
public @interface MyAnot2 { }
You can then use those annotations in an SQLJ program:
// Class annotations
@MyAnot2 public @MyAnot class TestAnnotation
{
// Field annotation
@MyAnot
private static final int field1 = 0;
// Constructor annotation
@MyAnot2 public @MyAnot TestAnnotation () { }
166
Application Programming Guide and Reference for Java
// Method annotation
@MyAnot
public static void main (String a[])
{
TestAnnotation TestAnnotation_o = new TestAnnotation();
TestAnnotation_o.runThis();
}
// Inner class annotation
public static @MyAnot class TestAnotherInnerClass { }
// Inner interface annotation
public static @MyAnot interface TestAnotInnerInterface { }
}
Enumerated types
An enumerated type is a data type that consists of a set of ordered values. The
SDK for Java version 5 introduces the enum type for enumerated types.
You can include enums in the following places:
v In Java source files (.java files) that you include in an SQLJ program
v In SQLJ class declarations
Example: The TestEnum.sqlj class declaration includes an enum type:
public class TestEnum2
{
public enum Color {
RED,ORANGE,YELLOW,GREEN,BLUE,INDIGO,VIOLET}
Color color;
...
// Get the value of color
switch (color) {
case RED:
System.out.println("Red is at one end of the spectrum.");
#sql[ctx] { INSERT INTO MYTABLE VALUES (:color) };
break;
case VIOLET:
System.out.println("Violet is on the other end of the spectrum.");
break;
case ORANGE:
case YELLOW:
case GREEN:
case BLUE:
case INDIGO:
System.out.println("Everything else is in the middle.");
break;
}
Generics
You can use generics in your Java programs to assign a type to a Java collection.
The SQLJ translator tolerates Java generic syntax. Examples of generics that you
can use in SQLJ programs are:
v A List of List objects:
List <List<String>> strList2 = new ArrayList<List<String>>();
v A HashMap in which the key/value pair has the String type:
Map <String,String> map = new HashMap<String,String>();
v A method that takes a List with elements of any type:
public void mthd(List <?> obj) {
...
}
Chapter 4. SQLJ application programming
167
Although you can use generics in SQLJ host variables, the value of doing so is
limited because the SQLJ translator cannot determine the types of those host
variables.
Enhanced for loop
The enhanced for lets you specify that a set of operations is performed on each
member of a collection or array. You can use the iterator in the enhanced for loop
in host expressions.
Example: INSERT each of the items in array names into table TAB.
String[] names = {"ABC","DEF","GHI"};
for (String n : names)
{
#sql {INSERT INTO TAB (VARCHARCOL) VALUES(:n) };
}
Varargs
Varargs make it easier to pass an arbitrary number of values to a method. A Vararg
in the last argument position of a method declaration indicates that the last
arguments are an array or a sequence of arguments. An SQLJ program can use the
passed arguments in host expressions.
Example: Pass an arbitrary number of parameters of type Object, to a method that
inserts each parameter value into table TAB.
public void runThis(Object... objects) throws SQLException
{
for (Object obj : objects)
{
#sql { INSERT INTO TAB (VARCHARCOL) VALUES(:obj) };
}
}
Transaction control in SQLJ applications
In SQLJ applications, as in other types of SQL applications, transaction control
involves explicitly or implicitly committing and rolling back transactions, and
setting the isolation level for transactions.
Setting the isolation level for an SQLJ transaction
To set the isolation level for a unit of work within an SQLJ program, use the SET
TRANSACTION ISOLATION LEVEL clause.
The following table shows the values that you can specify in the SET
TRANSACTION ISOLATION LEVEL clause and their DB2 equivalents.
Table 28. Equivalent SQLJ and DB2 isolation levels
168
SET TRANSACTION value
DB2 isolation level
SERIALIZABLE
Repeatable read
REPEATABLE READ
Read stability
READ COMMITTED
Cursor stability
READ UNCOMMITTED
Uncommitted read
Application Programming Guide and Reference for Java
The isolation level affects the underlying JDBC connection as well as the SQLJ
connection.
Related concepts
“JDBC connection objects” on page 20
Committing or rolling back SQLJ transactions
If you disable autocommit for an SQLJ connection, you need to perform explicit
commit or rollback operations.
You do this using execution clauses that contain the SQL COMMIT or ROLLBACK
statements.
To commit a transaction in an SQLJ program, use a statement like this:
#sql [myConnCtx] {COMMIT};
To roll back a transaction in an SQLJ program, use a statement like this:
#sql [myConnCtx] {ROLLBACK};
Related tasks
“Committing or rolling back SQLJ transactions”
“Connecting to a data source using SQLJ” on page 113
Handling SQL errors and warnings in SQLJ applications
SQLJ clauses throw SQLExceptions when SQL errors occur, but not when most
SQL warnings occur.
SQLJ generates an SQLException under the following circumstances:
v When any SQL statement returns a negative SQL error code
v When a SELECT INTO SQL statement returns a +100 SQL error code
You need to explicitly check for other SQL warnings.
v For SQL error handling, include try/catch blocks around SQLJ statements.
v For SQL warning handling, invoke the getWarnings method after every SQLJ
statement.
Handling SQL errors in an SQLJ application
SQLJ clauses use the JDBC class java.sql.SQLException for error handling.
To handle SQL errors in SQLJ applications, following these steps:
1. Import the java.sql.SQLException class.
2. Use the Java error handling try/catch blocks to modify program flow when an
SQL error occurs.
3. Obtain error information from the SQLException.
You can use the getErrorCode method to retrieve SQL error codes and the
getSQLState method to retrieve SQLSTATEs.
If you are using the IBM Data Server Driver for JDBC and SQLJ, obtain
additional information from the SQLException by casting it to a DB2Diagnosable
object, in the same way that you obtain this information in a JDBC application.
The following code prints out the SQL error that occurred if a SELECT statement
fails.
Chapter 4. SQLJ application programming
169
try {
#sql [ctxt] {SELECT LASTNAME INTO :empname
FROM EMPLOYEE WHERE EMPNO=’000010’};
}
catch(SQLException e) {
System.out.println("Error code returned: " + e.getErrorCode());
}
Related tasks
“Handling an SQLException under the IBM Data Server Driver for JDBC and
SQLJ” on page 102
Handling SQL warnings in an SQLJ application
Other than a +100 SQL error code on a SELECT INTO statement, warnings from
the data server do not throw SQLExceptions. To handle warnings from the data
server, you need to give the program access to the java.sql.SQLWarning class.
If you want to retrieve data-server-specific information about a warning, you also
need to give the program access to the com.ibm.db2.jcc.DB2Diagnosable interface
and the com.ibm.db2.jcc.DB2Sqlca class. Then follow these steps:
1. Set up an execution context for that SQL clause. See "Control the execution of
SQL statements in SQLJ" for information on how to set up an execution context.
2. To check for a warning from the data server, invoke the getWarnings method
after you execute an SQLJ clause.
getWarnings returns the first SQLWarning object that an SQL statement
generates. Subsequent SQLWarning objects are chained to the first one.
3. To retrieve data-server-specific information from the SQLWarning object with the
IBM Data Server Driver for JDBC and SQLJ, follow the instructions in "Handle
an SQLException under the IBM Data Server Driver for JDBC and SQLJ".
The following example demonstrates how to retrieve an SQLWarning object for an
SQL clause with execution context execCtx. The numbers to the right of selected
statements correspond to the previously-described steps.
ExecutionContext execCtx=myConnCtx.getExecutionContext();
1
// Get default execution context from
// connection context
SQLWarning sqlWarn;
...
#sql [myConnCtx,execCtx] {SELECT LASTNAME INTO :empname
FROM EMPLOYEE WHERE EMPNO=’000010’};
if ((sqlWarn = execCtx.getWarnings()) != null)
2
System.out.println("SQLWarning " + sqlWarn);
Related tasks
“Handling SQL errors in an SQLJ application” on page 169
Closing the connection to a data source in an SQLJ application
When you have finished with a connection to a data source, you need to close the
connection to the data source. Doing so releases the connection context object's
DB2 and SQLJ resources immediately.
To close the connection to the data source, use one of the ConnectionContext.close
methods.
v If you execute ConnectionContext.close() or
ConnectionContext.close(ConnectionContext.CLOSE_CONNECTION), the connection
context, as well as the connection to the data source, are closed.
170
Application Programming Guide and Reference for Java
v If you execute ConnectionContext.close(ConnectionContext.KEEP_CONNECTION)
the connection context is closed, but the connection to the data source is not.
The following code closes the connection context, but does not close the connection
to the data source.
...
ctx = new EzSqljctx(con0);
// Create a connection context object
// from JDBC connection con0
...
// Perform various SQL operations
EzSqljctx.close(ConnectionContext.KEEP_CONNECTION);
// Close the connection context but keep
// the connection to the data source open
Related tasks
“Connecting to a data source using SQLJ” on page 113
Chapter 4. SQLJ application programming
171
172
Application Programming Guide and Reference for Java
Chapter 5. Java stored procedures and user-defined functions
Like stored procedures and user-defined functions in any other language, Java
stored procedures and user-defined functions are programs that can contain SQL
statements. You invoke Java stored procedures from a client program that is
written in any supported language.
The following topics contain information that is specific to defining and writing
Java user-defined functions and stored procedures.
In these topics, the word routine refers to either a stored procedure or a
user-defined function.
Related reference
Java sample JDBC stored procedure (DB2 9 for z/OS Stored Procedures:
Through the CALL and Beyond)
Java stored procedure returning a BLOB column (DB2 9 for z/OS Stored
Procedures: Through the CALL and Beyond)
Java stored procedure returning a CLOB column (DB2 9 for z/OS Stored
Procedures: Through the CALL and Beyond)
Debugging Java procedures on Linux, UNIX, and Windows (DB2 9 for z/OS
Stored Procedures: Through the CALL and Beyond)
Java sample SQLJ stored procedure (DB2 9 for z/OS Stored Procedures:
Through the CALL and Beyond)
Setting up the environment for Java routines
Before you can run Java routines, you need to set up a WLM environment and set
Java environment variables.
Before you can prepare and run Java routines, you need to satisfy the following
prerequisites:
v Java 2 Technology Edition, V5 or later.
The IBM Data Server Driver for JDBC and SQLJ supports only 31-bit Java
routines.
v TCP/IP
TCP/IP is required on the client and all database servers to which you connect.
v The version of the IBM Data Server Driver for JDBC and SQLJ that matches the
DB2 for z/OS version.
If you are migrating from a previous release of DB2 for z/OS, you need to
install the corresponding version of the IBM Data Server Driver for JDBC and
SQLJ.
This topic discusses the setup tasks for preparing and running Java routines.
If you plan to use IBM Optim Development Studio to prepare and run your Java
routines, see the information on developing database routines in the Integrated
Data Management Information Center, at the following URL:
http://publib.boulder.ibm.com/infocenter/idm/v2r1/index.jsp
© Copyright IBM Corp. 1998, 2011
173
To set up the environment for running Java routines, you need to perform these
tasks:
1. Ensure that your operating system, SDK for Java, and the IBM Data Server
Driver for JDBC and SQLJ are at the correct levels, and that you have installed
all prerequisite products.
Important: If you have migrated the DB2 subsystem from a previous release of
DB2 for z/OS, your existing Java stored procedures and user-defined function
no longer work with the previous release of the IBM Data Server Driver for
JDBC and SQLJ and the current release of DB2 for z/OS. You need to install the
version of the IBM Data Server Driver for JDBC and SQLJ that matches the
DB2 for z/OS release level, and update the WLM-managed stored procedure
address space configuration and JAVAENV data set to use the current driver.
2. Create the Workload Manager for z/OS (WLM) application environment for
running the routines.
3. Set up the run-time environment for Java routines, which includes setting
environment variables.
Setting up the WLM application environment for Java routines
You need different WLM application environments for Java routines from the
WLM application environments that you use for other routines.
To set up the WLM environment for Java routines, you need to perform these
steps:
1. Create a WLM environment startup procedure for Java routines.
2. Define the WLM environment to WLM.
WLM address space startup procedure for Java routines
The WLM address space startup procedure for Java routines requires extra DD
statements that other routines do not need.
The following figure shows an example of a startup procedure for an address
space in which Java routines can run. The JAVAENV DD statement indicates to
DB2 that the WLM environment is for Java routines.
//DSNWLM PROC RGN=0K,APPLENV=WLMIJAV,DB2SSN=DSN,NUMTCB=5, 1
//
MINSPAS=0
//IEFPROC EXEC PGM=DSNX9WLM,REGION=&RGN,TIME=NOLIMIT,
// PARM=’&DB2SSN,&NUMTCB,&APPLENV,&MINSPAS’
//STEPLIB DD DISP=SHR,DSN=DSNA10.RUNLIB.LOAD
// DD DISP=SHR,DSN=CEE.SCEERUN
// DD DISP=SHR,DSN=DSNA10.SDSNEXIT
// DD DISP=SHR,DSN=DSNA10.SDSNLOAD
// DD DISP=SHR,DSN=DSNA10.SDSNLOD2
//JAVAENV DD DISP=SHR,DSN=WLMIJAV.JSPENV
2
//JSPDEBUG DD SYSOUT=A
3
//CEEDUMP DD SYSOUT=A
//SYSPRINT DD SYSOUT=A
Figure 46. Startup procedure for a WLM address space in which a Java routine runs
Notes to Figure 46:
174
Application Programming Guide and Reference for Java
1
In this line:
v Change the DB2SSN value to your DB2 for z/OS subsystem name.
v Change the APPLENV value to the name of the application environment that
you set up for Java stored procedures.
v Choose a maximum value of NUMTCB of between 5 and 8. For testing a Java
stored procedure, NUMTCB=1 is recommended. With NUMTCB=1, only one
JVM is started, so refreshing the WLM environment after you change the stored
procedure takes less time.
2
3
v Change the MINSPAS value to the minimum number of stored procedure
address spaces that WLM starts and maintains. Valid values are 0 to 50. If you
specify 0, WLM starts and shuts down stored procedure address spaces as
applications require them. Specify a value of greater than 0 if the overhead of
starting and shutting down stored procedure address spaces and JVMs makes
your response time unacceptable.
JAVAENV specifies a data set that contains Language Environment® run-time
options for Java stored procedures. The presence of this DD statement indicates to
DB2 that the WLM environment is for Java routines. This data set must contain
the environment variable JAVA_HOME. This environment variable indicates to
DB2 that the WLM environment is for Java routines. JAVA_HOME also specifies
the highest-level directory in the set of directories that containing the Java SDK.
Specifies a data set into which DB2 puts information that you can use to debug
your stored procedure. The information that DB2 collects is for assistance in
debugging setup problems, and should be used only under the direction of IBM
Software Support. You should comment out this DD statement during production.
Related concepts
“WLM application environment values for Java routines”
“Runtime environment for Java routines” on page 176
WLM application environment values for Java routines
To define the application environment for Java routines to WLM, specify the
appropriate values on WLM setup panels.
Use values like those that are shown in the following screen examples.
File Utilities Notes Options Help
-----------------------------------------------------------------------Definition Menu
WLM Appl
Command ===> ___________________________________________________________
Definition data set . :
Definition name . . . .
Description . . . . . .
Select one of the
following options. . .
none
WLMENV
Environment for Java stored procedures
9
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Policies
Workloads
Resource Groups
Service Classes
Classification Groups
Classification Rules
Report Classes
Service Coefficients/Options
Application Environments
Scheduling Environments
Definition name
Specify the name of the WLM application environment that you are setting up
for stored procedures.
Description
Specify any value.
Chapter 5. Java stored procedures and user-defined functions
175
Options
Specify 9 (Application Environments).
Application-Environment Notes Options Help
-----------------------------------------------------------------------Create an Application Environment
Command ===> ___________________________________________________________
Application Environment Name
Description . . . . . . . .
Subsystem Type . . . . . . .
Procedure Name . . . . . . .
Start Parameters . . . . . .
.
.
.
.
.
:
.
.
.
.
WLMENV
Environment for Java stored procedures
DB2
DSN8WLMP
DB2SSN=DB2T,NUMTCB=3,APPLENV=WLMENV
_______________________________________
___________________________________
Limit on starting server address spaces for a subsystem instance:
1
1. No limit.
2. Single address space per system.
3. Single address spaces per sysplex.
Subsystem Type
Specify DB2.
Procedure Name
Specify a name that matches the name of the JCL startup procedure for the
stored procedure address spaces that are associated with this application
environment.
Start Parameters
If the DB2 subsystem in which the stored procedure runs is not in a sysplex,
specify a DB2SSN value that matches the name of that DB2 subsystem. If the
same JCL is used for multiple DB2 subsystems, specify DB2SSN=&IWMSSNM.
The NUMTCB value depends on the type of stored procedure you are running.
For running Java routines, specify a value between 5 and 8. Specify an
APPLENV value that matches the value that you specify on the CREATE
PROCEDURE or CREATE FUNCTION statement for the routines that run in
this application environment.
Limit on starting server address spaces for a subsystem instance
Specify 1 (no limit).
Related concepts
“WLM address space startup procedure for Java routines” on page 174
“Runtime environment for Java routines”
Runtime environment for Java routines
For Java routines, the startup procedure for the stored procedure address space
contains a JAVAENV DD statement. This statement specifies a data set that
contains Language Environment runtime options for the routines that run in the
stored procedure address space.
Create the data set for the runtime options with the characteristics that are listed in
the following table.
Table 29. Data set characteristics for the JAVAENV data set
176
Primary space allocation
1 block
Secondary space allocation
1 block
Record format
VB
Record length
255
Application Programming Guide and Reference for Java
Table 29. Data set characteristics for the JAVAENV data set (continued)
Block size
4096
After you create the data set, edit it to insert a Language Environment options
string, which has this form:
,
ENVAR( "
environment-variable
=
setting
"
),
XPLINK(ON),
MSGFILE(
,
ddname
,
recfm
,
lrecl
,
blksize
)
NOENQ
ENQ
The maximum length of the Language Environment runtime options string in a
JAVAENV data set for Java stored procedures is 245 bytes. If you exceed the
maximum length, DB2 truncates the contents but does not issue a message. If you
enter the contents of the JAVAENV data set on more than one line, DB2
concatenates the lines to form the runtime options string. The runtime options
string can contain no leading or trailing blanks. Within the string, only blanks that
are valid within an option are permitted.
If your environment variable list is long enough that the JAVAENV content is
greater than 245 bytes, you can put the environment variable list in a separate data
set in a separate file, and use the environment variable _CEE_ENVFILE to point to
that file.
The descriptions of the parameters are:
_CEE_ENVFILE
Specifies a z/OS UNIX System Services data set that contains some or all of
the settings for environment variables.
Use the _CEE_ENVFILE parameter if the length of environment variable string
causes the total length of the JAVAENV content to exceed 245 bytes, which is
the DB2 limit for the JAVAENV content.
The data set must be variable-length.The format for environment variable
settings in this data set is:
environment-variable-1=setting-1
environment-variable-2=setting-2
...
environment-variable-n=setting-n
You can specify some of your environment variable settings as arguments of
ENVAR and put some of the settings in this data set, or you can put all of
your environment variable settings in this data set.
For example, to use file /u/db2a10/javasp/jspnolimit.txt for environment
variable settings, specify:
_CEE_ENVFILE=/u/db2a10/javasp/jspnolimit.txt
ENVAR
Sets the initial values for specified environment variables. The environment
variables that you might need to specify are:
Chapter 5. Java stored procedures and user-defined functions
177
CLASSPATH
When you prepare your Java routines, if you do not put your routine
classes into JAR files, include the directories that contain those classes. For
example:
CLASSPATH=.:/U/DB2RES3/ACMEJOS
Do not include directories for JAR files for JDBC or the JDK in the
CLASSPATH. If you use a DB2JccConfiguration.properties file, you need to
include the directory that contains that file in the CLASSPATH.
DB2_BASE
The value of DB2_BASE is the highest-level directory in the set of HFS
directories that contain DB2 for z/OS code.
For example:
DB2_BASE=/usr/lpp/db2a10/base
The default is /usr/lpp/db2a10/base.
JAVA_HOME
This environment variable indicates to DB2 that the WLM environment is
for Java routines. The value of JAVA_HOME is the highest-level directory
in the set of directories that contain the SDK for Java. For example:
JAVA_HOME=/usr/lpp/java/IBM/J1.4.2
JCC_HOME
The value of JCC_HOME is the highest-level directory in the set of
directories that contain the JDBC driver. For example:
JCC_HOME=/usr/lpp/db2a10/jdbc
JCC_HOME must be set.
JDBCSTD
Specifies which version of the IBM Data Server Driver for JDBC and SQLJ
that Java routines use. Possible values are:
3
Java routines use the version of the driver that supports JDBC 3.0.
4
Java routines use the version of the driver that supports JDBC 4.0.
JVM_DEBUG_PORTRANGE
This environment variable specifies a range of ports that the JVM listens on
for debug connections, in the form low-port-number::high-port-number. The
default is ports 8000 to 8050. For example:
JVM_DEBUG_PORTRANGE=8051::8055
Specify JVM_DEBUG_PORTRANGE only for WLM environments that are
used for debugging Java routines.
JVMPROPS
This environment variable specifies the name of a z/OS UNIX System
Services file that contains startup options for the JVM in which the stored
procedure runs. For example:
JVMPROPS=/usr/lpp/java/properties/jvmsp
The following example shows the contents of a startup options file that
you might use for a JVM in which Java stored procedures run:
# Properties file for JVM for Java stored procedures
# Sets the initial size of middleware heap within non-system heap
-Xms64M
178
Application Programming Guide and Reference for Java
# Sets the maximum size of nonsystem heap
-Xmx128M
#initial size of system heap
-Xinitsh512K
For information about JVM startup options, see IBM 31-bit and 64-bit SDKs
for z/OS, Java 2 Technology Edition, Version 5 SDK and Runtime Environment
User Guide, available at:
http://www.ibm.com/servers/eserver/zseries/software/java
Click the Reference Information link.
LC_ALL
Modify LC_ALL to change the locale to use for the locale categories when
the individual locale environment variables specify locale information. This
value needs to match the CCSID for the DB2 subsystem on which the
stored procedures run. For example:
LC_ALL=En_US.IBM-037
TZ
Modify TZ to change the local timezone. For example:
TZ=PST08
The default is GMT.
USE_LIBJVM_G
Specifies whether the debug version of the JVM is used instead of the
default, non-debug version of the JVM. The debug version of the JVM is in
dynamic link library libjvm_g. If USE_LIBJVM_G is not specified, or its
value is anything other than the capitalized string YES, the non-debug
version of the JVM is used. For example, USE_LIBJVM_G=NO causes the
non-debug version of the JVM to be used.
If USE_LIBJVM_G=YES, the JVMPROPS environment variable must specify
a file that contains JVM startup options. That file must contain the startup
option -Djava.execsuffix=_g.
Specify USE_LIBJVM_G=YES only under the direction of IBM Software
Support.
WORK_DIR
Modify WORK_DIR to change the default destination for STDOUT and
STDERR output.
MSGFILE
Specifies the DD name of a data set in which Language Environment puts
runtime diagnostics. All subparameters in the MSGFILE parameter are
optional. The default is
MSGFILE(SYSOUT,FBA,121,0,NOENQ)
If you specify a data set name in the JSPDEBUG statement of your stored
procedure address space startup procedure, you need to specify JSPDEBUG as
the first parameter. If the NUMTCB value in the stored procedure address
space startup procedure is greater than 1, you need to specify ENQ as the fifth
subparameter. z/OS Language Environment Programming Reference contains
complete information about MSGFILE.
Chapter 5. Java stored procedures and user-defined functions
179
XPLINK(ON)
Causes the initialization of the XPLINK environment. This parameter is
required.
The following example shows the contents of a JAVAENV data set.
ENVAR("JCC_HOME=/usr/lpp/db2a10/jdbc",
"JAVA_HOME=/usr/lpp/javas14/J1.4.2",
"WORK_DIR=/u/db2a10/tmp"),
MSGFILE(JSPDEBUG,,,,ENQ)
For information on environment variables that are related to locales, see z/OS
C/C++ Programming Guide.
Related concepts
“WLM address space startup procedure for Java routines” on page 174
“WLM application environment values for Java routines” on page 175
Defining Java routines and JAR files to DB2
Before you can use a Java routine, you need to define it to DB2.
If the routine is in a JAR file, it is recommended that you also define the JAR file
to DB2. Alternatively, you can include the JAR file name in the CLASSPATH.
If you use IBM Optim Development Studio, IBM Optim Development Studio
creates the definitions. If you do not use IBM Optim Development Studio, perform
these steps:
1. Execute the CREATE PROCEDURE or CREATE FUNCTION statement to
define the routine to DB2. To alter the routine definition, use the ALTER
PROCEDURE or ALTER FUNCTION statement.
2. If the routines are in JAR files, define the JAR files to DB2.
v Use the SQLJ.INSTALL_JAR or SQLJ.DB2_INSTALL_JAR built-in stored
procedure to define the JAR files to DB2.
v After you have installed a JAR, if that JAR references classes in other
installed JARs, use the SQLJ.ALTER_JAVA_PATH stored procedure to specify
the class resolution path that the JVM searches to resolve those class
references.
v To replace the JAR file, use the SQLJ.REPLACE_JAR or
SQLJ.DB2_REPLACE_JAR stored procedure.
v To remove the JAR file, use the SQLJ.REMOVE_JAR or
SQLJ.DB2_REMOVE_JAR stored procedure.
SQLJ.INSTALL_JAR, SQLJ, SQLJ.REPLACE_JAR, and SQLJ.REMOVE_JAR can
be used only with the local DB2 catalog. The other stored procedures can be
used with remote or local DB2 catalogs.
Definition of a Java routine to DB2
Before you can use a Java routine, you need to define it to DB2 using the CREATE
PROCEDURE or CREATE FUNCTION statement.
The definition for a Java routine is much like the definition for a routine in any
other language. However, the following parameters have different meanings for
Java routines.
180
Application Programming Guide and Reference for Java
LANGUAGE
Specifies the application programming language in which the routine is
written.
Specify LANGUAGE JAVA.
You cannot specify LANGUAGE JAVA for a user-defined table function.
EXTERNAL NAME
Specifies the program that runs when the procedure name is specified in a
CALL statement or the user-defined function name is specified in an SQL
statement. For Java routines, the argument of EXTERNAL NAME is a string
that is enclosed in single quotation marks. The EXTERNAL NAME clause for a
Java routine has the following syntax:
EXTERNAL NAME
'
class-name.method-name
(1)
JAR-name:
(2)
'
(method-signature)
package-name .
Notes:
1
For compatibility with DB2 for Linux, UNIX, and Windows, you can use an exclamation point (!)
after JAR-name instead of a colon.
2
For compatibility with previous versions of DB2, you can use a slash (/) after package-name instead
of a period.
Whether you include JAR-name depends on where the Java code for the routine
resides. If you create a JAR file from the class file for the routine (the output
from the javac command), you need to include JAR-name. You must create the
JAR file and define the JAR file to DB2 before you execute the CREATE
PROCEDURE or CREATE FUNCTION statement. If some other user executes
the CREATE PROCEDURE or CREATE FUNCTION statement, you need to
grant the USAGE privilege on the JAR to them.
If you use a JAR file, that JAR file must refer to classes that are contained in
that JAR file, are found in the CLASSPATH, or are system-supplied. Classes
that are in directories that are referenced in DB2_HOME or JCC_HOME, and
JAVA_HOME do not need to be included in the JAR file.
Whether you include (method-signature) depends on the following factors:
v The way that you define the parameters in your routine method
Each SQL data type has a corresponding default Java data type. If your
routine method uses data types other than the default types, you need to
include a method signature in the EXTERNAL NAME clause. A method
signature is a comma-separated list of data types.
v Whether you overload a Java routine
If you have several Java methods in the same class, with the same name and
different parameter types, you need to specify the method signature to
indicate which version of the program is associated with the Java routine.
If your stored procedure returns result sets, you also need to include a
parameter in the method signature for each result set. The parameter can be in
one of the following forms:
v java.sql.ResultSet[]
v An array of an SQLJ iterator class
Chapter 5. Java stored procedures and user-defined functions
181
You do not include these parameters in the parameter list of the SQL CALL
statement when you invoke the stored procedure.
Example: EXTERNAL NAME clause for a Java user-defined function: Suppose that
you write a Java user-defined function as method getSals in class S1Sal and
package s1. You put S1Sal in a JAR file named sal_JAR and install that JAR in
DB2. The EXTERNAL NAME parameter is :
EXTERNAL NAME ’sal_JAR:s1.S1Sal.getSals’
Example: EXTERNAL NAME clause for a Java stored procedure: Suppose that you
write a Java stored procedure as method getSals in class S1Sal. You put S1Sal
in a JAR file named sal_JAR and install that JAR in DB2. The stored procedure
has one input parameter of type INTEGER and returns one result set. The Java
method for the stored procedure receives one parameter of type
java.lang.Integer, but the default Java data type for an SQL type of INTEGER is
int, so the EXTERNAL NAME clause requires a signature clause. The
EXTERNAL NAME parameter is :
EXTERNAL NAME ’sal_JAR:S1Sal.getSals(java.lang.Integer,java.sql.ResultSet[])’
NO SQL
Indicates that the routine does not contain any SQL statements.
For a Java routine that is stored in a JAR file, you cannot specify NO SQL.
PARAMETER STYLE
Identifies the linkage convention that is used to pass parameters to the routine.
For a Java routine, the only value that is valid is PARAMETER STYLE JAVA.
You cannot specify PARAMETER STYLE JAVA for a user-defined table
function.
WLM ENVIRONMENT
Identifies the MVS workload manager (WLM) environment in which the
routine is to run.
If you do not specify this parameter, the routine runs in the default WLM
environment that was specified when DB2 was installed.
PROGRAM TYPE
Specifies whether Language Environment runs the routine as a main routine or
a subroutine.
This parameter value must be PROGRAM TYPE SUB.
RUN OPTIONS
Specifies the Language Environment run-time options to be used for the
routine.
This parameter has no meaning for a Java routine. If you specify this
parameter with LANGUAGE JAVA, DB2 issues an error.
SCRATCHPAD
Specifies that when the user-defined function is invoked for the first time, DB2
allocates memory for a scratchpad.
You cannot use a scratchpad in a Java user-defined function. Do not specify
SCRATCHPAD when you create or alter a Java user-defined function.
FINAL CALL
Specifies that a final call is made to the user-defined function, which the
function can use to free any system resources that it has acquired.
182
Application Programming Guide and Reference for Java
You cannot perform a final call when you call a Java user-defined function. Do
not specify FINAL CALL when you create or alter a Java user-defined function.
DBINFO
Specifies that when the routine is invoked, an additional argument is passed
that contains environment information.
You cannot pass the additional argument when you call a Java routine. Do not
specify DBINFO when you call a Java routine.
SECURITY
Specifies how the routine interacts with an external security product, such as
RACF, to control access to non-SQL resources. The values of the SECURITY
parameter are the same for a Java routine as for any other routine. However,
the value of the SECURITY parameter determines the authorization ID that
must have authority to access z/OS UNIX System Services. The values of
SECURITY and the IDs that must have access to z/OS UNIX System Services
are:
DB2
The user ID that is defined for the stored procedure address space in
the RACF started-procedure table.
EXTERNAL
The invoker of the routine.
DEFINER
The definer of the routine.
ALLOW DEBUG MODE, DISALLOW DEBUG MODE, or DISABLE DEBUG
MODE
Specifies whether a Java stored procedure can be run in debugging mode.
When DYNAMICRULES run behavior is in effect, the default is determined by
using the value of the CURRENT DEBUG MODE special register. Otherwise
the default is DISALLOW DEBUG MODE.
ALLOW DEBUG MODE
Specifies that the procedure can be run in debugging mode.
DISALLOW DEBUG MODE
Specifies that the procedure cannot be run in debugging mode.
You can use an ALTER PROCEDURE statement to change this option to
ALLOW DEBUG MODE.
DISABLE DEBUG MODE
Specifies that the procedure can never be run in debugging mode.
The procedure cannot be changed to specify ALLOW DEBUG MODE or
DISALLOW DEBUG MODE once the procedure has been created or altered
using DISABLE DEBUG MODE. To change this option, you must drop and
recreate the procedure using the desired option.
Example: Defining a Java stored procedure: Suppose that you have written and
prepared a stored procedure that has these characteristics:
Fully-qualified procedure name
Parameters
Language
Collection ID for the stored procedure
package
Package, class, and method name
Type of SQL statements in the program
SYSPROC.S1SAL
DECIMAL(10,2) INOUT
Java
DSNJDBC
s1.S1Sal.getSals
Statements that modify DB2 tables
Chapter 5. Java stored procedures and user-defined functions
183
WLM environment name
Maximum number of result sets returned
WLMIJAV
1
This CREATE PROCEDURE statement defines the stored procedure to DB2:
CREATE PROCEDURE SYSPROC.S1SAL
(DECIMAL(10,2) INOUT)
FENCED
MODIFIES SQL DATA
COLLID DSNJDBC
LANGUAGE JAVA
EXTERNAL NAME ’s1.S1Sal.getSals’
WLM ENVIRONMENT WLMIJAV
DYNAMIC RESULT SETS 1
PROGRAM TYPE SUB
PARAMETER STYLE JAVA;
Example: Defining a Java user-defined function: Suppose that you have written and
prepared a user-defined function that has these characteristics:
Fully-qualified function name
Input parameter
Data type of returned value
Language
Collection ID for the function package
Package, class, and method name
Java data type of the method input
parameter
JAR file that contains the function class
Type of SQL statements in the program
Function is called when input parameter is
null?
WLM environment name
MYSCHEMA.S2SAL
INTEGER
VARCHAR(20)
Java
DSNJDBC
s2.S2Sal.getSals
java.lang.Integer
sal_JAR
Statements that modify DB2 tables
Yes
WLMIJAV
This CREATE FUNCTION statement defines the user-defined function to DB2:
CREATE FUNCTION MYSCHEMA.S2SAL(INTEGER)
RETURNS VARCHAR(20)
FENCED
MODIFIES SQL DATA
COLLID DSNJDBC
LANGUAGE JAVA
EXTERNAL NAME ’sal_JAR:s2.S2Sal.getSals(java.lang.Integer)’
WLM ENVIRONMENT WLMIJAV
CALLED ON NULL INPUT
PROGRAM TYPE SUB
PARAMETER STYLE JAVA;
In this function definition, you need to specify a method signature in the
EXTERNAL NAME clause because the data type of the method input parameter is
different from the default Java data type for an SQL type of INTEGER.
184
Application Programming Guide and Reference for Java
Related concepts
“Definition of a JAR file for a Java routine to DB2”
Related reference
ALTER FUNCTION (external) (DB2 SQL)
ALTER PROCEDURE (external) (DB2 SQL)
CREATE FUNCTION (DB2 SQL)
CREATE PROCEDURE (external) (DB2 SQL)
Definition of a JAR file for a Java routine to DB2
One way to organize the classes for a Java routine is to collect those classes into a
JAR file. If you do this, you need to install the JAR file into the DB2 catalog.
DB2 provides built-in stored procedures that perform the following functions for
the JAR file:
SQLJ.INSTALL_JAR
Installs a JAR file into the local DB2 catalog.
SQLJ.DB2_INSTALL_JAR
Installs a JAR file into the local DB2 catalog or a remote DB2 catalog.
SQLJ.REPLACE_JAR
Replaces an existing JAR file in the local DB2 catalog.
SQLJ.DB2_REPLACE_JAR
Replaces an existing JAR file in the local DB2 catalog or a remote DB2 catalog.
SQLJ.REMOVE_JAR
Deletes a JAR file from the local DB2 catalog or a remote DB2 catalog.
SQLJ.ALTER_JAVA_PATH
Modifies the class resolution path of an previously installed JAR file to a
specified value.
You can use IBM Optim Development Studio to install JAR files into the DB2
catalog, or you can write a client program that executes SQL CALL statements to
invoke these stored procedures.
Related concepts
“Definition of a Java routine to DB2” on page 180
SQLJ.INSTALL_JAR stored procedure
SQLJ.INSTALL_JAR creates a new definition of a JAR file in the local DB2 catalog.
SQLJ.INSTALL_JAR authorization
Privilege set: If the CALL statement is embedded in an application program, the
privilege set consists of the privileges that are held by the authorization ID of the
owner of the plan or package. If the statement is dynamically prepared, the
privilege set consists of the privileges that are held by the authorization IDs of the
process.
For calling SQLJ.INSTALL_JAR, the privilege set must include at least one of the
following items:
v EXECUTE privilege on SQLJ.INSTALL_JAR
v Ownership of SQLJ.INSTALL_JAR
Chapter 5. Java stored procedures and user-defined functions
185
v SYSADM authority
The privilege set must also include the authority to install a JAR, which consists of
at least one of the following items:
v CREATEIN privilege on the schema of the JAR
The authorization ID that matches the schema name implicitly has the
CREATEIN privilege on the schema.
v SYSADM or SYSCTRL authority
SQLJ.INSTALL_JAR syntax
CALL SQLJ.INSTALL_JAR (
url,
JAR-name, deploy
)
SQLJ.INSTALL_JAR parameters
url A VARCHAR(1024) input parameter that identifies the z/OS UNIX System
Services full path name for the JAR file that is to be installed in the DB2
catalog. The format is file://path-name or file:/path-name.
JAR-name
A VARCHAR(257) input parameter that contains the DB2 name of the JAR, in
the form schema.JAR-id or JAR-id. JAR-name is the name that you use when you
refer to the JAR in SQL statements. If you omit schema, DB2 uses the SQL
authorization ID that is in the CURRENT SCHEMA special register. The owner
of the JAR is the authorization ID in the CURRENT SQLID special register.
deploy
An INTEGER input parameter that indicates whether additional actions are to
be performed after the JAR file is installed. Additional actions are not
supported, so this value is 0.
SQLJ.INSTALL_JAR example
Suppose that you want to install the JAR file that is in path /u/db2inst3/apps/
BUILDPLAN/BUILDPLAN.jar. You want to refer to the JAR file as
DB2INST3.BUILDPLAN in SQL statements. Use a CALL statement similar to this
one.
CALL SQLJ.INSTALL_JAR(’file:/u/db2inst3/apps/BUILDPLAN/BUILDPLAN.jar’,
’DB2INST3.BUILDPLAN’,0)
SQLJ.DB2_INSTALL_JAR stored procedure
SQLJ.DB2_INSTALL_JAR creates a new definition of a JAR file in the local DB2
catalog or in a remote DB2 catalog.
To install a JAR file at a remote location, you need to execute a CONNECT
statement to connect to that location before you call SQLJ.DB2_INSTALL_JAR.
SQLJ.DB2_INSTALL_JAR authorization
Privilege set: If the CALL statement is embedded in an application program, the
privilege set consists of the privileges that are held by the authorization ID of the
owner of the plan or package. If the statement is dynamically prepared, the
privilege set consists of the privileges that are held by the authorization IDs of the
process.
186
Application Programming Guide and Reference for Java
For calling SQLJ.DB2_INSTALL_JAR, the privilege set must include at least one of
the following items:
v EXECUTE privilege on SQLJ.DB2_INSTALL_JAR
v Ownership of SQLJ.DB2_INSTALL_JAR
v SYSADM authority
The privilege set must also include the authority to install a JAR, which consists of
at least one of the following items:
v CREATEIN privilege on the schema of the JAR
The authorization ID that matches the schema name implicitly has the
CREATEIN privilege on the schema.
v SYSADM or SYSCTRL authority
SQLJ.DB2_INSTALL_JAR syntax
CALL SQLJ.DB2_INSTALL_JAR (
Jar-locator, JAR-name, deploy
)
SQLJ.DB2_INSTALL_JAR parameters
JAR-locator
A BLOB locator input parameter that points to the JAR file that is to be
installed in the DB2 catalog.
JAR-name
A VARCHAR(257) input parameter that contains the DB2 name of the JAR, in
the form schema.JAR-id or JAR-id. JAR-name is the name that you use when you
refer to the JAR in SQL statements. If you omit schema, DB2 uses the SQL
authorization ID that is in the CURRENT SCHEMA special register. The owner
of the JAR is the authorization ID in the CURRENT SQLID special register.
deploy
An INTEGER input parameter that indicates whether additional actions are to
be performed after the JAR file is installed. Additional actions are not
supported, so this value is 0.
SQLJ.DB2_INSTALL_JAR example
Suppose that you want to install the JAR file that is in path /u/db2inst3/apps/
BUILDPLAN/BUILDPLAN.jar. You want to refer to the JAR file as
DB2INST3.BUILDPLAN in SQL statements. The following Java program installs
that JAR file.
import java.sql.*; // JDBC classes
import java.io.IOException;
import java.io.File;
import java.io.FileInputStream;
class SimpleInstallJar
{
public static void main (String argv[])
{
String url = "jdbc:db2://sysmvs1.stl.ibm.com:5021";
String jarname = "DB2INST3.BUILDPLAN";
String jarfile =
"/u/db2inst3/apps/BUILDPLAN/BUILDPLAN.jar";
try
{
Class.forName ("com.ibm.db2.jcc.DB2Driver").newInstance ();
Connection con =
Chapter 5. Java stored procedures and user-defined functions
187
DriverManager.getConnection(url, "MYID", "MYPW");
File aFile = new File(jarfile);
FileInputStream inputStream = new FileInputStream(aFile);
CallableStatement stmt;
String sql = "Call SQLJ.DB2_INSTALL_JAR(?, ?, ?)";
stmt = con.prepareCall(sql);
stmt.setBinaryStream(1, inputStream, (int)aFile.length());
stmt.setString(2, jarname);
stmt.setInt(3, 0);
boolean isrs = stmt.execute();
stmt.close();
System.out.println("Installation of JAR succeeded");
con.commit();
con.close();
}
catch (Exception e)
{
System.out.println("Installation of JAR failed");
e.printStackTrace ();
}
}
}
SQLJ.REPLACE_JAR stored procedure
SQLJ.REPLACE_JAR replaces an existing JAR file in the local DB2 catalog.
SQLJ.REPLACE_JAR authorization
Privilege set: If the CALL statement is embedded in an application program, the
privilege set consists of the privileges that are held by the authorization ID of the
owner of the plan or package. If the statement is dynamically prepared, the
privilege set consists of the privileges that are held by the authorization IDs of the
process.
For calling SQLJ.REPLACE_JAR, the privilege set must include at least one of the
following items:
v EXECUTE privilege on SQLJ.REPLACE_JAR
v Ownership of SQLJ.REPLACE_JAR
v SYSADM authority
The privilege set must also include the authority to replace a JAR, which consists
of at least one of the following items:
v Ownership of the JAR
v ALTERIN privilege on the schema of the JAR
The authorization ID that matches the schema name implicitly has the ALTERIN
privilege on the schema.
v SYSADM or SYSCTRL authority
SQLJ.REPLACE_JAR syntax
CALL SQLJ.REPLACE_JAR (
url,
JAR-name )
SQLJ.REPLACE_JAR parameters
url A VARCHAR(1024) input parameter that identifies the z/OS UNIX System
Services full path name for the JAR file that replaces the existing JAR file in
the DB2 catalog. The format is file://path-name or file:/path-name.
188
Application Programming Guide and Reference for Java
JAR-name
A VARCHAR(257) input parameter that contains the DB2 name of the JAR, in
the form schema.JAR-id or JAR-id. JAR-name is the name that you use when you
refer to the JAR in SQL statements. If you omit schema, DB2 uses the SQL
authorization ID that is in the CURRENT SCHEMA special register.
SQLJ.REPLACE_JAR example
Suppose that you want to replace a previously installed JAR file that is named
DB2INST3.BUILDPLAN with the JAR file that is in path /u/db2inst3/apps/
BUILDPLAN2/BUILDPLAN.jar. Use a CALL statement similar to this one.
CALL SQLJ.REPLACE_JAR(’file:/u/db2inst3/apps/BUILDPLAN2/BUILDPLAN.jar’,
’DB2INST3.BUILDPLAN’)
SQLJ.DB2_REPLACE_JAR stored procedure
SQLJ.DB2_REPLACE_JAR replaces an existing JAR file in the local DB2 catalog or
in a remote DB2 catalog.
To replace a JAR file at a remote location, you need to execute a CONNECT
statement to connect to that location before you call SQLJ.DB2_REPLACE_JAR.
SQLJ.DB2_REPLACE_JAR authorization
Privilege set: If the CALL statement is embedded in an application program, the
privilege set consists of the privileges that are held by the owner of the plan or
package. If the statement is dynamically prepared, the privilege set consists of the
privileges that are held by the authorization IDs of the process.
For calling SQLJ.DB2_REPLACE_JAR, the privilege set must include at least one of
the following items:
v EXECUTE privilege on SQLJ.DB2_REPLACE_JAR
v Ownership of SQLJ.DB2_REPLACE_JAR
v SYSADM authority
The privilege set must also include the authority to replace a JAR, which consists
of at least one of the following items:
v Ownership of the JAR
v ALTERIN privilege on the schema of the JAR
The authorization ID that matches the schema name implicitly has the ALTERIN
privilege on the schema.
v SYSADM or SYSCTRL authority
SQLJ.DB2_REPLACE_JAR syntax
CALL SQLJ.DB2_REPLACE_JAR (
JAR-locator, JAR-name
)
SQLJ.DB2_REPLACE_JAR parameters
JAR-locator
A BLOB locator input parameter that points to the JAR file that is to be
replaced in the DB2 catalog.
JAR-name
A VARCHAR(257) input parameter that contains the DB2 name of the JAR, in
Chapter 5. Java stored procedures and user-defined functions
189
the form schema.JAR-id or JAR-id. JAR-name is the name that you use when you
refer to the JAR in SQL statements. If you omit schema, DB2 uses the SQL
authorization ID that is in the CURRENT SCHEMA special register.
SQLJ.DB2_REPLACE_JAR example
Suppose that you want to replace a previously installed JAR file that is named
DB2INST3.BUILDPLAN with the JAR file that is in path /u/db2inst3/apps/
BUILDPLAN2/BUILDPLAN.jar. The following Java program replaces the JAR file.
import java.sql.*; // JDBC classes
import java.io.IOException;
import java.io.File;
import java.io.FileInputStream;
class SimpleInstallJar
{
public static void main (String argv[])
{
String url = "jdbc:db2://sysmvs1.stl.ibm.com:5021";
String jarname = "DB2INST3.BUILDPLAN";
String jarfile =
"/u/db2inst3/apps/BUILDPLAN2/BUILDPLAN.jar";
try
{
Class.forName ("com.ibm.db2.jcc.DB2Driver").newInstance ();
Connection con =
DriverManager.getConnection(url, "MYID", "MYPW");
File aFile = new File(jarfile);
FileInputStream inputStream = new FileInputStream(aFile);
CallableStatement stmt;
String sql = "Call SQLJ.DB2_REPLACE_JAR(?, ?)";
stmt = con.prepareCall(sql);
stmt.setBinaryStream(1, inputStream, (int)aFile.length());
stmt.setString(2, jarname);
boolean isrs = stmt.execute();
stmt.close();
System.out.println("Replacement of JAR succeeded");
con.commit();
con.close();
}
catch (Exception e)
{
System.out.println("Replacement of JAR failed");
e.printStackTrace ();
}
}
}
SQLJ.REMOVE_JAR stored procedure
SQLJ.REMOVE_JAR deletes a JAR file from the local DB2 catalog or from a remote
DB2 catalog.
To delete a JAR file at a remote location, you need to execute a CONNECT
statement to connect to that location before you call SQLJ.REMOVE_JAR.
The JAR cannot be referenced in the EXTERNAL NAME clause of an existing
routine, or in the path of an installed JAR.
SQLJ.REMOVE_JAR authorization
Privilege set: If the CALL statement is embedded in an application program, the
privilege set consists of the privileges that are held by the authorization ID of the
190
Application Programming Guide and Reference for Java
owner of the plan or package. If the statement is dynamically prepared, the
privilege set consists of the privileges that are held by the authorization IDs of the
process.
For calling SQLJ.REMOVE_JAR, the privilege set must include at least one of the
following items:
v EXECUTE privilege on SQLJ.REMOVE_JAR
v Ownership of SQLJ.REMOVE_JAR
v SYSADM authority
The privilege set must also include the authority to remove a JAR, which consists
of at least one of the following items:
v Ownership of the JAR
v DROPIN privilege on the schema of the JAR
The authorization ID that matches the schema name implicitly has the DROPIN
privilege on the schema.
v SYSADM or SYSCTRL authority
SQLJ.REMOVE_JAR syntax
CALL SQLJ.REMOVE_JAR (
JAR-name, undeploy
)
SQLJ.REMOVE_JAR parameters
JAR-name
A VARCHAR(257) input parameter that contains the DB2 name of the JAR that
is to be removed from the catalog, in the form schema.JAR-id or JAR-id.
JAR-name is the name that you use when you refer to the JAR in SQL
statements. If you omit schema, DB2 uses the SQL authorization ID that is in
the CURRENT SCHEMA special register.
undeploy
An INTEGER input parameter that indicates whether additional actions should
be performed before the JAR file is removed. Additional actions are not
supported, so this value is 0.
SQLJ.REMOVE_JAR example
Suppose that you want to remove a previously installed JAR file that is named
DB2INST3.BUILDPLAN. Use a CALL statement similar to this one.
CALL SQLJ.REMOVE_JAR(’DB2INST3.BUILDPLAN’,0)
SQLJ.ALTER_JAVA_PATH stored procedure
SQLJ.ALTER_JAVA_PATH modifies the class resolution path of an installed JAR.
SQLJ.ALTER_JAVA_PATH authorization
Privilege set: If the CALL statement is embedded in an application program, the
privilege set consists of the privileges that are held by the owner of the plan or
package. If the statement is dynamically prepared, the privilege set consists of the
privileges that are held by the authorization IDs of the process.
For calling SQLJ.ALTER_JAVA_PATH, the privilege set must include at least one of
the following items:
Chapter 5. Java stored procedures and user-defined functions
191
v EXECUTE privilege on SQLJ.ALTER_JAVA_PATH
v Ownership of SQLJ.ALTER_JAVA_PATH
v SYSADM authority
The privilege set must also include the authority to alter a JAR, which consists of
at least one of the following items:
v Ownership of the JAR
v ALTERIN privilege on the schema of the JAR
The authorization ID that matches the schema name implicitly has the ALTERIN
privilege on the schema.
v SYSADM or SYSCTRL authority
For referring to JAR jar2 in the Java path, the privilege set must include at least
one of the following items:
v Ownership of jar2
v USAGE privilege on jar2
v SYSADM authority
SQLJ.ALTER_JAVA_PATH syntax
CALL SQLJ.ALTER_JAVA_PATH (
JAR-name1,
'path'
'blanks'
''
)
path:
path-element
path-element:
(
*
Java-package-name .
, JAR-name2
)
*
class-name
Java-package-name .
Java-package-name:
Java-identifier .
Java-identifier
class-name:
Java-identifier
192
Application Programming Guide and Reference for Java
SQLJ.ALTER_JAVA_PATH parameters
JAR-name1
A VARCHAR(257) input parameter that contains the DB2 name of the JAR
whose path is to be altered, in the form schema.JAR-id or JAR-id. JAR-name1 is
the name that you use when you refer to the JAR in SQL statements. If you
omit schema, DB2 uses the SQL authorization ID that is in the CURRENT
SCHEMA special register.
path
A VARCHAR(2048) input parameter that specifies the class resolution path that
the JVM uses when JAR-name1 references a class that is neither contained in
JAR-name1, found in the CLASSPATH, nor system-supplied.
During execution of the Java routine, when DB2 encounters an unresolved
class reference, DB2 compares each path element in the path to the class
reference. If a path element matches the class reference, DB2 searches for the
class in the JAR that is specified by the path element.
*
Indicates that any class reference can be searched for in the JAR that is
identified by JAR-name2. If an error prevents the class from being found, the
search terminates, and a java.lang.ClassNotFoundException is thrown to
report that error. If the class is not found in the JAR, the search continues with
the next path element.
Java-package-name.*
Indicates that class references for classes that are in the package named
Java-package-name are searched for in the JAR that is identified by JAR-name2. If
an error prevents a class from being found, the search terminates, and a
java.lang.ClassNotFoundException is thrown to report that error. If a class is
not found in the JAR, the search terminates, and a
java.lang.NoClassDefFoundError is thrown.
If the class reference is to a class in a different package, the search continues
with the next path element.
Java-package-name.class-name or class-name
Indicates that class references for classes whose fully qualified name matches
Java-package-name.class-name or class-name are searched for in the JAR that is
identified by JAR-name2. Class references for classes that are in packages
within the package named Java-package-name are not searched for in the JAR
that is identified by JAR-name2. If an error prevents a class from being found,
the search terminates, and a java.lang.ClassNotFoundException is thrown to
report that error. If a class is not found in the JAR, the search terminates and a
java.lang.NoClassDefFoundError is thrown.
If the class reference is to a different class, the search continues with the next
path element.
JAR-name2
Specifies the DB2 name of the JAR that is to be searched. The form of
JAR-name2 is schema.JAR-id or JAR-id. If schema is omitted, the JAR name is
implicitly qualified with the schema name in the CURRENT SCHEMA special
register. JAR JAR-name2 must exist at the current server. JAR-name2 must not
be the same as JAR-name1.
SQLJ.ALTER_JAVA_PATH example
Suppose that the JAR file that is named DB2INST3.BUILDPLAN references classes
that are in a previously installed JAR that is named DB2INST3.BUILDPLAN2.
Chapter 5. Java stored procedures and user-defined functions
193
Those classes are in Java package buildPlan2. The following Java program calls
SQLJ.ALTER_JAVA_PATH to add the classes in the buildPlan2 package to the
resolution path for DB2INST3.BUILDPLAN.
import java.sql.*; // JDBC classes
import java.io.IOException;
import java.io.File;
import java.io.FileInputStream;
class SimpleInstallJar
{
public static void main (String argv[])
{
String url = "jdbc:db2://sysmvs1.stl.ibm.com:5021";
String jarname = "DB2INST3.BUILDPLAN";
String resolutionPath =
"(buildPlan2.*,DB2INST3.BUILDPLAN2)";
try
{
Class.forName ("com.ibm.db2.jcc.DB2Driver").newInstance ();
Connection con =
DriverManager.getConnection(url, "MYID", "MYPW");
CallableStatement stmt;
String sql = "Call SQLJ.ALTER_JAVA_PATH(?, ?)";
stmt = con.prepareCall(sql);
stmt.setString(1, jarname);
stmt.setString(2, resolutionPath);
boolean isrs = stmt.execute();
stmt.close();
System.out.println("Alteration of JAR resolution path succeeded");
con.commit();
con.close();
}
catch (Exception e)
{
System.out.println("Alteration of JAR resolution path failed");
e.printStackTrace ();
}
}
}
Java routine programming
A Java routine is a Java application program that runs in a stored procedure address
space. It can include JDBC methods or SQLJ clauses.
A Java routine is much like any other Java program and follows the same rules as
routines in other languages. It receives input parameters, executes Java statements,
optionally executes SQLJ clauses, JDBC methods, or a combination of both, and
returns output parameters.
Differences between Java routines and stand-alone Java
programs
Java routines differ in a few basic ways from stand-alone Java programs.
Those differences are:
v In a Java routine, a JDBC connection or an SQLJ connection context can use the
connection to the data source that processes the CALL statement or the
user-defined function invocation. The URL that identifies this default connection
is jdbc:default:connection.
v The top-level method for a Java routine must be declared as static and public.
194
Application Programming Guide and Reference for Java
Although you can use static and final variables in a Java routine without
problems, you might encounter problems when you use static and non-final
variables. You cannot guarantee that a static and non-final variable retains its
value in the following circumstances:
– Across multiple invocations of the same routine
– Across invocations of different routines that reference that variable
v As in routines in other languages, the SQL statements that you can execute in
the routine depend on whether you specify an SQL access level of CONTAINS
SQL, READS SQL DATA, or MODIFIES SQL DATA.
Related concepts
“Differences between Java routines and other routines”
Related reference
SQL statements allowed in external functions and stored procedures (DB2 SQL)
Differences between Java routines and other routines
Java routines differ in a few basic ways from routines that are written in other
programming languages.
A Java routine differs from stored procedures that are written in other languages in
the following ways:
v A Java routine must be defined with PARAMETER STYLE JAVA. PARAMETER
STYLE JAVA specifies that the routine uses a parameter-passing convention that
conforms to the Java language and SQLJ specifications. DB2 passes INOUT and
OUT parameters as single-entry arrays. This means that in your Java routine,
you must declare OUT or INOUT parameters as arrays. For example, suppose
that stored procedure sp_one_out has one output parameter of type int. You
declare the parameter like this:
public static void routine_one_out (int[] out_parm)
v Java routines that are Java main methods have these restrictions:
– The method must have a signature of String[]. It must be possible to map all
the parameters to Java variables of type java.lang.String.
– The routine can have only IN parameters.
v You cannot make instrumentation facility interface (IFI) calls in Java routines.
v You cannot specify an SQL access level of NO SQL for Java routines.
v As in other Java programs, you cannot include the following statements in a
Java routine:
– CONNECT
– RELEASE
– SET CONNECTION
v Routine parameters have different mappings to host language data types than
the mappings of routine parameters to host language parameters for other
languages.
v The technique for returning result sets from Java stored procedures is different
from the technique for returning result sets in other stored procedures.
v When a Java routine executes, Java dynamically loads classes when new class
references occur in the class that is being executed. During the class loading
process, a java.lang.ClassNotFoundException or
java.lang.NoClassDefFoundError can be thrown. These failures can occur
whether Java looks for the class in an installed JAR or in the CLASSPATH. If the
Java routine does not catch these errors and exceptions, the routine terminates
and an SQL error condition is reported.
Chapter 5. Java stored procedures and user-defined functions
195
Related concepts
“Differences between Java routines and stand-alone Java programs” on page 194
Related tasks
“Writing a Java stored procedure to return result sets”
Creating an external stored procedure (Application programming and SQL)
Writing an external user-defined function (Application programming and SQL)
Related reference
“Data types that map to database data types in Java applications” on page 211
Static and non-final variables in a Java routine
Using Java variables that are defined as static but not final can cause problems
for Java routines.
The reasons for those problems are:
v Use of variables that are static and non-final reduces portability.
Because the ANSI/ISO standard does not include support for static and
non-final variables, different database products might process those variables
differently.
v A sequence of routine invocations is not necessarily processed by the same JVM,
and static variable values are not shared among different JVMs.
For example, suppose that two stored procedures, INITIALIZE and PROCESS,
use the same static variable, sv1. INITIALIZE sets the value of sv1, and
PROCESS depends on the value of sv1. If INITIALIZE runs in one JVM, and
then PROCESS runs in another JVM, sv1 in PROCESS does not contain the value
that INTIALIZE set.
Specifying NUMTCB=1 in the WLM-established stored process space startup
procedure is not sufficient to guarantee that a sequence of routine invocations go
to the same JVM. Under load, multiple stored procedure address spaces are
initiated, and each address space has its own JVM. Multiple invocations might
be directed to multiple address spaces.
v In Java, the static variables for a class are initialized or reset whenever the class
is loaded. However, for Java routines, it is difficult to know when initialization
or reset of static variables occurs.
In certain cases, you need to declare variables as static and non-final. In those
cases, you can use the following technique to make your routines work correctly
with static variables.
To determine whether the values of static data in a routine have persisted across
routine invocations, define a static boolean variable in the class that contains the
routine. Initially set the variable to false, and then set it to true when you set the
value of static data. Check the value of the boolean variable at the beginning of the
routine. If the value is true, the static data has persisted. Otherwise, the data
values need to be set again. With this technique, static data values are not set for
most routine invocations, but are set more than once during the lifetime of the
JVM. Also, with this technique, it is not a problem for a routine to execute on
different JVMs for different invocations.
Writing a Java stored procedure to return result sets
You can write your Java stored procedures to return multiple query result sets to a
client program.
196
Application Programming Guide and Reference for Java
Your stored procedure can return multiple query result sets to a client program if
the following conditions are satisfied:
v The client supports the DRDA code points that are used to return query result
sets.
v The value of DYNAMIC RESULT SETS in the stored procedure definition is
greater than 0.
For each result set that you want to be returned, your Java stored procedure must
perform the following actions:
1. For each result set, include an object of type java.sql.ResultSet[] or an array of
an SQLJ iterator class in the parameter list for the stored procedure method.
If the stored procedure definition includes a method signature, for each result
set, include java.sql.ResultSet[] or the fully-qualified name of an array of a class
that is declared as an SQLJ iterator in the method signature. These result set
parameters must be the last parameters in the parameter list or method
signature. Do not include a java.sql.ResultSet array or an iterator array in the
SQL parameter list of the stored procedure definition.
2. Execute a SELECT statement to obtain the contents of the result set.
3. Retrieve any rows that you do not want to return to the client.
4. Assign the contents of the result set to element 0 of the java.sql.ResultSet[]
object or array of an SQLJ iterator class that you declared in step 1.
5. Do not close the ResultSet, the statement that generated the ResultSet, or the
connection that is associated with the statement that generated the ResultSet.
DB2 does not return result sets for ResultSets that are closed before the stored
procedure terminates.
The following code shows an example of a Java stored procedure that uses an
SQLJ iterator to retrieve a result set.
package s1;
import sqlj.runtime.*;
import java.sql.*;
import java.math.*;
#sql iterator NameSal(String LastName, BigDecimal Salary);
public class S1Sal
{
public static void getSals(BigDecimal[] AvgSalParm,
java.sql.ResultSet[] rs)
throws SQLException
{
NameSal iter1;
try
{
#sql iter1 = {SELECT LASTNAME, SALARY FROM EMP
WHERE SALARY>0 ORDER BY SALARY DESC};
#sql {SELECT AVG(SALARY) INTO :(AvgSalParm[0]) FROM EMP};
}
catch (SQLException e)
{
System.out.println("SQLCODE returned: " + e.getErrorCode());
throw(e);
}
rs[0] = iter1.getResultSet();
}
}
1
2
3
4
5
Figure 47. Java stored procedure that returns a result set
Chapter 5. Java stored procedures and user-defined functions
197
Notes to Figure 47 on page 197:
1
2
3
4
5
This SQLJ clause declares the iterator named NameSal, which is used to retrieve
the rows that will be returned to the stored procedure caller in a result set.
The declaration for the stored procedure method contains declarations for a single
passed parameter, followed by the declaration for the result set object.
This SQLJ clause executes the SELECT to obtain the rows for the result set,
constructs an iterator object that contains those rows, and assigns the iterator
object to variable iter1.
This SQLJ clause retrieves a value into the parameter that is returned to the stored
procedure caller.
This statement uses the getResultSet method to assign the contents of the iterator
to the result set that is returned to the caller.
Related concepts
“Retrieving multiple result sets from a stored procedure in an SQLJ application” on
page 148
Related tasks
“Retrieving multiple result sets from a stored procedure in a JDBC application” on
page 48
Techniques for testing a Java routine
You can test your Java routines as stand-alone programs, use the DB2 Unified
Debugger, or write your own debug information from the routines.
Test your routine as a stand-alone program
Before you invoke your Java routines from SQL applications, it is a good idea to
run the routines as stand-alone programs, which are easier to debug. A Java
program that runs as a routine requires only a DB2 package. However, before you
can run the program as a stand-alone program, you need to bind a DB2 plan for it.
Use the DB2 Unified Debugger (stored procedures only)
The DB2 Unified Debugger is available with DB2 Database for Linux, UNIX, and
Windows. The DB2 Unified Debugger provides a GUI interface for debugging Java
stored procedures. Information on the DB2 Unified Debugger is available in the
DB2 Database for Linux, UNIX, and Windows information center, at
http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp.
To set up a DB2 for z/OS subsystem to work with the DB2 Unified Debugger,
when you set up your stored procedure environment, follow these additional steps:
1. Customize and run the DSNTIJRT program to define stored procedures that
provide server support for the DB2 Unified Debugger.
DSNTIJSD is in the prefix.SDSNSAMP data set. The job prolog contains
customization instructions.
2. Define the stored procedure that you intend to test with the ALLOW DEBUG
MODE option in the CREATE PROCEDURE or ALTER PROCEDURE
statement.
3. When you prepare the stored procedure for execution, specify the -g option in
the javac command
-g causes the compiler to generate all debugging information for the program..
4. Grant the DEBUGSESSION privilege to the user who runs the debug client.
|
|
198
Application Programming Guide and Reference for Java
5. Make the following modifications to the WLM environment for the stored
procedure:
v In the WLM environment startup procedure, set NUMTCB=1
v In the WLM environment startup procedure, include a PSMDEBUG DD
statement to direct the debug diagnostic log to a data set. You can allocate to
a SYSOUT data set or to a preallocated data set. The data set needs to be
created with the RECFM=VBA and LRECL=4096 characteristics.
v In the ENVAR settings in the JAVAENV data set, set USE_LIBJVM_G=YES.
v If the debug port range of 8000::8050 is not acceptable, in the ENVAR
settings in the JAVAENV data set, set JVM_DEBUG_PORTRANGE to the
range of ports that the JVM listens on for debug connections.
Enable collection of DB2 debug information
Include a JSPDEBUG DD statement in your startup procedure for the stored
procedure address space. This DD statement specifies a data set to which DB2
writes debug information for use by IBM Software Support.
Write your own debug information from your routine
A useful technique for debugging is to include System.out.println and
System.err.println calls in your program to write messages to the STDERR and
STDOUT files.
STDERR and STDOUT output is written to the directory that is specified by the
WORK_DIR parameter in the JAVAENV data set, if that directory exists. If no
WORK_DIR parameter is specified, output goes to the default directory,
/tmp/java, if that directory exists.
Related concepts
“Runtime environment for Java routines” on page 176
Chapter 5. Java stored procedures and user-defined functions
199
200
Application Programming Guide and Reference for Java
Chapter 6. Preparing and running JDBC and SQLJ programs
You prepare and run DB2 for z/OS Java programs in the z/OS UNIX System
Services environment.
Program preparation for JDBC programs
Preparing a Java program that contains only JDBC methods is the same as
preparing any other Java program. You compile the program using the javac
command. No precompile or bind steps are required.
For example, to prepare the Sample01.java program for execution, execute this
command from the /usr/lpp/db2a10/jdbc/ directory:
javac Sample01.java
Program preparation for SQLJ programs
Program preparation for SQLJ programs involves translating, compiling,
customizing, and binding programs.
The following figure shows the steps of the program preparation process for a
program that uses the IBM Data Server Driver for JDBC and SQLJ.
Source
program
Modified
source
SQLJ
translator
Compile
Serialized
profile
Java class
file
Customize
Customized
serialized profile
Four
packages
Figure 48. The SQLJ program preparation process
The basic steps in SQLJ program preparation are:
1. Run the sqlj command from the z/OS UNIX System Services command line to
translate and compile the source code.
© Copyright IBM Corp. 1998, 2011
201
The SQLJ command generates a Java source program, optionally compiles the
Java source program, and produces zero or more serialized profiles. You can
compile the Java program separately, but the default behavior of the sqlj
command is to compile the program. The SQLJ command runs without
connecting to the database server.
2. Run the db2sqljcustomize command from the z/OS UNIX System Services
command line to customize the serialize profiles and bind DB2 packages.
The db2sqljcustomize command performs these tasks:
v Customizes the serialized profiles.
v Optionally does online checking to ensure that application variable types are
compatible with the corresponding column data types.
The default behavior is to do online checking. For better performance, you
should do online checking.
v Optionally binds DB2 packages on a specified database server.
The default behavior is to bind the DB2 packages. However, you can disable
automatic creation of packages and use the db2sqljbind command to bind the
packages later.
You might also need to run the db2sqljbind command under these
circumstances:
– If a bind fails when db2sqljcustomize runs
– if you want to create identical packages at multiple locations for the same
serialized profile
3. Optional: Bind the DB2 packages into a plan.
Use the DB2 BIND command to do that.
Related reference
“sqlj - SQLJ translator” on page 451
“db2sqljcustomize - SQLJ profile customizer” on page 454
“db2sqljbind - SQLJ profile binder” on page 466
Binding SQLJ applications to access multiple database servers
After you prepare an SQLJ program to run on one DB2 database server, you might
want to port that application to other environments that access different database
servers. For example, you might want to move your application from a test
environment to a production environment.
The general steps for enabling access of an existing SQLJ application to additional
database servers are:
1. Bind packages on each database server that you want to access.
Do not re-customize the serialized profiles. Customization stores a new package
timestamp in the serialized profile, which makes the new serialized profile
incompatible with the original package.
You can use one of the following methods to bind the additional DB2 packages:
v Run the db2sqljbind command against each of the database servers.
v Run the DB2 BIND PACKAGE command with the COPY option to copy the
original packages to each of the additional database servers.
You might need a different qualifier for unqualified DB2 objects on each of the
database servers. In that case, you need to specify a value for the QUALIFIER
bind option when you bind the new packages. If you use the db2sqljbind
202
Application Programming Guide and Reference for Java
command, you specify the QUALIFER option in the -bindoptions parameter,
not in the -qualifier parameter. The -qualifier parameter applies to online
checking only.
2. Specify the package collection for the DB2 packages.
By default, when an SQLJ application runs, the DB2 database server looks for
packages using the collection ID that is stored in the serialized profile. If the
collection ID for the additional DB2 packages that you create is different from
the collection ID in the serialized profile, you need to override the collection ID
that is in the serialized profile. You can do that in one of the following ways:
v Specify the collection ID with the pkList DataSource property or the
db2.jcc.pkList global property.
v Follow these steps:
a. Bind a plan for the application that includes the following packages:
– The package collection that you bound in the previous step
– The IBM Data Server Driver for JDBC and SQLJ packages
b. Specify the plan name in the planName DataSource property or the
db2.jcc.planName global property.
Binding a plan might simplify authorization for the application. You can
authorize users to execute the plan, rather than authorizing them to execute
each of the packages in the plan.
An existing SQLJ application was customized and bound using the following
db2sqljcustomize invocation:
db2sqljcustomize -url jdbc:db2://system1.svl.ibm.com:8000/ZOS1
-user user01 -password mypass
-rootPkgName WRKSQLJ
-qualifier WRK1
-collection MYCOL1
-bindoptions "CURRENTDATA NO QUALIFIER WRK1 "
-staticpositioned YES WrkTraceTest_SJProfile0.ser
In addition to accessing data at the location that is indicated by URL
jdbc:db2://system1.svl.ibm.com:8000/ZOS1, you want to use the application to
access data at the location that is indicated by jdbc:db2://
system2.svl.ibm.com:8000/ZOS2. On the ZOS2 system, DB2 objects have a qualifier
of WRK2, and the packages need to be in collection MYCOL2. You therefore need
to bind packages at location ZOS2, change the default qualifier to WRK2, and
specify the MYCOL2 collection for the packages. Use one of the following methods
to bind the packages:
v Run DB2 BIND with COPY to copy each of the packages (one for each isolation
level) from the ZOS1 system to the ZOS2 system:
BIND PACKAGE (ZOS2.MYCOL2) OWNER(USER01)
COPY(MYCOL.WRKSQLJ1) CURRENTDATA(NO)
BIND PACKAGE (ZOS2.MYCOL2) OWNER(USER01)
COPY(MYCOL.WRKSQLJ2) CURRENTDATA(NO)
BIND PACKAGE (ZOS2.MYCOL2) OWNER(USER01)
COPY(MYCOL.WRKSQLJ3) CURRENTDATA(NO)
BIND PACKAGE (ZOS2.MYCOL2) OWNER(USER01)
COPY(MYCOL.WRKSQLJ4) CURRENTDATA(NO)
QUALIFIER(WRK2) QUALIFIER(WRK2) QUALIFIER(WRK2) QUALIFIER(WRK2) -
v Run the db2sqljbind command to create DB2 packages on ZOS2 from the
serialized profile on ZOS1:
db2sqljbind -url jdbc:db2://system2.svl.ibm.com:8000/ZOS2
-user user01 -password mypass
-bindoptions "COLLECTION MYCOL2 QUALIFIER WRK2"
-staticpositioned YES WrkTraceTest_SJProfile0.ser
Chapter 6. Preparing and running JDBC and SQLJ programs
203
After you bind the packages, you need to ensure that when the application runs,
the DB2 database server at ZOS2 can find the packages. The collection ID in the
serialized profile is MYCOL1, so the DB2 database server looks in MYCOL1 for the
packages. When you run the application against the ZOS2 system, you need to
access packages in MYCOL2.
For applications that use IBM Data Server Driver for JDBC and SQLJ type 2
connectivity, use one of the following methods to tell the database server to look in
MYCOL2 as well as MYCOL1:
v Specify "MYCOL1.*,MYCOL2.*" in the pkList DataSource property:
pkList = MYCOL1.*,MYCOL2.*
v Bind a plan for the application that includes the packages in MYCOL2 and the
IBM Data Server Driver for JDBC and SQLJ packages:
BIND PLAN(WRKSQLJ) PKLIST(MYCOL1.*,MYCOL2.*,JDBCCOL.*)
Then specify WRKSQLJ in the planName DataSource property:
planName = WRKSQLJ
For applications that use IBM Data Server Driver for JDBC and SQLJ type 4
connectivity, specify "MYCOL1.*,MYCOL2.*" in the currentPackagePath DataSource
property.
Related tasks
“Program preparation for SQLJ programs” on page 201
Related reference
“db2sqljbind - SQLJ profile binder” on page 466
Program preparation for Java routines
The program preparation process for Java routines varies, depending on whether
the routines contain SQLJ clauses.
The following topics contain detailed information on program preparation for Java
routines.
Preparation of Java routines with no SQLJ clauses
Java routines that contain no SQLJ clauses are written entirely in JDBC. You can
use one of three methods to prepare Java routines with no SQLJ statements.
Those methods are:
v Prepare the Java routine to run from a JAR file. Running Java routines from JAR
files is recommended.
v Prepare the Java routine with no JAR file.
v Use IBM Optim Development Studio to prepare the routine.
You can use this method regardless of whether the routine is in a JAR file.
Preparing Java routines with no SQLJ clauses to run from a JAR
file
The recommended method of running Java routines is to run them from a JAR file.
The steps in the process are:
1. Run the javac command to compile the Java program to produce Java
bytecodes.
204
Application Programming Guide and Reference for Java
2. Run the jar command to collect the class files that contain the methods for
your routine into a JAR file. See 'Creating JAR files for Java routines" for
information on creating the JAR file.
3. Call the INSTALL_JAR stored procedure to define the JAR file to DB2.
4. If the installed JAR references classes in other installed JARs, call the
SQLJ.ALTER_JAVA_PATH stored procedure to specify the class resolution path
that the JVM searches to resolve those class references.
5. If another user defines the routine to DB2, execute the SQL GRANT USAGE
ON JAR statement to grant the privilege to use the JAR file to that user.
6. Execute the SQL CREATE PROCEDURE or CREATE FUNCTION statement to
define the routine to DB2. Specify the EXTERNAL NAME parameter with the
name of the JAR that you defined to DB2 in step 3.
7. Execute the SQL GRANT statement to grant the EXECUTE privilege on the
routine to the appropriate users.
Related concepts
“Program preparation for JDBC programs” on page 201
“Definition of a JAR file for a Java routine to DB2” on page 185
Related tasks
“Creating JAR files for Java routines” on page 208
Preparing Java routines with no SQLJ clauses and no JAR file
If you do not use a JAR file for a Java routine that has no SQLJ clauses, you need
to include the directories for the routine classes in the CLASSPATH.
The steps in the process of preparing Java routines with no SQLJ clauses and no
JAR file are:
1. Run the javac command to compile the Java program to produce Java
bytecodes.
2. Ensure that the zFS or HFS directory that contains the class files for your
routine is in the CLASSPATH for the WLM-established stored procedure
address space.
You specify this CLASSPATH in the JAVAENV data set. You specify the
JAVAENV data set using a JAVAENV DD statement in the startup procedure
for the WLM-established stored procedure address space.
If you need to modify the CLASSPATH environment variable in the JAVAENV
data set to include the directory for the Java routine's classes, you must restart
the WLM address space to make it use the modified CLASSPATH.
3. Execute the SQL CREATE PROCEDURE or CREATE FUNCTION statement to
define the routine to DB2. Specify the EXTERNAL NAME parameter without a
JAR name.
4. Execute the SQL GRANT statement to grant the EXECUTE privilege on the
routine to the appropriate users.
Related concepts
“Program preparation for JDBC programs” on page 201
“Runtime environment for Java routines” on page 176
Preparation of Java routines with SQLJ clauses
You can use one of three methods to prepare Java routines with SQLJ clauses.
Those methods are:
Chapter 6. Preparing and running JDBC and SQLJ programs
205
v Prepare the routine Java routine to run from a JAR file. Running Java routines
from JAR files is recommended.
v Prepare the routine Java routine with no JAR file.
v Use IBM Optim Development Studio to prepare the routine.
You can use this method regardless of whether the routine is in a JAR file.
Preparing Java routines with SQLJ clauses to run from a JAR
file
The recommended method of running Java routines with SQLJ clauses is to run
them from a JAR file.
The steps in the process of preparing Java routines with SQLJ clauses to run are:
1. Run the sqlj command to translate the source code to produce generated Java
source code and serialized profiles, and to compile the Java program to
produce Java bytecodes.
2. Run the db2sqljcustomize command to produce serialized profiles that are
customized for DB2 for z/OS and DB2 packages.
3. Run the jar command to package the class files that contain the methods for
your routine, and the profiles that you generated in step 2 into a JAR file. See
"Creating JAR files for Java routines" for information on creating the JAR file.
4. Call the INSTALL_JAR stored procedure to define the JAR file to DB2.
5. If the installed JAR references classes in other installed JARs, call the
SQLJ.ALTER_JAVA_PATH stored procedure to specify the class resolution path
that the JVM searches to resolve those class references.
6. If another user defines the routine to DB2, execute the SQL GRANT USAGE
ON JAR statement to grant the privilege to use the JAR file to that user.
7. Execute the SQL CREATE PROCEDURE or CREATE FUNCTION statement to
define the routine to DB2. Specify the EXTERNAL NAME parameter with the
name of the JAR that you defined to DB2 in step 4.
8. Execute the SQL GRANT statement to grant the EXECUTE privilege on the
routine to the appropriate users.
The following example demonstrates how to prepare a Java stored procedure that
contains SQLJ clauses for execution from a JAR file.
1. On z/OS UNIX System Services, run the sqlj command to translate and
compile the SQLJ source code.
Assume that the path for the stored procedure source program is
/u/db2res3/s1/s1sal.sqlj. Change to directory /u/db2res3/s1, and issue this
command:
sqlj s1sal.sqlj
After this process completes, the /u/db2res3/s1 directory contains these files:
s1sal.java
s1sal.class
s1sal_SJProfile0.ser
2. On z/OS UNIX System Services, run the db2sqljcustomize command to
produce serialized profiles that are customized for DB2 for z/OS and to bind
the DB2 packages for the stored procedure.
Change to the /u/db2res3 directory, and issue this command:
206
Application Programming Guide and Reference for Java
db2sqljcustomize -url jdbc:db2://mvs1:446/SJCEC1 \
-user db2adm -password db2adm \
-bindoptions "EXPLAIN YES" \
-collection ADMCOLL \
-rootpkgname S1SAL \
s1sal_SJProfile0.ser
After this process completes, s1sal_SJProfile0.ser contains a customized
serialized profile. The DB2 subsystem contains these packages:
S1SAL1
S1SAL2
S1SAL3
S1SAL4
3. On z/OS UNIX System Services, run the jar command to package the class
files that you created in step 1 on page 206 and the customized serialized
profile that you created in step 2 on page 206 into a JAR file.
Change to the /u/db2res3 directory, and issue this command:
jar -cvf s1sal.jar s1/*.class s1/*.ser
After this process completes, the /u/db2res3 directory contains this file:
s1sal.jar
4. Call the INSTALL_JAR stored procedure, which is on DB2 for z/OS, to define
the JAR file to DB2.
You need to execute the CALL statement from a static SQL program or from an
ODBC or JDBC program. The CALL statement looks similar to this:
CALL SQLJ.INSTALL_JAR(’file:/u/db2res3/s1sal.jar’,’MYSCHEMA.S1SAL’,0);
The exact form of the CALL statement depends on the language of the program
that issues the CALL statement.
After this process completes, the DB2 catalog contains JAR file
MYSCHEMA.S1SAL.
5. If the installed JAR references classes in other installed JARs, call the
SQLJ.ALTER_JAVA_PATH stored procedure, which is on DB2 for z/OS, to
specify the class resolution path that the JVM searches to resolve those class
references. You need to execute the CALL statement from a static SQL program
or from an ODBC or JDBC program.
6. If another user defines the routine to DB2, on DB2 for z/OS, execute the SQL
GRANT USAGE ON JAR statement to grant the privilege to use the JAR file to
that user.
Suppose that you want any user to be able to define the stored procedure to
DB2. This means that all users need the USAGE privilege on JAR
MYSCHEMA.S1SAL. To grant this privilege, execute this SQL statement:
GRANT USAGE ON JAR MYSCHEMA.S1SAL TO PUBLIC;
7. On DB2 for z/OS, execute the SQL CREATE PROCEDURE statement to define
the stored procedure to DB2:
CREATE PROCEDURE SYSPROC.S1SAL
(DECIMAL(10,2) INOUT)
FENCED
MODIFIES SQL DATA
COLLID ADMCOLL
LANGUAGE JAVA
EXTERNAL NAME ’MYSCHEMA.S1SAL:s1.S1Sal.getSals’
WLM ENVIRONMENT WLMIJAV
DYNAMIC RESULT SETS 1
PROGRAM TYPE SUB
PARAMETER STYLE JAVA;
Chapter 6. Preparing and running JDBC and SQLJ programs
207
8. On DB2 for z/OS, execute the SQL GRANT EXECUTE statement to grant the
privilege to run the routine to that user.
Suppose that you want any user to be able to run the routine. This means that
all users need the EXECUTE privilege on SYSPROC.S1SAL. To grant this
privilege, execute this SQL statement:
GRANT EXECUTE ON PROCEDURE SYSPROC.S1SAL TO PUBLIC;
Related concepts
“Definition of a JAR file for a Java routine to DB2” on page 185
Related tasks
“Program preparation for SQLJ programs” on page 201
“Creating JAR files for Java routines”
Preparing Java routines with SQLJ clauses and no JAR file
If you do not use a JAR file for a Java routine that contains SQLJ clauses, you need
to include the directories for the routine classes in the CLASSPATH.
The steps in the process for preparing Java routines that contain SQLJ clauses and
do not run from a JAR file are:
1. Run the sqlj command to translate the source code to produce generated Java
source code and serialized profiles, and to compile the Java program to
produce Java bytecodes.
2. Run the db2sqljcustomize command to produce serialized profiles that are
customized for DB2 for z/OS and DB2 packages.
3. Ensure that the zFS or HFS directory that contains the class files for your
routine is in the CLASSPATH for the WLM-established stored procedure
address space.
You specify this CLASSPATH in the JAVAENV data set. You specify the
JAVAENV data set using a JAVAENV DD statement in the startup procedure
for the WLM-established stored procedure address space.
If you need to modify the CLASSPATH environment variable in the JAVAENV
data set to include the directory for the Java routine's classes, you must restart
the WLM address space to make it use the modified CLASSPATH.
4. Use the SQL CREATE PROCEDURE or CREATE FUNCTION statement to
define the routine to DB2. Specify the EXTERNAL NAME parameter without a
JAR name.
5. Execute the SQL GRANT statement to grant the EXECUTE privilege on the
routine to the appropriate users.
Related concepts
“Runtime environment for Java routines” on page 176
Related tasks
“Program preparation for SQLJ programs” on page 201
Creating JAR files for Java routines
A convenient way to ensure that all modules of a Java routine are accessible is to
store those modules in a JAR file. You create the JAR file by running the jar
command in z/OS UNIX System Services.
The source code must be compiled. For Java routines with SQLJ clauses, the source
code must be translated, compiled, and customized.
To create the JAR file, follow these steps:
208
Application Programming Guide and Reference for Java
1. If the Java source file does not contain a package statement, change to the
directory that contains the class file for the Java routine, which you created by
running the javac command.
For example, if JDBC routine Add_customer.java is in /u/db2res3/acmejos,
change to directory /u/db2res3/acmejos.
If the Java source file contains a package statement, change to the directory that
is one level above the directory that is named in the package statement.
For example, suppose the package statement is:
package lvlOne.lvlTwo.lvlThree;
Change to the directory that contains lvlOne as an immediate subdirectory.
2. Run the jar command.
You might need to specify at least these options:
c
Creates a new or empty archive.
v
Generates verbose output on stderr.
f
Specifies that the argument immediately after the options list is the name of
the JAR file to be created.
For example, to create a JAR file named acmejos.jar from Add_customer.class,
which is in package acmejos, execute this jar command:
jar -cvf acmejos.jar acmejos/Add_customer.class
To create a JAR file for an SQLJ routine, you also need to include all generated
class files, such as classes that are generated for iterators, and all serialized
profile files. For example, suppose that all classes are declared to be in package
acmejos, and all class files, including generated class files, and all serialized
profile files for SQLJ routine Add_customer.sqlj are in directory
/u/db2res3/acmejos/. To create a JAR file named acmejos.jar, change the the
/u/db2res3 directory, and then issue this jar command:
jar -cvf acmejos.jar acmejos/*.class acmejos/*.ser
Running JDBC and SQLJ programs
You run a JDBC or SQLJ program using the java command. Before you run the
program, you need to ensure that the JVM can find all of the files that it needs.
To run a JDBC or SQLJ program, follow these steps:
1. Ensure that the program files can be found.
v For an SQLJ program, put the serialized profiles for the program in the same
directory as the class files for the program.
v Include directories for the class files that are used by the program in the
CLASSPATH.
2. Run the java command on the z/OS UNIX System Services command line, with
the top-level file name in the program as the argument.
To run a program that is in the EzJava class, add the directory that contains EzJava
to the CLASSPATH. Then run this command:
java EzJava
Related concepts
“Environment variables for the IBM Data Server Driver for JDBC and SQLJ” on
page 475
Chapter 6. Preparing and running JDBC and SQLJ programs
209
210
Application Programming Guide and Reference for Java
Chapter 7. JDBC and SQLJ reference information
The IBM implementations of JDBC and SQLJ provide a number of application
programming interfaces, properties, and commands for developing JDBC and SQLJ
applications.
Data types that map to database data types in Java applications
To write efficient JDBC and SQLJ programs, you need to use the best mappings
between Java data types and table column data types.
The following tables summarize the mappings of Java data types to JDBC and
database data types for a DB2 Database for Linux, UNIX, and Windows, DB2 for
z/OS, or IBM Informix system.
Data types for updating table columns
The following table summarizes the mappings of Java data types to database data
types for PreparedStatement.setXXX or ResultSet.updateXXX methods in JDBC
programs, and for input host expressions in SQLJ programs. When more than one
Java data type is listed, the first data type is the recommended data type.
Table 30. Mappings of Java data types to database server data types for updating database tables
Java data type
Database data type
short, java.lang.Short
SMALLINT
1
1
boolean , byte , java.lang.Boolean, java.lang.Byte
SMALLINT
int, java.lang.Integer
INTEGER
long, java.lang.Long
BIGINT11
float, java.lang.Float
REAL
double, java.lang.Double
DOUBLE
java.math.BigDecimal
DECIMAL(p,s)2
java.math.BigDecimal
DECFLOAT(n)3,4
java.lang.String
CHAR(n)5
java.lang.String
GRAPHIC(m)6
java.lang.String
VARCHAR(n)7
java.lang.String
VARGRAPHIC(m)8
java.lang.String
CLOB9
java.lang.String
XML10
byte[]
CHAR(n) FOR BIT DATA5
byte[]
VARCHAR(n) FOR BIT DATA7
byte[]
BINARY(n)5, 12
byte[]
VARBINARY(n)7, 12
byte[]
BLOB9
byte[]
ROWID
byte[]
XML10
© Copyright IBM Corp. 1998, 2011
211
Table 30. Mappings of Java data types to database server data types for updating database tables (continued)
Java data type
Database data type
java.sql.Blob
BLOB
java.sql.Blob
XML10
java.sql.Clob
CLOB
java.sql.Clob
DBCLOB9
java.sql.Clob
XML10
java.sql.Date
DATE
java.sql.Time
TIME
java.sql.Timestamp
TIMESTAMP, TIMESTAMP(p), TIMESTAMP WITH TIME ZONE,
TIMESTAMP(p) WITH TIME ZONE13,14
java.io.ByteArrayInputStream
BLOB
java.io.StringReader
CLOB
java.io.ByteArrayInputStream
CLOB
java.io.InputStream
XML10
com.ibm.db2.jcc.DB2RowID (deprecated)
ROWID
java.sql.RowId
ROWID
com.ibm.db2.jcc.DB2Xml (deprecated)
XML10
java.sql.SQLXML
XML10
Notes:
1. For column updates, the data server has no exact equivalent for the Java boolean or byte data types, but the best
fit is SMALLINT.
2. p is the decimal precision and s is the scale of the table column.
You should design financial applications so that java.math.BigDecimal columns map to DECIMAL columns. If
you know the precision and scale of a DECIMAL column, updating data in the DECIMAL column with data in a
java.math.BigDecimal variable results in better performance than using other combinations of data types.
3. n=16 or n=34.
4. DECFLOAT is valid for connections to DB2 Version 9.1 for z/OS, DB2 V9.5 for Linux, UNIX, and Windows, or
DB2 for i V6R1, or later database servers. Use of DECFLOAT requires the SDK for Java Version 5 (1.5) or later.
5. n<=255.
6. m<=127.
7. n<=32704.
8. m<=16352.
9. This mapping is valid only if the database server can determine the data type of the column.
10. XML is valid for connections to DB2 Version 9.1 for z/OS or later database servers or DB2 V9.1 for Linux, UNIX,
and Windows or later database servers.
11. BIGINT is valid for connections to DB2 Version 9.1 for z/OS or later database servers, DB2 V9.1 for Linux,
UNIX, and Windows or later database servers, and all supported DB2 for i database servers.
12. BINARY and VARBINARY are valid for connections to DB2 Version 9.1 for z/OS or later database servers or
DB2 for i5/OS® V5R3 and later database servers.
13. p indicates the timestamp precision, which is the number of digits in the fractional part of the timestamp.
0<=p<=12. The default is 6. TIMESTAMP(p) is supported for connections to DB2 Database for Linux, UNIX, and
Windows V9.7 and later and DB2 for z/OS V10 and later only.
14. The WITH TIME ZONE clause is supported for connections to DB2 for z/OS V10 and later only.
212
Application Programming Guide and Reference for Java
Data types for retrieval from table columns
The following table summarizes the mappings of DB2 or IBM Informix data types
to Java data types for ResultSet.getXXX methods in JDBC programs, and for
iterators in SQLJ programs. This table does not list Java numeric wrapper object
types, which are retrieved using ResultSet.getObject.
Table 31. Mappings of database server data types to Java data types for retrieving data from database server tables
SQL data type
Recommended Java data type or
Java object type
SMALLINT
short
byte, int, long, float, double,
java.math.BigDecimal, boolean,
java.lang.String
INTEGER
int
short, byte, long, float, double,
java.math.BigDecimal, boolean,
java.lang.String
BIGINT5
long
int, short, byte, float, double,
java.math.BigDecimal, boolean,
java.lang.String
DECIMAL(p,s) or NUMERIC(p,s)
java.math.BigDecimal
long, int, short, byte, float, double,
boolean, java.lang.String
DECFLOAT(n)1,2
java.math.BigDecimal
long, int, short, byte, float, double,
java.math.BigDecimal, boolean,
java.lang.String
REAL
float
long, int, short, byte, double,
java.math.BigDecimal, boolean,
java.lang.String
DOUBLE
double
long, int, short, byte, float,
java.math.BigDecimal, boolean,
java.lang.String
CHAR(n)
java.lang.String
long, int, short, byte, float, double,
java.math.BigDecimal, boolean,
java.sql.Date, java.sql.Time,
java.sql.Timestamp,
java.io.InputStream, java.io.Reader
VARCHAR(n)
java.lang.String
long, int, short, byte, float, double,
java.math.BigDecimal, boolean,
java.sql.Date, java.sql.Time,
java.sql.Timestamp,
java.io.InputStream, java.io.Reader
CHAR(n) FOR BIT DATA
byte[]
java.lang.String,
java.io.InputStream, java.io.Reader
VARCHAR(n) FOR BIT DATA
byte[]
java.lang.String,
java.io.InputStream, java.io.Reader
BINARY(n)6
byte[]
None
byte[]
None
java.lang.String
long, int, short, byte, float, double,
java.math.BigDecimal, boolean,
java.sql.Date, java.sql.Time,
java.sql.Timestamp,
java.io.InputStream, java.io.Reader
VARBINARY(n)
GRAPHIC(m)
6
Other supported Java data types
Chapter 7. JDBC and SQLJ reference information
213
Table 31. Mappings of database server data types to Java data types for retrieving data from database server
tables (continued)
SQL data type
Recommended Java data type or
Java object type
VARGRAPHIC(m)
java.lang.String
long, int, short, byte, float, double,
java.math.BigDecimal, boolean,
java.sql.Date, java.sql.Time,
java.sql.Timestamp,
java.io.InputStream, java.io.Reader
CLOB(n)
java.sql.Clob
java.lang.String
BLOB(n)
java.sql.Blob
byte[]3
DBCLOB(m)
No exact equivalent. Use
java.sql.Clob.
ROWID
java.sql.RowId
byte[], com.ibm.db2.jcc.DB2RowID
(deprecated)
XML4
java.sql.SQLXML
byte[], java.lang.String,
java.io.InputStream, java.io.Reader
DATE
java.sql.Date
java.sql.String, java.sql.Timestamp
TIME
java.sql.Time
java.sql.String, java.sql.Timestamp
TIMESTAMP, TIMESTAMP(p), TIMESTAMP java.sql.Timestamp
WITH TIME ZONE, TIMESTAMP(p) WITH
TIME ZONE7,8
Other supported Java data types
java.sql.String, java.sql.Date,
java.sql.Time, java.sql.Timestamp
Notes:
1. n=16 or n=34.
2. DECFLOAT is valid for connections to DB2 Version 9.1 for z/OS, DB2 V9.5 for Linux, UNIX, and Windows, or
DB2 for i V6R1, or later database servers. Use of DECFLOAT requires the SDK for Java Version 5 (1.5) or later.
3. This mapping is valid only if the database server can determine the data type of the column.
4. XML is valid for connections to DB2 Version 9.1 for z/OS or later database servers or DB2 V9.1 for Linux, UNIX,
and Windows or later database servers.
5. BIGINT is valid for connections to DB2 Version 9.1 for z/OS or later database servers, DB2 V9.1 for Linux, UNIX,
and Windows or later database servers, and all supported DB2 for i database servers.
6. BINARY and VARBINARY are valid for connections to DB2 Version 9.1 for z/OS or later database servers or DB2
for i5/OS V5R3 or later database servers.
7. p indicates the timestamp precision, which is the number of digits in the fractional part of the timestamp.
0<=p<=12. The default is 6. TIMESTAMP(p) is supported for connections to DB2 Database for Linux, UNIX, and
Windows V9.7 and later and DB2 for z/OS V10 and later only.
8. The WITH TIME ZONE clause is supported for connections to DB2 for z/OS V10 and later only.
Data types for calling stored procedures and user-defined
functions
The following table summarizes mappings of Java data types to JDBC data types
and DB2 or IBM Informix data types for calling user-defined function and stored
procedure parameters. The mappings of Java data types to JDBC data types are for
CallableStatement.registerOutParameter methods in JDBC programs. The
mappings of Java data types to database server data types are for parameters in
stored procedure or user-defined function invocations.
If more than one Java data type is listed in the following table, the first data type
is the recommended data type.
214
Application Programming Guide and Reference for Java
Table 32. Mappings of Java, JDBC, and SQL data types for calling stored procedures and user-defined functions
Java data type
JDBC data type
SQL data type1
boolean2, java.lang.Boolean
BIT
SMALLINT
byte , java.lang.Byte
TINYINT
SMALLINT
short, java.lang.Short
SMALLINT
SMALLINT
int, java.lang.Integer
INTEGER
INTEGER
long, java.lang.Long
BIGINT
BIGINT6
float, java.lang.Float
REAL
REAL
float, java.lang.Float
FLOAT
REAL
double, java.lang.Double
DOUBLE
DOUBLE
java.math.BigDecimal
DECIMAL
DECIMAL
java.math.BigDecimal
java.types.OTHER
DECFLOATn3
java.math.BigDecimal
com.ibm.db2.jcc.DB2Types.DECFLOAT
DECFLOATn3
java.lang.String
CHAR
CHAR
java.lang.String
CHAR
GRAPHIC
java.lang.String
VARCHAR
VARCHAR
java.lang.String
VARCHAR
VARGRAPHIC
java.lang.String
LONGVARCHAR
VARCHAR
java.lang.String
VARCHAR
CLOB
java.lang.String
LONGVARCHAR
CLOB
java.lang.String
CLOB
CLOB
byte[]
BINARY
CHAR FOR BIT DATA
byte[]
VARBINARY
VARCHAR FOR BIT
DATA
byte[]
BINARY
BINARY5
byte[]
VARBINARY
VARBINARY5
byte[]
LONGVARBINARY
VARCHAR FOR BIT
DATA
byte[]
VARBINARY
BLOB4
byte[]
LONGVARBINARY
BLOB4
java.sql.Date
DATE
DATE
java.sql.Time
TIME
TIME
java.sql.Timestamp
TIMESTAMP
TIMESTAMP,
TIMESTAMP(p),
TIMESTAMP WITH TIME
ZONE, TIMESTAMP(p)
WITH TIME ZONE7,8
java.sql.Blob
BLOB
BLOB
java.sql.Clob
CLOB
CLOB
java.sql.Clob
CLOB
DBCLOB
java.io.ByteArrayInputStream
None
BLOB
java.io.StringReader
None
CLOB
java.io.ByteArrayInputStream
None
CLOB
2
Chapter 7. JDBC and SQLJ reference information
215
Table 32. Mappings of Java, JDBC, and SQL data types for calling stored procedures and user-defined
functions (continued)
Java data type
JDBC data type
SQL data type1
com.ibm.db2.jcc.DB2RowID
(deprecated)
com.ibm.db2.jcc.DB2Types.ROWID
ROWID
java.sql.RowId
java.sql.Types.ROWID
ROWID
java.sql.SQLXML
java.sql.Types.SQLXML
XML
java.sql.ResultSet
com.ibm.db2.jcc.DB2Types.CURSOR
CURSOR type
Notes:
1. A DB2 for z/OS stored procedure or user-defined function parameter cannot have the XML data type.
2. A stored procedure or user-defined function that is defined with a SMALLINT parameter can be invoked with a
boolean or byte parameter. However, this is not recommended.
3. DECFLOAT parameters in Java routines are valid only for connections to DB2 Version 9.1 for z/OS or later
database servers. DECFLOAT parameters in Java routines are not supported for connections to for Linux, UNIX,
and Windows or DB2 for i. Use of DECFLOAT requires the SDK for Java Version 5 (1.5) or later.
4. This mapping is valid only if the database server can determine the data type of the column.
5. BINARY and VARBINARY are valid for connections to DB2 Version 9.1 for z/OS or later database servers or DB2
for i5/OS V5R3 and later database servers.
6. BIGINT is valid for connections to DB2 Version 9.1 for z/OS or later database servers, DB2 V9.1 for Linux, UNIX,
and Windows or later database servers, and all supported DB2 for i database servers.
7. p indicates the timestamp precision, which is the number of digits in the fractional part of the timestamp.
0<=p<=12. The default is 6. TIMESTAMP(p) is supported for connections to DB2 Database for Linux, UNIX, and
Windows V9.7 and later and DB2 for z/OS V10 and later only.
8. The WITH TIME ZONE clause is supported for connections to DB2 for z/OS V10 and later only.
Data types in Java stored procedures and user-defined functions
The following table summarizes mappings of the SQL parameter data types in a
CREATE PROCEDURE or CREATE FUNCTION statement to the data types in the
corresponding Java stored procedure or user-defined function method.
For DB2 Database for Linux, UNIX, and Windows, if more than one Java data type
is listed for an SQL data type, only the first Java data type is valid.
For DB2 for z/OS, if more than one Java data type is listed, and you use a data
type other than the first data type as a method parameter, you need to include a
method signature in the EXTERNAL clause of your CREATE PROCEDURE or
CREATE FUNCTION statement that specifies the Java data types of the method
parameters.
Table 33. Mappings of SQL data types in a CREATE PROCEDURE or CREATE FUNCTION statement to data types in
the corresponding Java stored procedure or user-defined function program
SQL data type in CREATE PROCEDURE or CREATE
FUNCTION1
Data type in Java stored procedure or
user-defined function method2
SMALLINT
short, java.lang.Integer
INTEGER
int, java.lang.Integer
BIGINT
3
long, java.lang.Long
REAL
float, java.lang.Float
DOUBLE
double, java.lang.Double
DECIMAL
java.math.BigDecimal
216
Application Programming Guide and Reference for Java
Table 33. Mappings of SQL data types in a CREATE PROCEDURE or CREATE FUNCTION statement to data types in
the corresponding Java stored procedure or user-defined function program (continued)
SQL data type in CREATE PROCEDURE or CREATE
FUNCTION1
Data type in Java stored procedure or
user-defined function method2
DECFLOAT4
java.math.BigDecimal
CHAR
java.lang.String
VARCHAR
java.lang.String
CHAR FOR BIT DATA
byte[]
VARCHAR FOR BIT DATA
byte[]
BINARY
5
VARBINARY
byte[]
5
byte[]
DATE
java.sql.Date
TIME
java.sql.Time
TIMESTAMP, TIMESTAMP(p), TIMESTAMP WITH TIME ZONE, java.sql.Timestamp
TIMESTAMP(p) WITH TIME ZONE6,7
BLOB
java.sql.Blob
CLOB
java.sql.Clob
DBCLOB
java.sql.Clob
ROWID
java.sql.Types.ROWID
Notes:
1. A DB2 for z/OS stored procedure or user-defined function parameter cannot have the XML data type.
2. For a stored procedure or user-defined function on a DB2 Database for Linux, UNIX, and Windows server, only
the first data type is valid.
3. BIGINT is valid for connections to DB2 Version 9.1 for z/OS or later database servers or DB2 V9.1 for Linux,
UNIX, and Windows or later database servers.
4. DECFLOAT parameters in Java routines are valid only for connections to DB2 Version 9.1 for z/OS or later
database servers. DECFLOAT parameters in Java routines are not supported for connections to for Linux, UNIX,
and Windows or DB2 for i. Use of DECFLOAT requires the SDK for Java Version 5 (1.5) or later.
5. BINARY and VARBINARY are valid for connections to DB2 Version 9.1 for z/OS or later database servers.
6. p indicates the timestamp precision, which is the number of digits in the fractional part of the timestamp.
0<=p<=12. The default is 6. TIMESTAMP(p) is supported for connections to DB2 Database for Linux, UNIX, and
Windows V9.7 and later and DB2 for z/OS V10 and later only.
7. The WITH TIME ZONE clause is supported for connections to DB2 for z/OS V10 and later only.
Date, time, and timestamp values that can cause problems in
JDBC and SQLJ applications
You might receive unexpected results in JDBC and SQLJ applications if you use
date, time, and timestamp values that do not correspond to real dates and times.
The following items might cause problems:
v Use of the hour '24' to represent midnight
v Use of a date between October 5, 1582, and October 14, 1582, inclusive
Problems with using the hour '24' as midnight
The IBM Data Server Driver for JDBC and SQLJ uses Java data types for its
internal processing of input and output parameters and ResultSet content in JDBC
Chapter 7. JDBC and SQLJ reference information
217
and SQLJ applications. The Java data type that is used by the driver is based on
the best match for the corresponding SQL type when the target SQL type is known
to the driver.
For values that are assigned to or retrieved from DATE, TIME, or TIMESTAMP
SQL types, the IBM Data Server Driver for JDBC and SQLJ uses java.sql.Date for
DATE SQL types, java.sql.Time for TIME SQL types, and java.sql.Timestamp for
TIMESTAMP SQL types.
When you assign a string value to a DATE, TIME, or TIMESTAMP target, the IBM
Data Server Driver for JDBC and SQLJ uses Java facilities to convert the string
value to a java.sql.Date, java.sql.Time, or java.sql.Timestamp value. If a string
representation of a date, time, or timestamp value does not correspond to a real
date or time, Java adjusts the value to a real date or time value. In particular, Java
adjusts an hour value of '24' to '00' of the next day. This adjustment can result in
an exception for a timestamp value of '9999-12-31 24:00:00.0', because the adjusted
year value becomes '10000'.
Important: To avoid unexpected results when you assign or retrieve date, time, or
timestamp values in JDBC or SQLJ applications, ensure that the values are real
date, time, or timestamp values. In addition, do not use '24' as the hour component
of a time or timestamp value.
If a value that does not correspond to a real date or time, such as a value with an
hour component of '24', is stored in a TIME or TIMESTAMP column, you can
avoid adjustment during retrieval by executing the SQL CHAR function against
that column in the SELECT statement that defines a ResultSet. Executing the
CHAR function converts the date or time value to a character string value on the
database side. However, if you use the getTime or getTimestamp method to retrieve
that value from the ResultSet, the IBM Data Server Driver for JDBC and SQLJ
converts the value to a java.sql.Time or java.sql.Timestamp type, and Java adjusts
the value. To avoid date adjustment, execute the CHAR function against the
column value, and retrieve the value from the ResultSet with the getString
method.
The following examples show the results of updating DATE, TIME, or
TIMESTAMP columns in JDBC or SQLJ applications, when the application data
does not represent real dates or times.
Table 34. Examples of updating DATE, TIME, or TIMESTAMP SQL values with Java date, time, or timestamp values
that do not represent real dates or times
String input value
Target type in
database
Value sent to table column, or exception
2008-13-35
DATE
2009-02-04
25:00:00
TIME
01:00:00
24:00:00
TIME
00:00:00
2008-15-36
28:63:74.0
TIMESTAMP
2009-04-06 05:04:14.0
9999-12-31
24:00:00.0
TIMESTAMP
Exception, because the adjusted value (10000-01-01 00:00:00.0) exceeds the
maximum year of 9999.
The following examples demonstrate the results of retrieving data from
TIMESTAMP columns in JDBC or SQLJ applications, when the values in those
columns do not represent real dates or times.
218
Application Programming Guide and Reference for Java
Table 35. Results of retrieving DATE, TIME, or TIMESTAMP SQL values that do not represent real dates or times into
Java application variables
SELECT statement
Value in TIMESTAMP
column TS_COL
Target type in application
(getXXX method for
retrieval)
Value retrieved from table column
SELECT TS_COL
FROM TABLE1
2000-01-01 24:00:00.000000
java.sql.Timestamp
(getTimestamp)
2000-01-02 00:00:00.000000
SELECT TS_COL
FROM TABLE1
2000-01-01 24:00:00.000000
String (getString)
2000-01-02 00:00:00.000000
SELECT
CHAR(TS_COL)
FROM TABLE1
2000-01-01 24:00:00.000000
java.sql.Timestamp
(getTimestamp)
2000-01-02 00:00:00.000000
SELECT
CHAR(TS_COL)
FROM TABLE1
2000-01-01 24:00:00.000000
String (getString)
2000-01-01 24:00:00.000000 (no
adjustment by Java)
Problems with using dates in the range October 5, 1582, through
October 14, 1582
The Java java.util.Date and java.util.Timestamp classes use the Julian calendar
for dates before October 4, 1582, and the Gregorian calendar for dates starting with
October 4, 1582. In the Gregorian calendar, October 4, 1582, is followed by October
15, 1582. If a Java program encounters a java.util.Date or java.util.Timestamp
value that is between October 5, 1582, and October 14, 1582, inclusive, Java adds 10
days to that date. Therefore, a DATE or TIMESTAMP value in a DB2 table that has
a value between October 5, 1582, and October 14, 1582, inclusive, is retrieved in a
Java program as a java.util.Date or java.util.Timestamp value between October
15, 1582, and October 24, 1582, inclusive. A java.util.Date or
java.util.Timestamp value in a Java program that is between October 5, 1582, and
October 14, 1582, inclusive, is stored in a DB2 table as a DATE or TIMESTAMP
value between October 15, 1582, and October 24, 1582, inclusive.
Example: Retrieve October 10, 1582, from a DATE column.
// DATETABLE has one date column with one row.
// Its value is 1582-10-10.
java.sql.ResultSet rs =
statement.executeQuery(select * from DATETABLE);
rs.next();
System.out.println(rs.getDate(1)); // Value is retrieved as 1582-10-20
Example: Store October 10, 1582, in a DATE column.
java.sql.Date d = java.sql.Date.valueOf("1582-10-10");
java.sql.PreparedStatement ps =
c.prepareStatement("Insert into DATETABLE values(?)");
ps.setDate(1, d);
ps.executeUpdate(); // Value is inserted as 1582-10-20
To retrieve a value in the range October 5, 1582, to October 14, 1582, from a DB2
table without date adjustment, execute the SQL CHAR function against the DATE
or TIMESTAMP column in the SELECT statement that defines a ResultSet.
Executing the CHAR function converts the date or time value to a character string
value on the database side.
To store a value in the range October 5, 1582, to October 14, 1582 in a DB2 table
without date adjustment, you can use one of the following techniques:
Chapter 7. JDBC and SQLJ reference information
219
v For a JDBC or an SQLJ application, use the setString method to assign the
value to a String input parameter. Cast the input parameter as VARCHAR, and
execute the DATE or TIMESTAMP function against the result of the cast. Then
store the result of the DATE or TIMESTAMP function in the DATE or
TIMESTAMP column.
v For a JDBC application, set the Connection or DataSource property sendDataAsIs
to true, and use the setString method to assign the date or timestamp value to
the input parameter. Then execute an SQL statement to assign the String value
to the DATE or TIMESTAMP column.
Example: Retrieve October 10, 1582, from a DATE column without date
adjustment.
// DATETABLE has one date column called DATECOL with one row.
// Its value is 1582-10-10.
java.sql.ResultSet rs =
statement.executeQuery(SELECT CHAR(DATECOL) FROM DATETABLE);
rs.next();
System.out.println(rs.getString(1)); // Value is retrieved as 1582-10-10
Example: Store October 10, 1582, in a DATE column without date adjustment.
String s = "1582-10-10";
java.sql.Statement stmt = c.createStatement;
java.sql.PreparedStatement ps =
c.prepareStatement("Insert INTO DATETABLE VALUES " +
"(DATE(CAST (? AS VARCHAR)))");
ps.setString(1, s);
ps.executeUpdate(); // Value is inserted as 1582-10-10
Data loss for timestamp data in JDBC and SQLJ applications
For DB2 for z/OS Version 10 or later, or DB2 Database for Linux, UNIX, and
Windows Version 9.7 or later, you can specify the precision of the fractional part of
a TIMESTAMP column, with a maximum precision of 12 digits. The fractional part
of a Java timestamp value can have up to 9 digits of precision. Depending on the
column definition, data loss can occur when you update a TIMESTAMP(p) column
or retrieve data from a TIMESTAMP(p) column.
Data loss for input data
If you use a setTimestamp call to pass a timestamp value to a TIMESTAMP(p)
column, the maximum precision of the Java value that is sent to the data source is
9. If you use a setTimestamp call to pass a timestamp value to a TIMESTAMP
column at a data source that does not support TIMESTAMP(p), the maximum
precision of the Java value that is sent to the data source is 6. For input to a
TIMESTAMP(p) column, if the precision of the target column is less than the
precision of the input value, the data source truncates the excess digits in the
fractional part of the timestamp.
If you use a setString call to pass the input value, it is possible to send a value
with a precision of greater than 9 to the data source.
For IBM Data Server Driver for JDBC and SQLJ version 3.59 or later, no data loss
occurs if the TIMESTAMP(p) column is big enough to accommodate the input
value. For IBM Data Server Driver for JDBC and SQLJ version 3.58 or earlier, data
loss depends on the setting of the deferPrepares property and the sendDataAsIs
property:
220
Application Programming Guide and Reference for Java
v If sendDataAsIs is set to true, the IBM Data Server Driver for JDBC and SQLJ
sends the string to the data source as-is, so the fractional part of the timestamp
value can be more than 9 digits. If the value of p in the TIMESTAMP(p) column
is greater than or equal to the number of digits in the fractional part of the input
data, no data loss occurs.
v If sendDataAsIs is set to false, data loss depends on the deferPrepares setting.
v If deferPrepares is set to true, the first time that an UPDATE statement is
executed, the IBM Data Server Driver for JDBC and SQLJ sends the string to the
data source as-is, so the fractional part of the timestamp value can be more than
9 digits. If the value of p in the TIMESTAMP(p) column is greater than or equal
to the number of digits in the fractional part of the input data, no data loss
occurs.
For subsequent executions of the UPDATE statement, the IBM Data Server
Driver for JDBC and SQLJ can determine that the target data type is a
TIMESTAMP data type. If the data source supports TIMESTAMP(p) columns, the
driver converts the input value to a java.sql.Timestamp value with a maximum
precision of 9. If the data source does not support TIMESTAMP(p) columns, the
driver converts the input value to a java.sql.Timestamp value with a maximum
precision of 6. Data loss occurs if the original value has more precision than the
converted java.sql.Timestamp value, or if the java.sql.Timestamp value has more
precision than the TIMESTAMP(p) column.
v If deferPrepares is set to false, the IBM Data Server Driver for JDBC and SQLJ
can determine that the target data type is a TIMESTAMP data type. If the data
source supports TIMESTAMP(p) columns, the driver converts the input value to
a java.sql.Timestamp value with a maximum precision of 9. If the data source
does not support TIMESTAMP(p) columns, the driver converts the input value
to a java.sql.Timestamp value with a maximum precision of 6. Data loss occurs if
the original value has more precision than the converted java.sql.Timestamp
value, or if the java.sql.Timestamp value has more precision than the
TIMESTAMP(p) column.
You can lessen data loss for input timestamp values by using a setString call and
setting sendDataAsIs to true. However, if you set sendDataAsIs to true, you need
to ensure that application data types are compatible with data source data types.
Data loss for output data
When you use a getTimestamp or getString call to retrieve data from a
TIMESTAMP(p) column, the IBM Data Server Driver for JDBC and SQLJ converts
the value to a java.sql.Timestamp value with a maximum precision of 9. If the
source value has a precision of greater than 9, the driver truncates the fractional
part of the retrieved value to nine digits. If you do not want truncation to occur, in
the SELECT statement that retrieves the TIMESTAMP(p) value, you can cast the
TIMESTAMP(p) value to a character data type, such as VARCHAR, and use
getString to retrieve the value from the ResultSet.
Properties for the IBM Data Server Driver for JDBC and SQLJ
IBM Data Server Driver for JDBC and SQLJ properties define how the connection
to a particular data source should be made. Most properties can be set for a
DataSource object or for a Connection object.
Methods for setting the properties
Properties can be set in one of the following ways:
Chapter 7. JDBC and SQLJ reference information
221
v Using setXXX methods, where XXX is the unqualified property name, with the
first character capitalized.
Properties are applicable to the following IBM Data Server Driver for JDBC and
SQLJ-specific implementations that inherit from
com.ibm.db2.jcc.DB2BaseDataSource:
– com.ibm.db2.jcc.DB2SimpleDataSource
– com.ibm.db2.jcc.DB2ConnectionPoolDataSource
– com.ibm.db2.jcc.DB2XADataSource
v In a java.util.Properties value in the info parameter of a
DriverManager.getConnection call.
v In a java.lang.String value in the url parameter of a
DriverManager.getConnection call.
Some properties with an int data type have predefined constant field values. You
must resolve constant field values to their integer values before you can use
those values in the url parameter. For example, you cannot use
com.ibm.db2.jcc.DB2BaseDataSource.TRACE_ALL in a url parameter. However,
you can build a URL string that includes
com.ibm.db2.jcc.DB2BaseDataSource.TRACE_ALL, and assign the URL string to
a String variable. Then you can use the String variable in the url parameter:
String url =
"jdbc:db2://sysmvs1.stl.ibm.com:5021" +
"user=dbadm;password=dbadm;" +
"traceLevel=" +
(com.ibm.db2.jcc.DB2BaseDataSource.TRACE_ALL) + ";";
Connection con =
java.sql.DriverManager.getConnection(url);
Related concepts
“IBM Data Server Driver for JDBC and SQLJ support for SSL” on page 507
“LOBs in JDBC applications with the IBM Data Server Driver for JDBC and SQLJ”
on page 51
Chapter 9, “Security under the IBM Data Server Driver for JDBC and SQLJ,” on
page 495
Related tasks
“Connecting to a data source using the DataSource interface” on page 17
“Connecting to a data source using the DriverManager interface with the IBM Data
Server Driver for JDBC and SQLJ” on page 13
Keeping prepared statements after commit points (Application programming
and SQL)
Related reference
“IBM Data Server Driver for JDBC and SQLJ extensions to JDBC” on page 347
SIGNON function for RRSAF (Application programming and SQL)
Common IBM Data Server Driver for JDBC and SQLJ
properties for all supported database products
Most of the IBM Data Server Driver for JDBC and SQLJ properties apply to all
database products that the driver supports.
Unless otherwise noted, all properties are in com.ibm.db2.jcc.DB2BaseDataSource.
Those properties are:
222
Application Programming Guide and Reference for Java
affinityFailbackInterval
Specifies the length of the interval, in seconds, that the IBM Data Server Driver
for JDBC and SQLJ waits between attempts to fail back an existing connection
to the primary server. A value that is less than or equal to 0 means that the
connection does not fail back. The default is DB2BaseDataSource.NOT_SET (0).
Attempts to fail back connections to the primary server are made at transaction
boundaries, after the specified interval elapses.
affinityFailbackInterval is used only if the values of properties
enableSeamlessFailover and enableClientAffinitiesList are
DB2BaseDataSource.YES (1).
affinityFailbackInterval applies only to IBM Data Server Driver for JDBC and
SQLJ type 4 connectivity.
allowNextOnExhaustedResultSet
Specifies how the IBM Data Server Driver for JDBC and SQLJ handles a
ResultSet.next() call for a forward-only cursor that is positioned after the last
row of the ResultSet. The data type of this property is int.
Possible values are:
DB2BaseDataSource.YES (1)
For a ResultSet that is defined as TYPE_FORWARD_ONLY,
ResultSet.next() returns false if the cursor was previously positioned
after the last row of the ResultSet. false is returned, regardless of
whether the cursor is open or closed.
DB2BaseDataSource.NO (2)
For a ResultSet that is defined as TYPE_FORWARD_ONLY, when
ResultSet.next() is called, and the cursor was previously positioned
after the last row of the ResultSet, the driver throws a
java.sql.SQLException with error text "Invalid operation: result set is
closed." This is the default.
allowNullResultSetForExecuteQuery
Specifies whether the IBM Data Server Driver for JDBC and SQLJ returns null
when Statement.executeQuery, PreparedStatement.executeQuery, or
CallableStatement.executeQuery is used to execute a CALL statement for a
stored procedure that does not return any result sets.
Possible values are:
DB2BaseDataSource.NOT_SET (0)
The behavior is the same as for DB2BaseDataSource.NO.
DB2BaseDataSource.YES (1)
The IBM Data Server Driver for JDBC and SQLJ returns null when
Statement.executeQuery, PreparedStatement.executeQuery, or
CallableStatement.executeQuery is used to execute a CALL statement
for a stored procedure that does not return any result sets. This
behavior does not conform to the JDBC standard.
DB2BaseDataSource.NO (2)
The IBM Data Server Driver for JDBC and SQLJ throws an
SQLException when Statement.executeQuery,
PreparedStatement.executeQuery, or CallableStatement.executeQuery
is used to execute a CALL statement for a stored procedure that does
not return any result sets. This behavior conforms to the JDBC
standard.
Chapter 7. JDBC and SQLJ reference information
223
atomicMultiRowInsert
Specifies whether batch operations that use PreparedStatement methods to
modify a table are atomic or non-atomic. The data type of this property is int.
For connections to DB2 for z/OS, this property applies only to batch INSERT
operations.
For connections to DB2 Database for Linux, UNIX, and Windows or IBM
Informix, this property applies to batch INSERT, MERGE, UPDATE or DELETE
operations.
Possible values are:
DB2BaseDataSource.YES (1)
Batch operations are atomic. Insertion of all rows in the batch is
considered to be a single operation. If insertion of a single row fails,
the entire operation fails with a BatchUpdateException. Use of a batch
statement that returns auto-generated keys fails with a
BatchUpdateException.
If atomicMultiRowInsert is set to DB2BaseDataSource.YES (1):
v Execution of statements in a heterogeneous batch is not allowed.
v If the target data source is DB2 for z/OS the following operations
are not allowed:
– Insertion of more than 32767 rows in a batch results in a
BatchUpdateException.
– Calling more than one of the following methods against the same
parameter in different rows results in a BatchUpdateException:
- PreparedStatement.setAsciiStream
- PreparedStatement.setCharacterStream
- PreparedStatement.setUnicodeStream
DB2BaseDataSource.NO (2)
Batch inserts are non-atomic. Insertion of each row is considered to be
a separate execution. Information on the success of each insert
operation is provided by the int[] array that is returned by
Statement.executeBatch.
DB2BaseDataSource.NOT_SET (0)
Batch inserts are non-atomic. Insertion of each row is considered to be
a separate execution. Information on the success of each insert
operation is provided by the int[] array that is returned by
Statement.executeBatch. This is the default.
blockingReadConnectionTimeout
The amount of time in seconds before a connection socket read times out. This
property applies only to IBM Data Server Driver for JDBC and SQLJ type 4
connectivity, and affects all requests that are sent to the data source after a
connection is successfully established. The default is 0. A value of 0 means that
there is no timeout.
clientDebugInfo
Specifies a value for the CLIENT DEBUGINFO connection attribute, to notify
the data server that stored procedures and user-defined functions that are
using the connection are running in debug mode. CLIENT DEBUGINFO is
used by the DB2 Unified Debugger. The data type of this property is String.
The maximum length is 254 bytes.
This property applies only to IBM Data Server Driver for JDBC and SQLJ type
4 connectivity.
224
Application Programming Guide and Reference for Java
clientRerouteAlternateServerName
Specifies one or more server names for client reroute. The data type of this
property is String.
When enableClientAffinitiesList=DB2BaseDataSource.YES (1),
clientRerouteAlternateServerName must contain the name of the primary
server as well as alternate server names. The server that is identified by
serverName and portNumber is the primary server. That server name must
appear at the beginning of the clientRerouteAlternateServerName list.
If more than one server name is specified, delimit the server names with
commas (,) or spaces. The number of values that is specified for
clientRerouteAlternateServerName must match the number of values that is
specified for clientRerouteAlternatePortNumber.
clientRerouteAlternateServerName applies to IBM Data Server Driver for JDBC
and SQLJ type 2 connectivity to DB2 Database for Linux, UNIX, and Windows
and IBM Data Server Driver for JDBC and SQLJ type 4 connectivity.
clientRerouteAlternatePortNumber
Specifies one or more port numbers for client reroute. The data type of this
property is String.
When enableClientAffinitiesList=DB2BaseDataSource.YES (1),
clientRerouteAlternatePortNumber must contain the port number for the
primary server as well as port numbers for alternate servers. The server that is
identified by serverName and portNumber is the primary server. That port
number must appear at the beginning of the
clientRerouteAlternatePortNumber list.
If more than one port number is specified, delimit the port numbers with
commas (,) or spaces. The number of values that is specified for
clientRerouteAlternatePortNumber must match the number of values that is
specified for clientRerouteAlternateServerName.
clientRerouteAlternatePortNumber applies to IBM Data Server Driver for JDBC
and SQLJ type 2 connectivity to DB2 Database for Linux, UNIX, and Windows
and IBM Data Server Driver for JDBC and SQLJ type 4 connectivity.
clientRerouteServerListJNDIName
Identifies a JNDI reference to a DB2ClientRerouteServerList instance in a JNDI
repository of reroute server information. clientRerouteServerListJNDIName
applies only to IBM Data Server Driver for JDBC and SQLJ type 4 connectivity,
and to connections that are established through the DataSource interface.
If the value of clientRerouteServerListJNDIName is not null,
clientRerouteServerListJNDIName provides the following functions:
v Allows information about reroute servers to persist across JVMs
v Provides an alternate server location if the first connection to the data source
fails
clientRerouteServerListJNDIContext
Specifies the JNDI context that is used for binding and lookup of the
DB2ClientRerouteServerList instance. clientRerouteServerListJNDIContext
applies only to IBM Data Server Driver for JDBC and SQLJ type 4 connectivity,
and to connections that are established through the DataSource interface.
If clientRerouteServerListJNDIContext is not set, the IBM Data Server Driver
for JDBC and SQLJ creates an initial context using system properties or the
jndi.properties file.
Chapter 7. JDBC and SQLJ reference information
225
clientRerouteServerListJNDIContext can be set only by using the following
method:
public void setClientRerouteServerListJNDIContext(javax.naming.Context registry)
connectionCloseWithInFlightTransaction
Specifies whether the IBM Data Server Driver for JDBC and SQLJ throws an
SQLException or rolls back a transaction without throwing an SQLException
when a connection is closed in the middle of the transaction. Possible values
are:
DB2BaseDataSource.NOT_SET (0)
The behavior is the same as for
DB2BaseDataSource.CONNECTION_CLOSE_WITH_EXCEPTION.
DB2BaseDataSource.CONNECTION_CLOSE_WITH_EXCEPTION (1)
When a connection is closed in the middle of a transaction, an
SQLException with error -4471 is thrown.
DB2BaseDataSource.CONNECTION_CLOSE_WITH_ROLLBACK (2)
When a connection is closed in the middle of a transaction, the
transaction is rolled back, and no SQLException is thrown.
databaseName
Specifies the name for the data source. This name is used as the database
portion of the connection URL. The name depends on whether IBM Data
Server Driver for JDBC and SQLJ type 4 connectivity or IBM Data Server
Driver for JDBC and SQLJ type 2 connectivity is used.
For IBM Data Server Driver for JDBC and SQLJ type 4 connectivity:
v If the connection is to a DB2 for z/OS server, the databaseName value is the
DB2 location name that is defined during installation. All characters in this
value must be uppercase characters. You can determine the location name by
executing the following SQL statement on the server:
SELECT CURRENT SERVER FROM SYSIBM.SYSDUMMY1;
v If the connection is to a DB2 Database for Linux, UNIX, and Windows
server, the databaseName value is the database name that is defined during
installation.
v If the connection is to an IBM Informix server, database is the database name.
The name is case-insensitive. The server converts the name to lowercase.
v If the connection is to an IBM Cloudscape server, the databaseName value is
the fully-qualified name of the file that contains the database. This name
must be enclosed in double quotation marks ("). For example:
"c:/databases/testdb"
If this property is not set, connections are made to the local site.
For IBM Data Server Driver for JDBC and SQLJ type 2 connectivity:
v The databaseName value is the location name for the data source. The
location name is defined in the SYSIBM.LOCATIONS catalog table.
If the databaseName property is not set, the connection location depends on
the type of environment in which the connection is made. If the connection
is made in an environment such as a stored procedure, CICS, or IMS
environment, where a DB2 connection to a location is previously established,
that connection is used. The connection URL for this case is
jdbc:default:connection:. If a connection to DB2 is not previously established,
the connection is to the local site. The connection URL for this case is
jdbc:db2os390: or jdbc:db2os390sqlj:.
226
Application Programming Guide and Reference for Java
decimalSeparator
Specifies the decimal separator for input and output, for decimal, floating
point, or decimal floating-point data values. The data type of this property is
int.
If the value of the sendDataAsIs property is true, decimalSeparator affects only
output values.
Possible values are:
DB2BaseDataSource.DECIMAL_SEPARATOR_NOT_SET (0)
A period is used as the decimal separator. This is the default.
DB2BaseDataSource.DECIMAL_SEPARATOR_PERIOD (1)
A period is used as the decimal separator.
DB2BaseDataSource.DECIMAL_SEPARATOR_COMMA (2)
A comma is used as the decimal separator.
When DECIMAL_SEPARATOR_COMMA is set, the result of
ResultSet.getString on a decimal, floating point, or decimal
floating-point value has a comma as a separator. However, if the
toString method is executed on a value that is retrieved with a
ResultSet.getXXX method that returns a decimal, floating point, or
decimal floating-point value, the result has a decimal point as the
decimal separator.
decimalStringFormat
Specifies the string format for data that is retrieved from a DECIMAL or
DECFLOAT column when the SDK for Java is Version 1.5 or later. The data
type of this property is int. Possible values are:
DB2BaseDataSource.DECIMAL_STRING_FORMAT_NOT_SET (0)
The IBM Data Server Driver for JDBC and SQLJ returns decimal values
in the format that the java.math.BigDecimal.toString method returns
them. This is the default.
For example, the value 0.0000000004 is returned as 4E-10.
DB2BaseDataSource.DECIMAL_STRING_FORMAT_TO_STRING (1)
The IBM Data Server Driver for JDBC and SQLJ returns decimal values
in the format that the java.math.BigDecimal.toString method returns
them.
For example, the value 0.0000000004 is returned as 4E-10.
DB2BaseDataSource.DECIMAL_STRING_FORMAT_TO_PLAIN_STRING (2)
The IBM Data Server Driver for JDBC and SQLJ returns decimal values
in the format that the java.math.BigDecimal.toPlainString method
returns them.
For example, the value 0.0000000004 is returned as 0.0000000004.
This property has no effect for earlier versions of the SDK for Java. For those
versions, the IBM Data Server Driver for JDBC and SQLJ returns decimal
values in the format that the java.math.BigDecimal.toString method returns
them.
defaultIsolationLevel
Specifies the default transaction isolation level for new connections. The data
type of this property is int. When defaultIsolationLevel is set on a DataSource,
all connections that are created from that DataSource have the default isolation
level that is specified by defaultIsolationLevel.
Chapter 7. JDBC and SQLJ reference information
227
For DB2 data sources, the default is
java.sql.Connection.TRANSACTION_READ_COMMITTED.
For IBM Informix databases, the default depends on the type of data source.
The following table shows the defaults.
Table 36. Default isolation levels for IBM Informix databases
Type of data source
Default isolation level
ANSI-compliant database with logging
java.sql.Connection.TRANSACTION_SERIALIZABLE
Database without logging
java.sql.Connection.TRANSACTION_READ_UNCOMMITTED
Non-ANSI-compliant database with
logging
java.sql.Connection.TRANSACTION_READ_COMMITTED
deferPrepares
Specifies whether invocation of the Connection.prepareStatement method
results in immediate preparation of an SQL statement on the data source, or
whether statement preparation is deferred until the PreparedStatement.execute
method is executed. The data type of this property is boolean.
deferPrepares is supported for IBM Data Server Driver for JDBC and SQLJ
type 2 connectivity to DB2 Database for Linux, UNIX, and Windows, and for
IBM Data Server Driver for JDBC and SQLJ type 4 connectivity.
Possible values are:
true
Statement preparation on the data source does not occur until the
PreparedStatement.execute method is executed. This is the default.
false
Statement preparation on the data source occurs when the
Connection.prepareStatement method is executed.
Deferring prepare operations can reduce network delays. However, if you defer
prepare operations, you need to ensure that input data types match table
column types.
description
A description of the data source. The data type of this property is String.
downgradeHoldCursorsUnderXa
Specifies whether cursors that are defined WITH HOLD can be opened under
XA connections.
downgradeHoldCursorsUnderXa applies to:
v IBM Data Server Driver for JDBC and SQLJ type 4 connectivity to DB2 for
z/OS servers.
v IBM Data Server Driver for JDBC and SQLJ type 4 connectivity or IBM Data
Server Driver for JDBC and SQLJ type 2 connectivity to DB2 Database for
Linux, UNIX, and Windows servers.
The default is false, which means that a cursor that is defined WITH HOLD
cannot be opened under an XA connection. An exception is thrown when an
attempt is made to open that cursor.
If downgradeHoldCursorsUnderXa is set to true, a cursor that is defined
WITH HOLD can be opened under an XA connection. However, the cursor has
the following restrictions:
v When the cursor is opened under an XA connection, the cursor does not
have WITH HOLD behavior. The cursor is closed at XA End.
228
Application Programming Guide and Reference for Java
v A cursor that is open before XA Start on a local transaction is closed at XA
Start.
driverType
For the DataSource interface, determines which driver to use for connections.
The data type of this property is int. Valid values are 2 or 4. 2 is the default.
enableClientAffinitiesList
Specifies whether the IBM Data Server Driver for JDBC and SQLJ enables
client affinities for cascaded failover support. The data type of this property is
int. Possible values are:
DB2BaseDataSource.YES (1)
The IBM Data Server Driver for JDBC and SQLJ enables client affinities
for cascaded failover support. This means that only servers that are
specified in the clientRerouteAlternateServerName and
clientRerouteAlternatePortNumber properties are retried. The driver
does not attempt to reconnect to any other servers.
For example, suppose that clientRerouteAlternateServerName contains
the following string:
host1,host2,host3
Also suppose that clientRerouteAlternatePortNumber contains the
following string:
port1,port2,port3
When client affinities are enabled, the retry order is:
1. host1:port1
2. host2:port2
3. host3:port3
DB2BaseDataSource.NO (2)
The IBM Data Server Driver for JDBC and SQLJ does not enable client
affinities for cascaded failover support.
DB2BaseDataSource.NOT_SET (0)
The IBM Data Server Driver for JDBC and SQLJ does not enable client
affinities for cascaded failover support. This is the default.
The effect of the maxRetriesForClientReroute and retryIntervalForClientReroute
properties differs depending on whether enableClientAffinitiesList is enabled.
This property applies only to IBM Data Server Driver for JDBC and SQLJ type
4 connectivity.
enableNamedParameterMarkers
Specifies whether support for named parameter markers is enabled in the IBM
Data Server Driver for JDBC and SQLJ. The data type of this property is int.
Possible values are:
DB2BaseDataSource.YES (1)
Named parameter marker support is enabled in the IBM Data Server
Driver for JDBC and SQLJ.
DB2BaseDataSource.NO (2)
Named parameter marker support is not enabled in the IBM Data
Server Driver for JDBC and SQLJ.
Chapter 7. JDBC and SQLJ reference information
229
The driver sends an SQL statement with named parameter markers to
the target data source without modification. The success or failure of
the statement depends on a number of factors, including the following
ones:
v Whether the target data source supports named parameter markers
v Whether the deferPrepares property value is true of false
v Whether the sendDataAsIs property value is true of false
Recommendation: To avoid unexpected behavior in an application
that uses named parameter markers, set
enableNamedParameterMarkers to YES.
DB2BaseDataSource.NOT_SET (0)
The behavior is the same as the behavior for DB2BaseDataSource.NO (2).
This is the default.
enableSeamlessFailover
Specifies whether the IBM Data Server Driver for JDBC and SQLJ uses
seamless failover for client reroute. The data type of this property is int.
For connections to DB2 for z/OS, if enableSysplexWLB is set to true,
enableSeamlessFailover has no effect. The IBM Data Server Driver for JDBC
and SQLJ uses seamless failover regardless of the enableSeamlessFailover
setting.
Possible values of enableSeamlessFailover are:
DB2BaseDataSource.YES (1)
The IBM Data Server Driver for JDBC and SQLJ uses seamless failover.
This means that the driver does not throw an SQLException with error
code -4498 after a failed connection has been successfully re-established
if the following conditions are true:
v The connection was not being used for a transaction at the time the
failure occurred.
v There are no outstanding global resources, such as global temporary
tables or open, held cursors, or connection states that prevent a
seamless failover to another server.
When seamless failover occurs, after the connection to a new data
source has been established, the driver re-issues the SQL statement that
was being processed when the original connection failed.
Recommendation: Set the queryCloseImplicit property to
DB2BaseDataSource.QUERY_CLOSE_IMPLICIT_NO (2) when you set
enableSeamlessFailover to DB2BaseDataSource.YES, if the application
uses held cursors.
DB2BaseDataSource.NO (2)
The IBM Data Server Driver for JDBC and SQLJ does not use seamless
failover.
When this setting is in effect, if a server goes down, the driver tries to
fail back or fail over to an alternate server. If failover or failback is
successful, the driver throws an SQLException with error code -4498,
which indicates that a connection failed but was successfully
reestablished. An SQLException with error code -4498 informs the
application that it should retry the transaction during which the
connection failure occurred. If the driver cannot reestablish a
connection, it throws an SQLException with error code -4499.
230
Application Programming Guide and Reference for Java
DB2BaseDataSource.NOT_SET (0)
The IBM Data Server Driver for JDBC and SQLJ does not use seamless
failover. This is the default.
enableSysplexWLB
Indicates whether the Sysplex workload balancing function of the IBM Data
Server Driver for JDBC and SQLJ is enabled. The data type of
enableSysplexWLB is boolean. The default is false.
enablSysplexWLB applies only to IBM Data Server Driver for JDBC and SQLJ
type 4 connectivity.
fetchSize
Specifies the default fetch size for ResultSet objects that are generated from
Statement objects. The data type of this property is int.
The fetchSize default can be overridden by the Statement.setFetchSize
method. The fetchSize property does not affect Statement objects that already
exist when fetchSize is set.
Possible values of fetchSize are:
0 or positive-integer
The default fetchSize value for newly created Statement objects. If the
fetchSize property value is invalid, the IBM Data Server Driver for
JDBC and SQLJ sets the default fetchSize value to 0.
DB2BaseDataSource.FETCHSIZE_NOT_SET (-1)
Indicates that the default fetchSize value for Statement objects is 0. This
is the property default.
The fetchSize property differs from the queryDataSize property. fetchSize
affects the number of rows that are returned, and queryDataSize affects the
number of bytes that are returned.
floatingPointStringFormat
Specifies the format for data that is retrieved from a DOUBLE, FLOAT, or
REAL column with the ResultSet.getString method. The data type of this
property is int. Possible values are:
DB2BaseDataSource.NOT_SET (0)
The IBM Data Server Driver for JDBC and SQLJ returns
double-precision floating point values in the string format that the
java.lang.String.valueOf(double) method returns them. The IBM
Data Server Driver for JDBC and SQLJ returns single-precision floating
point values in the string format that the
java.lang.String.valueOf(float) method returns them. This is the
default.
For example, suppose that the value 71256.789 is retrieved from a
DOUBLE column. If floatingPointStringFormat is not set, the string
format of the retrieved value is 71256.789. If the value 71256.789 is
retrieved from a REAL column, the string format of the retrieved value
is 71256.79.
DB2BaseDataSource.JCC_DRIVER_FLOATING_POINT_STRING_FORMAT (1)
The IBM Data Server Driver for JDBC and SQLJ returns
double-precision floating point values in the string format that the
java.lang.String.valueOf(double) method returns them. The IBM
Data Server Driver for JDBC and SQLJ returns single-precision floating
Chapter 7. JDBC and SQLJ reference information
231
point values in the string format that the
java.lang.String.valueOf(float) method returns them. This is the
default.
For example, suppose that the value 71256.789 is retrieved from a
DOUBLE column. If floatingPointStringFormat is
DB2BaseDataSource.JCC_DRIVER_FLOATING_POINT_STRING_FORMAT, the
string format of the retrieved value is 71256.789. If the value 71256.789
is retrieved from a REAL column, the string format of the retrieved
value is 71256.79.
DB2BaseDataSource.LUW_TYPE2_DRIVER_FLOATING_POINT_STRING_FORMAT (2)
The IBM Data Server Driver for JDBC and SQLJ returns DOUBLE,
FLOAT, or REAL values in the same format that the DB2 JDBC Type 2
Driver for Linux, UNIX, and Windows returns them.
For example, suppose that the value 71256.789 is retrieved from a
DOUBLE column. If floatingPointStringFormat is
DB2BaseDataSource.LUW_TYPE2_DRIVER_FLOATING_POINT_STRING_FORMAT,
the string format of the retrieved value is 7.12567890000000E+004. If
the value 71256.789 is retrieved from a REAL column, the string format
of the retrieved value is 7.125679E+04.
fullyMaterializeLobData
Indicates whether the driver retrieves LOB locators for FETCH operations. The
data type of this property is boolean.
The effect of fullyMaterializeLobData depends on whether the data source
supports progressive streaming, which is also known as dynamic data format:
v If the data source does not support progressive streaming:
If the value of fullyMaterializeLobData is true, LOB data is fully
materialized within the JDBC driver when a row is fetched. If the value is
false, LOB data is streamed. The driver uses locators internally to retrieve
LOB data in chunks on an as-needed basis It is highly recommended that
you set this value to false when you retrieve LOBs that contain large
amounts of data. The default is true.
v If the data source supports progressive streaming:
The JDBC driver ignores the value of fullyMaterializeLobData if the
progressiveStreaming property is set to DB2BaseDataSource.YES or
DB2BaseDataSource.NOT_SET.
This property has no effect on stored procedure parameters or on LOBs that
are fetched using scrollable cursors. LOB stored procedure parameters are
always fully materialized. LOBs that are fetched using scrollable cursors use
LOB locators if progressive streaming is not in effect.
interruptProcessingMode
Specifies the behavior of the IBM Data Server Driver for JDBC and SQLJ when
an application executes the Statement.cancel method. Possible values are:
DB2BaseDataSource.INTERRUPT_PROCESSING_MODE_DISABLED (0)
Interrupt processing is disabled. When an application executes
Statement.cancel, the IBM Data Server Driver for JDBC and SQLJ
does nothing.
DB2BaseDataSource.INTERRUPT_PROCESSING_MODE_STATEMENT_CANCEL (1)
When an application executes Statement.cancel, the IBM Data Server
Driver for JDBC and SQLJ cancels the currently executing statement, if
the data server supports interrupt processing. If the data server does
232
Application Programming Guide and Reference for Java
not support interrupt processing, the IBM Data Server Driver for JDBC
and SQLJ throws an SQLException that indicates that the feature is not
supported.
INTERRUPT_PROCESSING_MODE_STATEMENT_CANCEL is the
default.
For DB2 Database for Linux, UNIX, and Windows clients, when
interruptProcessingMode is set to
INTERRUPT_PROCESSING_MODE_STATEMENT_CANCEL, the DB2
Connect setting for INTERRUPT_ENABLED and the DB2 registry
variable setting for DB2CONNECT_DISCONNECT_ON_INTERRUPT
override this value.
DB2BaseDataSource.INTERRUPT_PROCESSING_MODE_CLOSE_SOCKET (2)
When an application executes Statement.cancel, the IBM Data Server
Driver for JDBC and SQLJ performs one of the following actions:
v If automatic client reroute or client affinities is not enabled, the IBM
Data Server Driver for JDBC and SQLJ drops the underlying socket,
closes the connection, and throws an SQLException that indicates
that the application is being disconnected from the data server. Any
subsequent operations that are invoked on any Statement objects
that are created from the same connection receive an SQLException
that indicates that the connection is closed.
v If automatic client reroute or client affinities is enabled, the IBM
Data Server Driver for JDBC and SQLJ drops the underlying socket,
closes the connection, and then attempts to re-establish the
connection. If re-connection is successful, the driver throws an
SQLException that indicates that the connection was re-established.
the driver does not re-execute any SQL statements, even if the
enableSeamlessFailover property is set to DB2BaseDataSource.YES.
loginTimeout
The maximum time in seconds to wait for a connection to a data source. After
the number of seconds that are specified by loginTimeout have elapsed, the
driver closes the connection to the data source. The data type of this property
is int. The default is 0. A value of 0 means that the timeout value is the default
system timeout value. This property is not supported for IBM Data Server
Driver for JDBC and SQLJ type 2 connectivity on DB2 for z/OS.
logWriter
The character output stream to which all logging and trace messages for the
DataSource object are printed. The data type of this property is
java.io.PrinterWriter. The default value is null, which means that no logging
or tracing for the DataSource is output.
maxRetriesForClientReroute
During automatic client reroute, limit the number of retries if the primary
connection to the data source fails.
The data type of this property is int.
The IBM Data Server Driver for JDBC and SQLJ uses the
maxRetriesForClientReroute property only if the retryIntervalForClientReroute
property is also set.
If the enableClientAffinitiesList is set to DB2BaseDataSource.NO (2), an attempt
to connect to the primary server and alternate servers counts as one retry. If
enableClientAffinitiesList is set to DB2BaseDataSource.YES (1), each server that
is specified by the clientRerouteAlternateServerName and
Chapter 7. JDBC and SQLJ reference information
233
clientRerouteAlternatePortNumber values is retried the number of times that is
specified by maxRetriesForClientReroute.
The default value for maxRetriesForClientReroute is 0 if
enableClientAffinitiesList is DB2BaseDataSource.NO (2), or 3 if
enableClientAffinitiesList is DB2BaseDataSource.YES (1).
If the value of maxRetriesForClientReroute is 0, client reroute processing does
not occur.
password
The password to use for establishing connections. The data type of this
property is String. When you use the DataSource interface to establish a
connection, you can override this property value by invoking this form of the
DataSource.getConnection method:
getConnection(user, password);
portNumber
The port number where the DRDA server is listening for requests. The data
type of this property is int.
This property is applicable only to IBM Data Server Driver for JDBC and SQLJ
type 4 connectivity.
progressiveStreaming
Specifies whether the JDBC driver uses progressive streaming when
progressive streaming is supported on the data source.
DB2 for z/OS Version 9.1 and later supports progressive streaming for LOBs
and XML objects. DB2 Database for Linux, UNIX, and Windows Version 9.5
and later, and IBM Informix Version 11.50 and later support progressive
streaming for LOBs.
With progressive streaming, also known as dynamic data format, the data
source dynamically determines the most efficient mode in which to return LOB
or XML data, based on the size of the LOBs or XML objects. The value of the
streamBufferSize parameter determines whether the data is materialized when
it is returned.
The data type of progressiveStreaming is int. Valid values are
DB2BaseDataSource.YES (1) and DB2BaseDataSource.NO (2). If the
progressiveStreaming property is not specified, the progressiveStreaming value
is DB2BaseDataSource.NOT_SET (0).
If the connection is to a data source that supports progressive streaming, and
the value of progressiveStreaming is DB2BaseDataSource.YES or
DB2BaseDataSource.NOT_SET, the JDBC driver uses progressive streaming to
return LOBs and XML data.
If the value of progressiveStreaming is DB2BaseDataSource.NO, or the data
source does not support progressive streaming, the way in which the JDBC
driver returns LOB or XML data depends on the value of the
fullyMaterializeLobData property.
queryCloseImplicit
Specifies whether cursors are closed immediately after all rows are fetched.
queryCloseImplicit applies only to connections to IBM Data Server Driver for
JDBC and SQLJ type 4 connectivity to DB2 for z/OS Version 8 or later, and
IBM Data Server Driver for JDBC and SQLJ type 4 connectivity or IBM Data
Server Driver for JDBC and SQLJ type 2 connectivityDB2 Database for Linux,
UNIX, and Windows Version 9.7 or later. Possible values are:
234
Application Programming Guide and Reference for Java
DB2BaseDataSource.QUERY_CLOSE_IMPLICIT_YES (1)
Close cursors immediately after all rows are fetched.
A value of DB2BaseDataSource.QUERY_CLOSE_IMPLICIT_YES can provide
better performance because this setting results in less network traffic.
DB2BaseDataSource.QUERY_CLOSE_IMPLICIT_NO (2)
Do not close cursors immediately after all rows are fetched.
DB2BaseDataSource.QUERY_CLOSE_IMPLICIT_COMMIT (3)
Perform these actions:
v Implicitly close the cursor after all rows are fetched.
v If the application is in autocommit mode, implicitly send a commit
request to the data source for the current unit of work.
Important: When this value is set, there might be impacts on other
resources, just as an explicit commit operation might impact other
resources. For example, other non-held cursors are closed, LOB locators
go out of scope, progressive references are reset, and scrollable cursors
lose their position.
Restriction: The following restrictions apply to
QUERY_CLOSE_IMPLICIT_COMMIT behavior:
v This behavior applies only to SELECT statements that are issued by
the application. It does not apply to SELECT statements that are
generated by the IBM Data Server Driver for JDBC and SQLJ.
v If QUERY_CLOSE_IMPLICIT_COMMIT is set, and the application is
not in autocommit mode, the driver uses the default behavior
(QUERY_CLOSE_IMPLICIT_NOT_SET behavior). If
QUERY_CLOSE_IMPLICIT_COMMIT is the default behavior, the
driver uses QUERY_CLOSE_IMPLICIT_YES behavior.
v If QUERY_CLOSE_IMPLICIT_COMMIT is set, and the data source
does not support QUERY_CLOSE_IMPLICIT_COMMIT behavior, the
driver uses QUERY_CLOSE_IMPLICIT_YES behavior.
v This behavior is not supported for batched statements.
v This behavior is supported on an XA Connection only when the
connection is in a local transaction.
DB2BaseDataSource.QUERY_CLOSE_IMPLICIT_NOT_SET (0)
This is the default. The following table describes the behavior for a
connection to each type of data source.
Data source
Version
Data sharing environment
Behavior
DB2 for z/OS
Version 10
Data sharing or non-data sharing
QUERY_CLOSE_IMPLICIT_COMMIT
DB2 for z/OS
Version 9 with
APAR PK68746
Non-data sharing, or in a data
sharing group but not in
coexistence mode with Version 8
members
QUERY_CLOSE_IMPLICIT_COMMIT
DB2 for z/OS
Version 9
without APAR
PK68746
Non-data sharing, or in a data
sharing group but not in
coexistence mode with Version 8
members
QUERY_CLOSE_IMPLICIT_YES
DB2 for z/OS
Version 9 with
APAR PK68746
In a data sharing group in
coexistence mode with Version 8
members
QUERY_CLOSE_IMPLICIT_COMMIT
Chapter 7. JDBC and SQLJ reference information
235
Data source
Version
Data sharing environment
Behavior
DB2 for z/OS
Version 9
without APAR
PK68746
In a data sharing group in
coexistence mode with Version 8
members
QUERY_CLOSE_IMPLICIT_YES
DB2 for z/OS
Version 8 with
or without
APAR PK68746
QUERY_CLOSE_IMPLICIT_YES
DB2 Database for
Linux, UNIX, and
Windows
Version 9.7
QUERY_CLOSE_IMPLICIT_YES
queryDataSize
Specifies a hint that is used to control the amount of query data, in bytes, that
is returned from the data source on each fetch operation. This value can be
used to optimize the application by controlling the number of trips to the data
source that are required to retrieve data.
Use of a larger value for queryDataSize can result in less network traffic,
which can result in better performance. For example, if the result set size is 50
KB, and the value of queryDataSize is 32767 (32KB), two trips to the database
server are required to retrieve the result set. However, if queryDataSize is set
to 65535 (64 KB), only one trip to the data source is required to retrieve the
result set.
The following table lists minimum, maximum, and default values of
queryDataSize for each data source.
Table 37. Default, minimum, and maximum values of queryDataSize
Product
Version
Default
Minimum
Maximum
Valid values
DB2 Database for
Linux, UNIX, and
Windows
All
32767
4096
262143
4096-32767, 98303, 131071, 163839, 196607,
229375, 2621431
IBM Informix
All
32767
4096
10485760
4096-10485760
DB2 for i
V5R4
32767
4096
65535
4096-65535
V6R1
32767
4096
262143
4096-65535, 98303, 131071, 163839, 196607,
229375, 2621431
Version 8
32767
32767
32767
32767
Version 9
32767
32767
65535
32767, 65535
Version 10
32767
32767
262143
32767, 65535, 98303, 131071, 163839, 196607,
229375, 2621431
Data source
DB2 for z/OS
Note:
1. If you specify a value between the minimum and maximum value that is not a valid value, the IBM Data Server
Driver for JDBC and SQLJ sets queryDataSize to the nearest valid value.
resultSetHoldability
Specifies whether cursors remain open after a commit operation. The data type
of this property is int. Valid values are:
DB2BaseDataSource.HOLD_CURSORS_OVER_COMMIT (1)
Leave cursors open after a commit operation.
This setting is not valid for a connection that is part of a distributed
(XA) transaction.
236
Application Programming Guide and Reference for Java
DB2BaseDataSource.CLOSE_CURSORS_AT_COMMIT (2)
Close cursors after a commit operation.
DB2BaseDataSource.NOT_SET (0)
This is the default value. The behavior is:
v For connections that are part of distributed (XA) transactions,
cursors are closed after a commit operation.
v For connections that are not part of a distributed transaction:
– For connections to all versions of DB2 for z/OS, DB2 Database for
Linux, UNIX, and Windows, or DB2 for i servers, or to
Cloudscape Version 8.1 or later servers, cursors remain open after
a commit operation.
– For connections to all versions of IBM Informix, or to Cloudscape
versions earlier than Version 8.1, cursors are closed after a commit
operation.
retrieveMessagesFromServerOnGetMessage
Specifies whether JDBC SQLException.getMessage or SQLWarning.getMessage
calls cause the IBM Data Server Driver for JDBC and SQLJ to invoke a DB2 for
z/OS stored procedure that retrieves the message text for the error. The data
type of this property is boolean. The default is false, which means that the full
message text is not returned to the client.
For example, if retrieveMessagesFromServerOnGetMessage is set to true, a
message similar to this one is returned by SQLException.getMessage after an
attempt to perform an SQL operation on nonexistent table
ADMF001.NO_TABLE:
ADMF001.NO_TABLE IS AN UNDEFINED NAME. SQLCODE=-204,
SQLSTATE=42704, DRIVER=3.50.54
If retrieveMessagesFromServerOnGetMessage is set to false, a message similar
to this one is returned:
DB2 SQL Error: SQLCODE=-204, SQLSTATE=42704, DRIVER=3.50.54
An alternative to setting this property to true is to use the IBM Data Server
Driver for JDBC and SQLJ-only DB2Sqlca.getMessage method in applications.
Both techniques result in a stored procedure call, which starts a unit of work.
retryIntervalForClientReroute
For automatic client reroute, specifies the amount of time in seconds between
connection retries.
The data type of this property is int.
The IBM Data Server Driver for JDBC and SQLJ uses the
retryIntervalForClientReroute property only if the maxRetriesForClientReroute
property is also set.
If maxRetriesForClientReroute or retryIntervalForClientReroute is not set, the
IBM Data Server Driver for JDBC and SQLJ performs retries for 10 minutes.
If the enableClientAffinitiesList is set to DB2BaseDataSource.NO (2), an attempt
to connect to the primary server and alternate servers counts as one retry. The
driver waits the number of seconds that is specified by
retryIntervalForClientReroute before retrying the connection. If
enableClientAffinitiesList is set to DB2BaseDataSource.YES (1), each server that
is specified by the clientRerouteAlternateServerName and
clientRerouteAlternatePortNumber values is retried after the number of
seconds that is specified by retryIntervalForClientReroute.
Chapter 7. JDBC and SQLJ reference information
237
The default value for retryIntervalForClientReroute is
DB2BaseDataSource.NOT_SET (-1). The default behavior is that there is no wait
between retries.
securityMechanism
Specifies the DRDA security mechanism. The data type of this property is int.
Possible values are:
CLEAR_TEXT_PASSWORD_SECURITY (3)
User ID and password
USER_ONLY_SECURITY (4)
User ID only
ENCRYPTED_PASSWORD_SECURITY (7)
User ID, encrypted password
ENCRYPTED_USER_AND_PASSWORD_SECURITY (9)
Encrypted user ID and password
KERBEROS_SECURITY (11)
Kerberos. This value does not apply to connections to IBM Informix.
ENCRYPTED_USER_AND_DATA_SECURITY (12)
Encrypted user ID and encrypted security-sensitive data. This value
applies to connections to DB2 for z/OS only.
ENCRYPTED_USER_PASSWORD_AND_DATA_SECURITY (13)
Encrypted user ID and password, and encrypted security-sensitive
data. This value does not apply to connections to IBM Informix.
PLUGIN_SECURITY (15)
Plug-in security. This value applies to connections to DB2 Database for
Linux, UNIX, and Windows only.
ENCRYPTED_USER_ONLY_SECURITY (16)
Encrypted user ID. This value does not apply to connections to IBM
Informix.
If this property is specified, the specified security mechanism is the only
mechanism that is used. If the security mechanism is not supported by the
connection, an exception is thrown.
The default value for securityMechanism is
CLEAR_TEXT_PASSWORD_SECURITY. If the server does not support
CLEAR_TEXT_PASSWORD_SECURITY but supports
ENCRYPTED_USER_AND_PASSWORD_SECURITY, the IBM Data Server
Driver for JDBC and SQLJ driver updates the security mechanism to
ENCRYPTED_USER_AND_PASSWORD_SECURITY and attempts to connect to
the server. Any other mismatch in security mechanism support between the
requester and the server results in an error.
This property is applicable only to IBM Data Server Driver for JDBC and SQLJ
type 4 connectivity.
sendDataAsIs
Specifies that the IBM Data Server Driver for JDBC and SQLJ does not convert
input parameter values to the target column data types. The data type of this
property is boolean. The default is false.
You should use this property only for applications that always ensure that the
data types in the application match the data types in the corresponding
database tables.
238
Application Programming Guide and Reference for Java
serverName
The host name or the TCP/IP address of the data source. The data type of this
property is String.
This property is applicable only to IBM Data Server Driver for JDBC and SQLJ
type 4 connectivity.
sslConnection
Specifies whether the IBM Data Server Driver for JDBC and SQLJ uses an SSL
socket to connect to the data source. If sslConnection is set to true, the
connection uses an SSL socket. If sslConnection is set to false, the connection
uses a plain socket.
This property is applicable only to IBM Data Server Driver for JDBC and SQLJ
type 4 connectivity.
sslTrustStoreLocation
Specifies the name of the Java truststore on the client that contains the server
certificate for an SSL connection.
The IBM Data Server Driver for JDBC and SQLJ uses this option only if the
sslConnection property is set to true.
If sslTrustStore is set, and sslConnection is set to true, the IBM Data Server
Driver for JDBC and SQLJ uses the sslTrustStoreLocation value instead of the
value in the javax.net.ssl.trustStore Java property.
This property is applicable only to IBM Data Server Driver for JDBC and SQLJ
type 4 connectivity.
sslTrustStorePassword
Specifies the password for the Java truststore on the client that contains the
server certificate for an SSL connection.
The IBM Data Server Driver for JDBC and SQLJ uses this option only if the
sslConnection property is set to true.
If sslTrustStorePassword is set, and sslConnection is set to true, the IBM Data
Server Driver for JDBC and SQLJ uses the sslTrustStorePassword value instead
of the value in the javax.net.ssl.trustStorePassword Java property.
This property is applicable only to IBM Data Server Driver for JDBC and SQLJ
type 4 connectivity.
stripTrailingZerosForDecimalNumbers
Specifies whether the IBM Data Server Driver for JDBC and SQLJ removes
trailing zeroes when it retrieves data from a DECFLOAT, DECIMAL, or
NUMERIC column. This property is meaningful only if the SDK for Java is
Version 1.5 or later. The data type of this property is int. Possible values are:
DB2BaseDataSource.NOT_SET (0)
The IBM Data Server Driver for JDBC and SQLJ does not remove
trailing zeroes from the retrieved value. This is the default.
DB2BaseDataSource.YES (1)
The IBM Data Server Driver for JDBC and SQLJ removes trailing
zeroes when it retrieves a value from a DECFLOAT, DECIMAL, or
NUMERIC column as a java.math.BigDecimal object.
For example, when the driver retrieves the value 234.04000, it returns
the value 234.04 to the application.
Chapter 7. JDBC and SQLJ reference information
239
DB2BaseDataSource.NO (2)
The IBM Data Server Driver for JDBC and SQLJ does not remove
trailing zeroes from the retrieved value.
timestampFormat
Specifies the format in which the result of the ResultSet.getString or
CallableStatement.getString method against a TIMESTAMP column is
returned. The data type of timestampFormat is int.
Possible values of timestampFormat are:
Constant
Integer
value
com.ibm.db2.jcc.DB2BaseDataSource.ISO
1
yyyy-mm-ddhh.mm.ss.nnnnnnnnn1
com.ibm.db2.jcc.DB2BaseDataSource.JDBC
5
yyyy-mm-dd
hh:mm:ss.nnnnnnnnn1
Format
Note:
1. The number of digits in the fractional part of the timestamp depends on the precision of
the TIMESTAMP(p) column in the source table. If p<9, p digits are returned. If p>=9, 9
digits are returned, and the remaining digits are truncated.
The default is com.ibm.db2.jcc.DB2BaseDataSource.JDBC.
timestampFormat affects the format of output only.
timestampPrecisionReporting
Specifies whether trailing zeroes are truncated in the result of a
Resultset.getString call for a TIMESTAMP value. The data type of this
property is int. Possible values are:
TIMESTAMP_JDBC_STANDARD (1)
Trailing zeroes are truncated in the result of a Resultset.getString call
for a TIMESTAMP value. This is the default.
For example:
v A TIMESTAMP value of 2009-07-19-10.12.00.000000 is truncated to
2009-07-19-10.12.00.0 after retrieval.
v A TIMESTAMP value of 2009-12-01-11.30.00.100000 is truncated to
2009-12-01-11.30.00.1 after retrieval.
TIMESTAMP_ZERO_PADDING (2)
Trailing zeroes are not truncated in the result of a Resultset.getString
call for a TIMESTAMP value.
traceDirectory
Specifies a directory into which trace information is written. The data type of
this property is String. When traceDirectory is specified, trace information for
multiple connections on the same DataSource is written to multiple files.
When traceDirectory is specified, a connection is traced to a file named
traceFile_origin_n.
n is the nth connection for a DataSource.
origin indicates the origin of the log writer that is in use. Possible values of
origin are:
cpds
The log writer for a DB2ConnectionPoolDataSource object.
driver The log writer for a DB2Driver object.
240
Application Programming Guide and Reference for Java
global The log writer for a DB2TraceManager object.
sds
The log writer for a DB2SimpleDataSource object.
xads
The log writer for a DB2XADataSource object.
If the traceFile property is also specified, the traceDirectory value is not used.
traceFile
Specifies the name of a file into which the IBM Data Server Driver for JDBC
and SQLJ writes trace information. The data type of this property is String.
The traceFile property is an alternative to the logWriter property for directing
the output trace stream to a file.
For IBM Data Server Driver for JDBC and SQLJ type 2 connectivity, the
db2.jcc.override.traceFile configuration property value overrides the traceFile
property value.
Recommendation: Set the db2.jcc.override.traceFile configuration property,
rather than setting the traceFile property for individual connections.
traceFileAppend
Specifies whether to append to or overwrite the file that is specified by the
traceFile property. The data type of this property is boolean. The default is
false, which means that the file that is specified by the traceFile property is
overwritten.
traceLevel
Specifies what to trace. The data type of this property is int.
You can specify one or more of the following traces with the traceLevel
property:
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_NONE (X'00')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_CONNECTION_CALLS (X'01')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_STATEMENT_CALLS (X'02')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_RESULT_SET_CALLS (X'04')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_DRIVER_CONFIGURATION (X'10')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_CONNECTS (X'20')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_DRDA_FLOWS (X'40')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_RESULT_SET_META_DATA (X'80')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_PARAMETER_META_DATA (X'100')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_DIAGNOSTICS (X'200')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_SQLJ (X'400')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_META_CALLS (X'2000')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_DATASOURCE_CALLS (X'4000')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_LARGE_OBJECT_CALLS (X'8000')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_T2ZOS (X'10000')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_SYSTEM_MONITOR (X'20000')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_TRACEPOINTS (X'40000')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_ALL (X'FFFFFFFF')
To specify more than one trace, use one of these techniques:
v Use bitwise OR (|) operators with two or more trace values. For example, to
trace DRDA flows and connection calls, specify this value for traceLevel:
TRACE_DRDA_FLOWS|TRACE_CONNECTION_CALLS
v Use a bitwise complement (~) operator with a trace value to specify all
except a certain trace. For example, to trace everything except DRDA flows,
specify this value for traceLevel:
~TRACE_DRDA_FLOWS
Chapter 7. JDBC and SQLJ reference information
241
user
The user ID to use for establishing connections. The data type of this property
is String. When you use the DataSource interface to establish a connection, you
can override this property value by invoking this form of the
DataSource.getConnection method:
getConnection(user, password);
xaNetworkOptimization
Specifies whether XA network optimization is enabled for IBM Data Server
Driver for JDBC and SQLJ type 4 connectivity. You might need to disable XA
network optimization in an environment in which an XA Start and XA End are
issued from one Java process, and an XA Prepare and an XA Commit are
issued from another Java process. With XA network optimization, the XA
Prepare can reach the data source before the XA End, which results in an
XAER_PROTO error. To prevent the XAER_PROTO error, disable XA network
optimization.
The default is true, which means that XA network optimization is enabled. If
xaNetworkOptimization is false, which means that XA network optimization
is disabled, the driver closes any open cursors at XA End time.
xaNetworkOptimization can be set on a DataSource object, or in the url
parameter in a getConnection call. The value of xaNetworkOptimization
cannot be changed after a connection is obtained.
com.ibm.db2.jcc.DB2ConnectionPoolDataSource.maxStatements
Controls an internal statement cache that is associated with a
PooledConnection. The data type of this property is int. Possible values are:
positive integer
Enables the internal statement cache for a PooledConnection, and
specifies the number of statements that the IBM Data Server Driver for
JDBC and SQLJ keeps open in the cache.
0 or negative integer
Disables internal statement caching for the PooledConnection. 0 is the
default.
maxStatements controls the internal statement cache that is associated with a
PooledConnection only when the PooledConnection object is created.
maxStatements has no effect on caching in an already existing
PooledConnection object.
maxStatements applies only to IBM Data Server Driver for JDBC and SQLJ
type 4 connectivity.
Related concepts
“Examples of ResultSetMetaData.getColumnName and
ResultSetMetaData.getColumnLabel values” on page 439
Common IBM Data Server Driver for JDBC and SQLJ
properties for DB2 servers
Some of the IBM Data Server Driver for JDBC and SQLJ properties apply to DB2
for z/OS and DB2 Database for Linux, UNIX, and Windows only.
Unless otherwise noted, all properties are in com.ibm.db2.jcc.DB2BaseDataSource.
Those properties are:
242
Application Programming Guide and Reference for Java
clientAccountingInformation
Specifies accounting information for the current client for the connection. This
information is for client accounting purposes. This value can change during a
connection. The data type of this property is String. The maximum length is
255 bytes. A Java empty string ("") is valid for this value, but a Java null value
is not valid.
clientApplicationInformation
Specifies the application or transaction name of the end user's application. You
can use this property to provide the identity of the client end user for
accounting and monitoring purposes. This value can change during a
connection. The data type of this property is String. For a DB2 for z/OS server,
the maximum length is 32 bytes. For a DB2 Database for Linux, UNIX, and
Windows server, the maximum length is 255 bytes. A Java empty string ("") is
valid for this value, but a Java null value is not valid.
clientProgramId
Specifies a value for the client program ID that can be used to identify the end
user. The data type of this property is String, and the length is 80 bytes. If the
program ID value is less than 80 bytes, the value must be padded with blanks.
clientProgramName
Specifies an application ID that is fixed for the duration of a physical
connection for a client. The value of this property becomes the correlation ID
on a DB2 for z/OS server. Database administrators can use this property to
correlate work on a DB2 for z/OS server to client applications. The data type
of this property is String. The maximum length is 12 bytes. If this value is
null, the IBM Data Server Driver for JDBC and SQLJ supplies a value of
db2jccthread-name.
This property applies only to IBM Data Server Driver for JDBC and SQLJ type
4 connectivity.
concurrentAccessResolution
Specifies whether the IBM Data Server Driver for JDBC and SQLJ requests that
a read transaction can access a committed and consistent image of rows that
are incompatibly locked by write transactions, if the data source supports
accessing currently committed data, and the application isolation level is cursor
stability (CS) or read stability (RS). This option has the same effect as the DB2
CONCURRENTACCESSRESOLUTION bind option. Possible values are:
DB2BaseDataSource.CONCURRENTACCESS_USE_CURRENTLY_COMMITTED (1)
The IBM Data Server Driver for JDBC and SQLJ requests that:
v Read transactions access the currently committed data when the data
is being updated or deleted.
v Read transactions skip rows that are being inserted.
DB2BaseDataSource.CONCURRENTACCESS_WAIT_FOR_OUTCOME (2)
The IBM Data Server Driver for JDBC and SQLJ requests that:
v Read transactions wait for a commit or rollback operation when they
encounter data that is being updated or deleted.
v Read transactions do not skip rows that are being inserted.
DB2BaseDataSource.CONCURRENTACCESS_NOT_SET (0)
Enables the data server's default behavior for read transactions when
lock contention occurs. This is the default value.
Chapter 7. JDBC and SQLJ reference information
243
currentDegree
Specifies the degree of parallelism for the execution of queries that are
dynamically prepared. The type of this property is String. The currentDegree
value is used to set the CURRENT DEGREE special register on the data source.
If currentDegree is not set, no value is passed to the data source.
currentExplainMode
Specifies the value for the CURRENT EXPLAIN MODE special register. The
CURRENT EXPLAIN MODE special register enables and disables the Explain
facility. The data type of this property is String. The maximum length is 254
bytes. This property applies only to connections to data sources that support
the CURRENT EXPLAIN MODE special register.
currentFunctionPath
Specifies the SQL path that is used to resolve unqualified data type names and
function names in SQL statements that are in JDBC programs. The data type of
this property is String. For a DB2 Database for Linux, UNIX, and Windows
server, the maximum length is 254 bytes. For a DB2 for z/OS server, the
maximum length is 2048 bytes. The value is a comma-separated list of schema
names. Those names can be ordinary or delimited identifiers.
currentMaintainedTableTypesForOptimization
Specifies a value that identifies the types of objects that can be considered
when the data source optimizes the processing of dynamic SQL queries. This
register contains a keyword representing table types. The data type of this
property is String.
Possible values of currentMaintainedTableTypesForOptimization are:
ALL
Indicates that all materialized query tables will be considered.
NONE
Indicates that no materialized query tables will be considered.
SYSTEM
Indicates that only system-maintained materialized query tables that are
refresh deferred will be considered.
USER
Indicates that only user-maintained materialized query tables that are
refresh deferred will be considered.
currentPackagePath
Specifies a comma-separated list of collections on the server. The database
server searches these collections for JDBC and SQLJ packages.
The precedence rules for the currentPackagePath and currentPackageSet
properties follow the precedence rules for the CURRENT PACKAGESET and
CURRENT PACKAGE PATH special registers.
currentPackageSet
Specifies the collection ID to search for JDBC and SQLJ packages. The data
type of this property is String. The default is NULLID for IBM Data Server
Driver for JDBC and SQLJ type 4 connectivity. For IBM Data Server Driver for
JDBC and SQLJ type 2 connectivity, if a value for currentPackageSet is not
specified, the property value is not set. If currentPackageSet is set, its value
overrides the value of jdbcCollection.
Multiple instances of the IBM Data Server Driver for JDBC and SQLJ can be
installed at a database server by running the DB2Binder utility multiple times.
The DB2binder utility includes a -collection option that lets the installer specify
244
Application Programming Guide and Reference for Java
the collection ID for each IBM Data Server Driver for JDBC and SQLJ instance.
To choose an instance of the IBM Data Server Driver for JDBC and SQLJ for a
connection, you specify a currentPackageSet value that matches the collection
ID for one of the IBM Data Server Driver for JDBC and SQLJ instances.
The precedence rules for the currentPackagePath and currentPackageSet
properties follow the precedence rules for the CURRENT PACKAGESET and
CURRENT PACKAGE PATH special registers.
currentRefreshAge
Specifies a timestamp duration value that is the maximum duration since a
REFRESH TABLE statement was processed on a system-maintained REFRESH
DEFERRED materialized query table such that the materialized query table can
be used to optimize the processing of a query. This property affects dynamic
statement cache matching. The data type of this property is long.
currentSchema
Specifies the default schema name that is used to qualify unqualified database
objects in dynamically prepared SQL statements. The value of this property
sets the value in the CURRENT SCHEMA special register on the database
server. The schema name is case-sensitive, and must be specified in uppercase
characters.
cursorSensitivity
Specifies whether the java.sql.ResultSet.TYPE_SCROLL_SENSITIVE value for a
JDBC ResultSet maps to the SENSITIVE DYNAMIC attribute, the SENSITIVE
STATIC attribute, or the ASENSITIVE attribute for the underlying database
cursor. The data type of this property is int. Possible values are
TYPE_SCROLL_SENSITIVE_STATIC (0), TYPE_SCROLL_SENSITIVE_DYNAMIC (1), or
TYPE_SCROLL_ASENSITIVE (2). The default is TYPE_SCROLL_SENSITIVE_STATIC.
If the data source does not support sensitive dynamic scrollable cursors, and
TYPE_SCROLL_SENSITIVE_DYNAMIC is requested, the JDBC driver accumulates a
warning and maps the sensitivity to SENSITIVE STATIC. For DB2 for i
database servers, which do not support sensitive static cursors,
java.sql.ResultSet.TYPE_SCROLL_SENSITIVE always maps to SENSITIVE
DYNAMIC.
dateFormat
Specifies:
v The format in which the String argument of the
PreparedStatement.setString method against a DATE column must be
specified.
v The format in which the result of the ResultSet.getString or
CallableStatement.getString method against a DATE column is returned.
The data type of dateFormat is int.
Possible values of dateFormat are:
Constant
Integer
value
Format
com.ibm.db2.jcc.DB2BaseDataSource.ISO
1
yyyy-mm-dd
com.ibm.db2.jcc.DB2BaseDataSource.USA
2
mm/dd/yyyy
com.ibm.db2.jcc.DB2BaseDataSource.EUR
3
dd.mm.yyyy
com.ibm.db2.jcc.DB2BaseDataSource.JIS
4
yyyy-mm-dd
The default is com.ibm.db2.jcc.DB2BaseDataSource.ISO.
Chapter 7. JDBC and SQLJ reference information
245
decimalRoundingMode
Specifies the rounding mode for decimal floating-point values on DB2 for
z/OS Version 9 or later, or DB2 Database for Linux, UNIX, and Windows
database servers.
Possible values are:
DB2BaseDataSource.ROUND_DOWN (1)
Rounds the value towards 0 (truncation). The discarded digits are
ignored.
DB2BaseDataSource.ROUND_CEILING (2)
Rounds the value towards positive infinity. If all of the discarded digits
are zero or if the sign is negative the result is unchanged other than
the removal of the discarded digits. Otherwise, the result coefficient is
incremented by 1.
DB2BaseDataSource.ROUND_HALF_EVEN (3)
Rounds the value to the nearest value; if the values are equidistant,
rounds the value so that the final digit is even. If the discarded digits
represents greater than half (0.5) of the value of one in the next left
position then the result coefficient is incremented by 1. If they
represent less than half, then the result coefficient is not adjusted (that
is, the discarded digits are ignored). Otherwise the result coefficient is
unaltered if its rightmost digit is even, or is incremented by 1 if its
rightmost digit is odd (to make an even digit).
DB2BaseDataSource.ROUND_HALF_UP (4)
Rounds the value to the nearest value; if the values are equidistant,
rounds the value away from zero. If the discarded digits represent
greater than or equal to half (0.5) of the value of one in the next left
position then the result coefficient is incremented by 1. Otherwise the
discarded digits are ignored.
DB2BaseDataSource.ROUND_FLOOR (6)
Rounds the value towards negative infinity. If all of the discarded
digits are zero or if the sign is positive the result is unchanged other
than the removal of discarded digits. Otherwise, the sign is negative
and the result coefficient is incremented by 1.
DB2BaseDataSource.ROUND_UNSET (-2147483647)
No rounding mode was explicitly set. The IBM Data Server Driver for
JDBC and SQLJ does not use the decimalRoundingMode to set the
rounding mode on the data source.
The IBM Data Server Driver for JDBC and SQLJ uses the following
values for its rounding mode:
v For DB2 for z/OS or DB2 Database for Linux, UNIX, and Windows
database servers, the rounding mode is ROUND_HALF_EVEN for
decimal floating-point values.
If decimalRoundingMode is set, the decimalRoundingMode value is used to set
the CURRENT DECFLOAT ROUNDING MODE special register on DB2 for
z/OS database servers.
enableExtendedIndicators
Specifies whether support for extended indicators is enabled in the IBM Data
Server Driver for JDBC and SQLJ. Possible values are:
246
Application Programming Guide and Reference for Java
DB2BaseDataSource.YES (1)
Support for extended indicators is enabled in the IBM Data Server
Driver for JDBC and SQLJ.
DB2BaseDataSource.NO (2)
Support for extended indicators is disabled in the IBM Data Server
Driver for JDBC and SQLJ.
DB2BaseDataSource.NOT_SET (0)
Support for extended indicators is enabled in the IBM Data Server
Driver for JDBC and SQLJ. This is the default value.
enableRowsetSupport
Specifies whether the IBM Data Server Driver for JDBC and SQLJ uses
multiple-row FETCH for forward-only cursors or scrollable cursors, if the data
source supports multiple-row FETCH. The data type of this property is int.
When enableRowsetSupport is set, its value overrides the useRowsetCursor
property value.
Possible values are:
DB2BaseDataSource.YES (1)
Specifies that:
v For IBM Data Server Driver for JDBC and SQLJ type 2 connectivity
to DB2 for z/OS, multiple-row FETCH is used for scrollable cursors
and forward-only cursors, if the data source supports multiple-row
FETCH.
v For IBM Data Server Driver for JDBC and SQLJ type 4 connectivity,
or IBM Data Server Driver for JDBC and SQLJ type 2 connectivity to
DB2 Database for Linux, UNIX, and Windows, multiple-row fetch is
used for scrollable cursors, if the data source supports multiple-row
FETCH.
DB2BaseDataSource.NO (2)
Specifies that multiple-row fetch is not used.
DB2BaseDataSource.NOT_SET (0)
Specifies that if the enableRowsetSupport property is not set:
v For IBM Data Server Driver for JDBC and SQLJ type 2 connectivity
to DB2 for z/OS, multiple-row fetch is not used.
v For IBM Data Server Driver for JDBC and SQLJ type 4 connectivity,
or IBM Data Server Driver for JDBC and SQLJ type 2 connectivity to
DB2 Database for Linux, UNIX, and Windows, the useRowsetCursor
property determines whether multiple-row fetch is used for
scrollable cursors.
For IBM Data Server Driver for JDBC and SQLJ type 2 connectivity to DB2 for
z/OS, multiple-row fetch is not compatible with progressive streaming.
Therefore, if progressive streaming is used for a FETCH operation,
multiple-row FETCH is not used.
encryptionAlgorithm
Specifies whether the IBM Data Server Driver for JDBC and SQLJ uses 56-bit
DES (weak) encryption or 256-bit AES (strong) encryption. The data type of
this property is int. Possible values are:
1
The driver uses 56-bit DES encryption.
2
The driver uses 256-bit AES encryption, if the database server supports
Chapter 7. JDBC and SQLJ reference information
247
it. 256-bit AES encryption is available for IBM Data Server Driver for
JDBC and SQLJ type 4 connectivity only.
For AES encryption, you need an unrestricted policy file for JCE. That
file is available at the following location:
https://www14.software.ibm.com/webapp/iwm/web/preLogin.do?source=jcesdk
encryptionAlgorithm can be specified only if the securityMechanism value is
ENCRYPTED_PASSWORD_SECURITY (7) or ENCRYPTED_USER_AND_PASSWORD_SECURITY
(9).
fullyMaterializeInputStreams
Indicates whether streams are fully materialized before they are sent from the
client to a data source. The data type of this property is boolean. The default is
false.
If the value of fullyMaterializeInputStreams is true, the JDBC driver fully
materialized the streams before sending them to the server.
gssCredential
For a data source that uses Kerberos security, specifies a delegated credential
that is passed from another principal. The data type of this property is
org.ietf.jgss.GSSCredential. Delegated credentials are used in multi-tier
environments, such as when a client connects to WebSphere Application Server,
which, in turn, connects to the data source. You obtain a value for this
property from the client, by invoking the GSSContext.getDelegCred method.
GSSContext is part of the IBM Java Generic Security Service (GSS) API. If you
set this property, you also need to set the Mechanism and
KerberosServerPrincipal properties.
This property is applicable only to IBM Data Server Driver for JDBC and SQLJ
type 4 connectivity.
For more information on using Kerberos security with the IBM Data Server
Driver for JDBC and SQLJ, see "Using Kerberos security under the IBM Data
Server Driver for JDBC and SQLJ".
kerberosServerPrincipal
For a data source that uses Kerberos security, specifies the name that is used
for the data source when it is registered with the Kerberos Key Distribution
Center (KDC). The data type of this property is String.
This property is applicable only to IBM Data Server Driver for JDBC and SQLJ
type 4 connectivity.
pdqProperties
Specifies properties that control the interaction between the IBM Data Server
Driver for JDBC and SQLJ and the client optimization feature of pureQuery.
The data type of this property is String.
Set the pdqProperties property only if you are using the client optimization
feature of pureQuery. See the Integrated Data Management Information Center
for information about valid values for pdqProperties.
readOnly
Specifies whether the connection is read-only. The data type of this property is
boolean. The default is false.
resultSetHoldabilityForCatalogQueries
Specifies whether cursors for queries that are executed on behalf of
DatabaseMetaData methods remain open after a commit operation. The data
type of this property is int.
248
Application Programming Guide and Reference for Java
When an application executes DatabaseMetaData methods, the IBM Data Server
Driver for JDBC and SQLJ executes queries against the catalog of the target
data source. By default, the holdability of those cursors is the same as the
holdability of application cursors. To use different holdability for catalog
queries, use the resultSetHoldabilityForCatalogQueries property. Possible
values are:
DB2BaseDataSource.HOLD_CURSORS_OVER_COMMIT (1)
Leave cursors for catalog queries open after a commit operation,
regardless of the resultSetHoldability setting.
DB2BaseDataSource.CLOSE_CURSORS_AT_COMMIT (2)
Close cursors for catalog queries after a commit operation, regardless
of the resultSetHoldability setting.
DB2BaseDataSource.NOT_SET (0)
Use the resultSetHoldability setting for catalog queries. This is the
default value.
returnAlias
Specifies whether the JDBC driver returns rows for table aliases and synonyms
for DatabaseMetaData methods that return table information, such as
getTables. The data type of returnAlias is int. Possible values are:
0
Do not return rows for aliases or synonyms of tables in output from
DatabaseMetaData methods that return table information.
1
For tables that have aliases or synonyms, return rows for aliases and
synonyms of those tables, as well as rows for the tables, in output from
DatabaseMetaData methods that return table information. This is the
default.
statementConcentrator
Specifies whether the IBM Data Server Driver for JDBC and SQLJ uses the data
source's statement concentrator functionality. The statement concentrator is the
ability to bypass preparation of a statement when it is the same as a statement
in the dynamic statement cache, except for literal values. Statement
concentrator functionality applies only to SQL statements that have literals but
no parameter markers. Possible values are:
DB2BaseDataSource.STATEMENT_CONCENTRATOR_OFF (1)
The IBM Data Server Driver for JDBC and SQLJ does not use the data
source's statement concentrator functionality.
DB2BaseDataSource.STATEMENT_CONCENTRATOR_WITH_LITERALS (2)
The IBM Data Server Driver for JDBC and SQLJ uses the data source's
statement concentrator functionality.
DB2BaseDataSource.STATEMENT_CONCENTRATOR_NOT_SET (0)
Enables the data server's default behavior for statement concentrator
functionality. This is the default value.
For DB2 Database for Linux, UNIX, and Windows data sources that
support statement concentrator functionality, the functionality is used if
the STMT_CONC configuration parameter is set to ON at the data
source. Otherwise, statement concentrator functionality is not used.
For DB2 for z/OS data sources that support statement concentrator
functionality, the functionality is not used if statementConcentrator is
not set.
Chapter 7. JDBC and SQLJ reference information
249
streamBufferSize
Specifies the size, in bytes, of the JDBC driver buffers for chunking LOB or
XML data. The JDBC driver uses the streamBufferSize value whether or not it
uses progressive streaming. The data type of streamBufferSize is int. The
default is 1048576.
If the JDBC driver uses progressive streaming, LOB or XML data is
materialized if it fits in the buffers, and the driver does not use the
fullyMaterializeLobData property.
DB2 for z/OS Version 9.1 and later supports progressive streaming for LOBs
and XML objects. DB2 Database for Linux, UNIX, and Windows Version 9.5
and later, and IBM Informix Version 11.50 and later support progressive
streaming for LOBs.
supportsAsynchronousXARollback
Specifies whether the IBM Data Server Driver for JDBC and SQLJ supports
asynchronous XA rollback operations. The data type of this property is int. The
default is DB2BaseDataSource.NO (2). If the application runs against a BEA
WebLogic Server application server, set supportsAsynchronousXARollback to
DB2BaseDataSource.YES (1).
sysSchema
Specifies the schema of the shadow catalog tables or views that are searched
when an application invokes a DatabaseMetaData method. The sysSchema
property was formerly called cliSchema.
timeFormat
Specifies:
v The format in which the String argument of the
PreparedStatement.setString method against a TIME column must be
specified.
v The format in which the result of the ResultSet.getString or
CallableStatement.getString method against a TIME column is returned.
The data type of timeFormat is int.
Possible values of timeFormat are:
Constant
Integer
value
Format
com.ibm.db2.jcc.DB2BaseDataSource.ISO
1
hh:mm:ss
com.ibm.db2.jcc.DB2BaseDataSource.USA
2
hh:mm am or hh:mm
pm
com.ibm.db2.jcc.DB2BaseDataSource.EUR
3
hh.mm.ss
com.ibm.db2.jcc.DB2BaseDataSource.JIS
4
hh:mm:ss
The default is com.ibm.db2.jcc.DB2BaseDataSource.ISO.
timestampOutputType
Specifies whether the IBM Data Server Driver for JDBC and SQLJ returns a
java.sql.Timestamp object or a com.ibm.db2.jcc.DBTimestamp when the
standard JDBC interfaces ResultSet.getTimestamp,
CallableStatement.getTimestamp, ResultSet.getObject, or
CallableStatement.getObject are called to return timestamp information.
Possible values are:
DB2BaseDataSource.JDBC_TIMESTAMP (1)
The IBM Data Server Driver for JDBC and SQLJ returns
250
Application Programming Guide and Reference for Java
java.sql.Timestamp objects from ResultSet.getTimestamp,
CallableStatement.getTimestamp, ResultSet.getObject, or
CallableStatement.getObject calls.
DB2BaseDataSource.JCC_DBTIMESTAMP (2)
The IBM Data Server Driver for JDBC and SQLJ returns
com.ibm.db2.jcc.DBTimestamp objects from ResultSet.getTimestamp,
CallableStatement.getTimestamp, ResultSet.getObject, or
CallableStatement.getObject calls.
DB2BaseDataSource.NOT_SET (0)
This is the default behavior.
The behavior is the same as the behavior for
DB2BaseDataSource.JDBC_TIMESTAMP.
useCachedCursor
Specifies whether the underlying cursor for PreparedStatement objects is
cached and reused on subsequent executions of the PreparedStatement. The
data type of useCachedCursor is boolean.
If useCachedCursor is set to true, the cursor for PreparedStatement objects is
cached, which can improve performance. true is the default.
Set useCachedCursor to false if PreparedStatement objects access tables whose
column types or lengths change between executions of those
PreparedStatement objects.
useJDBC4ColumnNameAndLabelSemantics
Specifies how the IBM Data Server Driver for JDBC and SQLJ handles column
labels in ResultSetMetaData.getColumnName,
ResultSetMetaData.getColumnLabel, and ResultSet.findColumn method calls.
Possible values are:
DB2BaseDataSource.YES (1)
The IBM Data Server Driver for JDBC and SQLJ uses the following
rules, which conform to the JDBC 4.0 specification, to determine the
value that ResultSetMetaData.getColumnName,
ResultSetMetaData.getColumnLabel, and ResultSet.findColumn return:
v The column name that is returned by
ResultSetMetaData.getColumnName is its name from the database.
v The column label that is returned by
ResultSetMetaData.getColumnLabel is the label that is specified with
the SQL AS clause. If the SQL AS clause is not specified, the label is
the name of the column.
v ResultSet.findColumn takes the label for the column, as specified
with the SQL AS clause, as input. If the SQL AS clause was not
specified, the label is the column name.
v The IBM Data Server Driver for JDBC and SQLJ does not use a
column label that is assigned by the SQL LABEL ON statement.
These rules apply to IBM Data Server Driver for JDBC and SQLJ
version 3.50 and later, for connections to the following database
systems:
v DB2 for z/OS Version 8 or later
v DB2 Database for Linux, UNIX, and Windows Version 8.1 or later
v DB2 UDB for iSeries® V5R3 or later
Chapter 7. JDBC and SQLJ reference information
251
For earlier versions of the driver or the database systems, the rules for
a useJDBC4ColumnNameAndLabelSemantics value of
DB2BaseDataSource.NO apply, even if
useJDBC4ColumnNameAndLabelSemantics is set to
DB2BaseDataSource.YES.
DB2BaseDataSource.NO (2)
The IBM Data Server Driver for JDBC and SQLJ uses the following
rules to determine the values that ResultSetMetaData.getColumnName,
ResultSetMetaData.getColumnLabel, and ResultSet.findColumn return:
If the data source does not support the LABEL ON statement, or the
source column is not defined with the LABEL ON statement:
v The value that is returned by ResultSetMetaData.getColumnName is
its name from the database, if no SQL AS clause is specified. If the
SQL AS clause is specified, the value that is returned is the column
label.
v The value that is returned by ResultSetMetaData.getColumnLabel is
the label that is specified with the SQL AS clause. If the SQL AS
clause is not specified, the value that is returned is the name of the
column.
v ResultSet.findColumn takes the column name as input.
If the source column is defined with the LABEL ON statement:
v The value that is returned by ResultSetMetaData.getColumnName is
the column name from the database, if no SQL AS clause is
specified. If the SQL AS clause is specified, the value that is returned
is the column label that is specified in the AS clause.
v The value that is returned by ResultSetMetaData.getColumnLabel is
the label that is specified in the LABEL ON statement.
v ResultSet.findColumn takes the column name as input.
These rules conform to the behavior of the IBM Data Server Driver for
JDBC and SQLJ before Version 3.50.
DB2BaseDataSource.NOT_SET (0)
This is the default behavior.
For the IBM Data Server Driver for JDBC and SQLJ version 3.50 and
earlier, the default behavior for
useJDBC4ColumnNameAndLabelSemantics is the same as the behavior
for DB2BaseDataSource.NO.
For the IBM Data Server Driver for JDBC and SQLJ version 4.0 and
later:
v The default behavior for useJDBC4ColumnNameAndLabelSemantics
is the same as the behavior for DB2BaseDataSource.YES, for
connections to the following database systems:
– DB2 for z/OS Version 8 or later
– DB2 Database for Linux, UNIX, and Windows Version 8.1 or later
– DB2 UDB for iSeries V5R3 or later
v For connections to earlier versions of these database systems, the
default behavior for useJDBC4ColumnNameAndLabelSemantics is
DB2BaseDataSource.NO.
com.ibm.db2.jcc.DB2ConnectionPoolDataSource.maxStatements
Controls an internal statement cache that is associated with a
PooledConnection. The data type of this property is int. Possible values are:
252
Application Programming Guide and Reference for Java
positive integer
Enables the internal statement cache for a PooledConnection, and
specifies the number of statements that the IBM Data Server Driver for
JDBC and SQLJ keeps open in the cache.
0 or negative integer
Disables internal statement caching for the PooledConnection. 0 is the
default.
maxStatements controls the internal statement cache that is associated with a
PooledConnection only when the PooledConnection object is created.
maxStatements has no effect on caching in an already existing
PooledConnection object.
maxStatements applies only to IBM Data Server Driver for JDBC and SQLJ
type 2 connectivity on DB2 for z/OS, and toIBM Data Server Driver for JDBC
and SQLJ type 4 connectivity.
Related reference
Settings for properties for running JDBC applications in DYNAMIC mode
Common IBM Data Server Driver for JDBC and SQLJ
properties for DB2 for z/OS and IBM Informix
Some of the IBM Data Server Driver for JDBC and SQLJ properties apply to IBM
Informix and DB2 for z/OS database servers.
Properties that apply to IBM Informix and DB2 for z/OS are:
enableConnectionConcentrator
Indicates whether the connection concentrator function of the IBM Data Server
Driver for JDBC and SQLJ is enabled.
The data type of enableConnectionConcentrator is boolean. The default is
false. However, if enableSysplexWLB is set to true, the default is true.
enablConnectionConcentrator applies only to IBM Data Server Driver for JDBC
and SQLJ type 4 connectivity.
keepDynamic
Specifies whether the data source keeps already prepared dynamic SQL
statements in the dynamic statement cache after commit points so that those
prepared statements can be reused. The data type of this property is int. Valid
values are DB2BaseDataSource.YES (1) and DB2BaseDataSource.NO (2).
If the keepDynamic property is not specified, the keepDynamic value is
DB2BaseDataSource.NOT_SET (0). If the connection is to a DB2 for z/OS server,
caching of dynamic statements for a connection is not done if the property is
not set. If the connection is to an IBM Informix data source, caching of
dynamic statements for a connection is done if the property is not set.
keepDynamic is used with the DB2Binder -keepdynamic option. The
keepDynamic property value that is specified must match the -keepdynamic
value that was specified when DB2Binder was run.
For a DB2 for z/OS database server, dynamic statement caching can be done
only if the EDM dynamic statement cache is enabled on the data source. The
CACHEDYN subsystem parameter must be set to DB2BaseDataSource.YES to
enable the dynamic statement cache.
maxTransportObjects
Specifies the maximum number of transport objects that can be used for all
Chapter 7. JDBC and SQLJ reference information
253
connections with the associated DataSource object. The IBM Data Server Driver
for JDBC and SQLJ uses transport objects and a global transport objects pool to
support the connection concentrator and Sysplex workload balancing. There is
one transport object for each physical connection to the data source.
The data type of this property is int.
The maxTransportObjects value is ignored if the enableConnectionConcentrator
or enableSysplexWLB properties are not set to enable the use of the connection
concentrator or Sysplex workload balancing.
If the maxTransportObjects value has not been reached, and a transport object
is not available in the global transport objects pool, the pool creates a new
transport object. If the maxTransportObjects value has been reached, the
application waits for the amount of time that is specified by the
db2.jcc.maxTransportObjectWaitTime configuration property. After that amount
of time has elapsed, if there is still no available transport object in the pool, the
pool throws an SQLException.
maxTransportObjects does not override the db2.jcc.maxTransportObjects
configuration property. maxTransportObjects has no effect on connections from
other DataSource objects. If the maxTransportObjects value is larger than the
db2.jcc.maxTransportObjects value, maxTransportObjects does not increase the
db2.jcc.maxTransportObjects value.
The default value for maxTransportObjects is -1, which means that the number
of transport objects for the DataSource is limited only by the
db2.jcc.maxTransportObjects value for the driver.
Common IBM Data Server Driver for JDBC and SQLJ
properties for IBM Informix and DB2 Database for Linux, UNIX,
and Windows
Some of the IBM Data Server Driver for JDBC and SQLJ properties apply to IBM
Informix and DB2 Database for Linux, UNIX, and Windows database servers.
Properties that apply to IBM Informix and DB2 Database for Linux, UNIX, and
Windows are:
currentLockTimeout
Specifies whether DB2 Database for Linux, UNIX, and Windows servers wait
for a lock when the lock cannot be obtained immediately. The data type of this
property is int. Possible values are:
integer Wait for integer seconds. integer is between -1 and 32767, inclusive.
LOCK_TIMEOUT_NO_WAIT
Do not wait for a lock. This is the default.
LOCK_TIMEOUT_WAIT_INDEFINITELY
Wait indefinitely for a lock.
LOCK_TIMEOUT_NOT_SET
Use the default for the data source.
IBM Data Server Driver for JDBC and SQLJ properties for DB2
Database for Linux, UNIX, and Windows
Some of the IBM Data Server Driver for JDBC and SQLJ properties apply only to
DB2 Database for Linux, UNIX, and Windows servers.
254
Application Programming Guide and Reference for Java
Those properties are:
connectNode
Specifies the target database partition server that an application connects to.
The data type of this property is int. The value can be between 0 and 999. The
default is database partition server that is defined with port 0. connectNode
applies to IBM Data Server Driver for JDBC and SQLJ type 4 connectivity to
DB2 Database for Linux, UNIX, and Windows servers only.
currentExplainSnapshot
Specifies the value for the CURRENT EXPLAIN SNAPSHOT special register.
The CURRENT EXPLAIN SNAPSHOT special register enables and disables the
Explain snapshot facility. The data type of this property is String. The
maximum length is eight bytes. This property applies only to connections to
data sources that support the CURRENT EXPLAIN SNAPSHOT special
register, such as DB2 Database for Linux, UNIX, and Windows.
currentQueryOptimization
Specifies a value that controls the class of query optimization that is performed
by the database manager when it binds dynamic SQL statements. The data
type of this property is int. The possible values of currentQueryOptimization
are:
0
Specifies that a minimal amount of optimization is performed to
generate an access plan. This class is most suitable for simple dynamic
SQL access to well-indexed tables.
1
Specifies that optimization roughly comparable to DB2 Database for
Linux, UNIX, and Windows Version 1 is performed to generate an
access plan.
2
Specifies a level of optimization higher than that of DB2 Database for
Linux, UNIX, and Windows Version 1, but at significantly less
optimization cost than levels 3 and above, especially for very complex
queries.
3
Specifies that a moderate amount of optimization is performed to
generate an access plan.
5
Specifies a significant amount of optimization is performed to generate
an access plan. For complex dynamic SQL queries, heuristic rules are
used to limit the amount of time spent selecting an access plan. Where
possible, queries will use materialized query tables instead of the
underlying base tables.
7
Specifies a significant amount of optimization is performed to generate
an access plan. This value is similar to 5 but without the heuristic
rules.
9
Specifies the maximum amount of optimization is performed to
generate an access plan. This can greatly expand the number of
possible access plans that are evaluated. This class should be used to
determine if a better access plan can be generated for very complex
and very long-running queries using large tables. Explain and
performance measurements can be used to verify that a better plan has
been generated.
optimizationProfile
Specifies an optimization profile that is used during SQL optimization. The
data type of this property is String. The optimizationProfile value is used to set
the OPTIMIZATION PROFILE special register. The default is null.
Chapter 7. JDBC and SQLJ reference information
255
optimizationProfile applies to DB2 Database for Linux, UNIX, and Windows
servers only.
optimizationProfileToFlush
Specifies the name of an optimization profile that is to be removed from the
optimization profile cache. The data type of this property is String. The default
is null.
plugin
The name of a client-side JDBC security plug-in. This property has the Object
type and contains a new instance of the JDBC security plug-in method.
pluginName
The name of a server-side security plug-in module.
retryWithAlternativeSecurityMechanism
Specifies whether the IBM Data Server Driver for JDBC and SQLJ retries a
connection with an alternative security mechanism if the security mechanism
that is specified by property securityMechanism is not supported by the data
source. The data type of this property is int. Possible values are:
com.ibm.db2.jcc.DB2BaseDataSource.YES (1)
Retry the connection using an alternative security mechanism. The IBM
Data Server Driver for JDBC and SQLJ issues warning code +4222 and
retries the connection with the most secure available security
mechanism.
com.ibm.db2.jcc.DB2BaseDataSource.NO (2) or
com.ibm.db2.jcc.DB2BaseDataSource.NOT_SET (0)
Do not retry the connection using an alternative security mechanism.
retryWithAlternativeSecurityMechanism applies to IBM Data Server Driver for
JDBC and SQLJ type 4 connectivity connections to DB2 Database for Linux,
UNIX, and Windows only.
useTransactionRedirect
Specifies whether the DB2 system directs SQL statements to different database
partitions for better performance. The data type of this property is boolean.
The default is false.
This property is applicable only under the following conditions:
v The connection is to a DB2 Database for Linux, UNIX, and Windows server
that uses the Database Partitioning Feature (DPF).
v The partitioning key remains constant throughout a transaction.
If useTransactionRedirect is true, the IBM Data Server Driver for JDBC and
SQLJ sends connection requests to the DPF node that contains the target data
of the first directable statement in the transaction. DB2 Database for Linux,
UNIX, and Windows then directs the SQL statement to different partitions as
needed.
IBM Data Server Driver for JDBC and SQLJ properties for DB2
for z/OS
Some of the IBM Data Server Driver for JDBC and SQLJ properties apply only to
DB2 for z/OS servers.
Those properties are:
256
Application Programming Guide and Reference for Java
accountingInterval
Specifies whether DB2 accounting records are produced at commit points or on
termination of the physical connection to the data source. The data type of this
property is String.
If the value of accountingInterval is "COMMIT", and there are no open, held
cursors, DB2 writes an accounting record each time that the application
commits work. If the value of accountingInterval is "COMMIT", and the
application performs a commit operation while a held cursor is open, the
accounting interval spans that commit point and ends at the next valid
accounting interval end point. If the value of accountingInterval is not
"COMMIT", accounting records are produced on termination of the physical
connection to the data source.
The accountingInterval property sets the accounting-interval parameter for an
underlying RRSAF signon call. If the value of subsystem parameter
ACCUMACC is not NO, the ACCUMACC value overrides the
accountingInterval setting.
accountingInterval applies only to IBM Data Server Driver for JDBC and SQLJ
type 2 connectivity on DB2 for z/OS. accountingInterval is not applicable to
connections under CICS or IMS, or for Java stored procedures.
The accountingInterval property overrides the db2.jcc.accountingInterval
configuration property.
charOutputSize
Specifies the maximum number of bytes to use for INOUT or OUT stored
procedure parameters that are registered as Types.CHAR charOutputSize applies
only to IBM Data Server Driver for JDBC and SQLJ type 2 connectivity to DB2
for z/OS database servers.
Because DESCRIBE information for stored procedure INOUT and OUT
parameters is not available at run time, by default, the IBM Data Server Driver
for JDBC and SQLJ sets the maximum length of each character INOUT or OUT
parameter to 32767. For stored procedures with many Types.CHAR parameters,
this maximum setting can result in allocation of much more storage than is
necessary.
To use storage more efficiently, set charOutputSize to the largest expected
length for any Types.CHAR INOUT or OUT parameter.
charOutputSize has no effect on INOUT or OUT parameters that are registered
as Types.VARCHAR or Types.LONGVARCHAR. The driver uses the default length of
32767 for Types.VARCHAR and Types.LONGVARCHAR parameters.
The value that you choose for charOutputSize needs to take into account the
possibility of expansion during character conversion. Because the IBM Data
Server Driver for JDBC and SQLJ has no information about the server-side
CCSID that is used for output parameter values, the driver requests the stored
procedure output data in UTF-8 Unicode. The charOutputSize value needs to
be the maximum number of bytes that are needed after the parameter value is
converted to UTF-8 Unicode. UTF-8 Unicode characters can require up to three
bytes. (The euro symbol is an example of a three-byte UTF-8 character.) To
ensure that the value of charOutputSize is large enough, if you have no
information about the output data, set charOutputSize to three times the
defined length of the largest CHAR parameter.
clientUser
Specifies the current client user name for the connection. This information is
Chapter 7. JDBC and SQLJ reference information
257
for client accounting purposes. Unlike the JDBC connection user name, this
value can change during a connection. For a DB2 for z/OS server, the
maximum length is 16 bytes.
This property applies only to IBM Data Server Driver for JDBC and SQLJ type
2 connectivity on DB2 for z/OS.
clientWorkstation
Specifies the workstation name for the current client for the connection. This
information is for client accounting purposes. This value can change during a
connection. The data type of this property is String. For a DB2 for z/OS server,
the maximum length is 18 bytes. A Java empty string ("") is valid for this
value, but a Java null value is not valid.
This property applies only to IBM Data Server Driver for JDBC and SQLJ type
2 connectivity on DB2 for z/OS.
currentSQLID
Specifies:
v The authorization ID that is used for authorization checking on dynamically
prepared CREATE, GRANT, and REVOKE SQL statements.
v The owner of a table space, database, storage group, or synonym that is
created by a dynamically issued CREATE statement.
v The implicit qualifier of all table, view, alias, and index names specified in
dynamic SQL statements.
currentSQLID sets the value in the CURRENT SQLID special register on a DB2
for z/OS server. If the currentSQLID property is not set, the default schema
name is the value in the CURRENT SQLID special register.
enableMultiRowInsertSupport
Specifies whether the IBM Data Server Driver for JDBC and SQLJ uses
multi-row INSERT for batched INSERT or MERGE operations, when the target
data server is a DB2 for z/OS server that supports multi-row INSERT. The
batch operations must be PreparedStatement calls with parameter markers. The
data type of this property is boolean. The default is true.
The enableMultiRowInsertSupport value cannot be changed for the duration of
a connection. enableMultiRowInsertSupport must be set to false if INSERT
FROM SELECT statements are executed in a batch. Otherwise, the driver
throws a BatchUpdateException.
jdbcCollection
Specifies the collection ID for the packages that are used by an instance of the
IBM Data Server Driver for JDBC and SQLJ at run time. The data type of
jdbcCollection is String. The default is NULLID.
This property is used with the DB2Binder -collection option. The DB2Binder
utility must have previously bound IBM Data Server Driver for JDBC and
SQLJ packages at the server using a -collection value that matches the
jdbcCollection value.
The jdbcCollection setting does not determine the collection that is used for
SQLJ applications. For SQLJ, the collection is determined by the -collection
option of the SQLJ customizer.
jdbcCollection does not apply to IBM Data Server Driver for JDBC and SQLJ
type 2 connectivity on DB2 for z/OS.
maxRowsetSize
Specifies the maximum number of bytes that are used for rowset buffering for
258
Application Programming Guide and Reference for Java
each statement, when the IBM Data Server Driver for JDBC and SQLJ uses
multiple-row FETCH for cursors. The data type of this property is int. The
default is 32767.
maxRowsetSize applies only to IBM Data Server Driver for JDBC and SQLJ
type 2 connectivity on DB2 for z/OS.
pkList
Specifies a package list that is used for the underlying RRSAF CREATE
THREAD call when a JDBC or SQLJ connection to a data source is established.
pkList applies only to IBM Data Server Driver for JDBC and SQLJ type 2
connectivity on DB2 for z/OS.
Specify this property if you do not bind plans for your SQLJ programs or for
the JDBC driver. If you specify this property, do not specify planName.
Recommendation: Use pkList instead of planName.
The format of the package list is:
,
collection-ID.*
pkList overrides the value of the db2.jcc.pkList configuration property. If
pkList, planName, and db2.jcc.pkList are not specified, the value of pkList is
NULLID.*.
planName
Specifies a DB2 plan name that is used for the underlying RRSAF CREATE
THREAD call when a JDBC or SQLJ connection to a data source is established.
planName applies only to IBM Data Server Driver for JDBC and SQLJ type 2
connectivity on DB2 for z/OS.
Specify this property if you bind plans for your SQLJ programs and for the
JDBC driver packages. If you specify this property, do not specify pkList.
planName overrides the value of the db2.jcc.planName configuration property.
If pkList, planName, and db2.jcc.planName are not specified, NULLID.* is
used as the package list for the underlying CREATE THREAD call.
reportLongTypes
Specifies whether DatabaseMetaData methods report LONG VARCHAR and
LONG VARGRAPHIC column data types as long data types. The data type of
this property is short. Possible values are:
com.ibm.db2.jcc.DB2BaseDataSource.NO (2) or
com.ibm.db2.jcc.DB2BaseDataSource.NOT_SET (0)
Specifies that DatabaseMetaData methods that return information about
a LONG VARCHAR or LONG VARGRAPHIC column return
java.sql.Types.VARCHAR in the DATA_TYPE column and VARCHAR
or VARGRAPHIC in the TYPE_NAME column of the result set. This is
the default for DB2 for z/OS Version 9 or later.
com.ibm.db2.jcc.DB2BaseDataSource.YES (1)
Specifies that DatabaseMetaData methods that return information about
a LONG VARCHAR or LONG VARGRAPHIC column return
java.sql.Types.LONGVARCHAR in the DATA_TYPE column and
LONG VARCHAR or LONG VARGRAPHIC in the TYPE_NAME
column of the result set.
Chapter 7. JDBC and SQLJ reference information
259
sendCharInputsUTF8
Specifies whether the IBM Data Server Driver for JDBC and SQLJ converts
character input data to the CCSID of the DB2 for z/OS database server, or
sends the data in UTF-8 encoding for conversion by the database server.
sendCharInputsUTF8 applies to IBM Data Server Driver for JDBC and SQLJ
type 2 connectivity to DB2 for z/OS database servers only. The data type of
this property is int. If this property is also set at the driver level
(db2.jcc.sendCharInputsUTF8), this value overrides the driver-level value.
Possible values are:
com.ibm.db2.jcc.DB2BaseDataSource.NO (2)
Specifies that the IBM Data Server Driver for JDBC and SQLJ converts
character input data to the target encoding before the data is sent to
the DB2 for z/OS database server.
com.ibm.db2.jcc.DB2BaseDataSource.NO is the default.
com.ibm.db2.jcc.DB2BaseDataSource.YES (1)
Specifies that the IBM Data Server Driver for JDBC and SQLJ sends
character input data to the DB2 for z/OS database server in UTF-8
encoding. The database server converts the data from UTF-8 encoding
to the target CCSID.
Specify com.ibm.db2.jcc.DB2BaseDataSource.YES only if conversion to
the target CCSID by the SDK for Java causes character conversion
problems. The most common problem occurs when you use IBM Data
Server Driver for JDBC and SQLJ type 2 connectivity to insert a
Unicode line feed character (U+000A) into a table column that has
CCSID 37, and then retrieve that data from a non-z/OS client. If the
SDK for Java does the conversion during insertion of the character into
the column, the line feed character is converted to the EBCDIC new
line character X'15'. However, during retrieval, some SDKs for Java on
operating systems other than z/OS convert the X'15' character to the
Unicode next line character (U+0085) instead of the line feed character
(U+000A). The next line character causes unexpected behavior for some
XML parsers. If you set sendCharInputsUTF8 to
com.ibm.db2.jcc.DB2BaseDataSource.YES, the DB2 for z/OS database
server converts the U+000A character to the EBCDIC line feed
character X'25' during insertion into the column, so the character is
always retrieved as a line feed character.
Conversion of data to the target CCSID on the database server might
cause the IBM Data Server Driver for JDBC and SQLJ to use more
memory than conversion by the driver. The driver allocates memory
for conversion of character data from the source encoding to the
encoding of the data that it sends to the database server. The amount
of space that the driver allocates for character data that is sent to a
table column is based on the maximum possible length of the data.
UTF-8 data can require up to three bytes for each character. Therefore,
if the driver sends UTF-8 data to the database server, the driver needs
to allocate three times the maximum number of characters in the input
data. If the driver does the conversion, and the target CCSID is a
single-byte CCSID, the driver needs to allocate only the maximum
number of characters in the input data.
sessionTimeZone
Specifies the setting for the CURRENT SESSION TIME ZONE special register.
The data type of this property is String.
260
Application Programming Guide and Reference for Java
The sessionTimeZone value is a time zone value that is in the format of sth:tm.
s is the sign, th is the time zone hour, and tm is time zone minutes. The range
of valid values is -12:59 to +14:00.
sqljEnableClassLoaderSpecificProfiles
Specifies whether the IBM Data Server Driver for JDBC and SQLJ allows using
and loading of SQLJ profiles with the same Java name in multiple J2EE
application (.ear) files. The data type of this property is boolean. The default is
false. sqljEnableClassLoaderSpecificProfiles is a DataSource property. This
property is primarily intended for use with WebSphere Application Server.
ssid
Specifies the name of the local DB2 for z/OS subsystem to which a connection
is established using IBM Data Server Driver for JDBC and SQLJ type 2
connectivity on DB2 for z/OS. The data type of this property is String.
The ssid property overrides the db2.jcc.ssid configuration property.
ssid can be the subsystem name for a local subsystem or a group attachment
name or subgroup attachment name.
Specification of a single local subsystem name allows more than one subsystem
on a single LPAR to be accessed as a local subsystem for connections that use
IBM Data Server Driver for JDBC and SQLJ type 2 connectivity.
Specification of a group attachment name or subgroup attachment name allows
failover processing to occur if a data sharing group member fails. If the DB2
subsystem to which an application is connected fails, the connection
terminates. However, when new connections use that group attachment name
or subgroup attachment name, DB2 for z/OS uses group or subgroup
attachment processing to find an active DB2 subsystem to which to connect.
ssid applies only to IBM Data Server Driver for JDBC and SQLJ type 2
connectivity to DB2 for z/OS.
useIdentityValLocalForAutoGeneratedKeys
Specifies whether the IBM Data Server Driver for JDBC and SQLJ uses only the
SQL built-in function IDENTITY_VAL_LOCAL to determine automatically
generated key values. The data type of this property is boolean. Possible values
are:
true
Specifies that the IBM Data Server Driver for JDBC and SQLJ always
uses the SQL built-in function IDENTITY_VAL_LOCAL to determine
automatically generated key values. The driver uses
IDENTITY_VAL_LOCAL even if it is possible to use SELECT FROM
INSERT.
Specify true if the target data server supports SELECT FROM INSERT,
but the target objects do not. For example, SELECT FROM INSERT is
not valid for a table on which a trigger is defined.
false
Specifies that the IBM Data Server Driver for JDBC and SQLJ
determines whether to use SELECT FROM INSERT or
IDENTITY_VAL_LOCAL to determine automatically generated keys.
false is the default.
useRowsetCursor
Specifies whether the IBM Data Server Driver for JDBC and SQLJ always uses
multiple-row FETCH for scrollable cursors if the data source supports
multiple-row fetch. The data type of this property is boolean.
Chapter 7. JDBC and SQLJ reference information
261
This property applies only to IBM Data Server Driver for JDBC and SQLJ type
4 connectivity, or to IBM Data Server Driver for JDBC and SQLJ type 2
connectivity to DB2 for z/OS. If the enableRowsetSupport property is not set,
the default for useRowsetCursor is true. If the enableRowsetSupport property
is set, the useRowsetCursor property is not used.
Applications that use the JDBC 1 technique for performing positioned update
or delete operations should set useRowSetCursor to false. Those applications
do not operate properly if the IBM Data Server Driver for JDBC and SQLJ uses
multiple-row FETCH.
xmlFormat
Specifies the format that is used to send XML data to the data server or
retrieve XML data from the data server. The XML format cannot be modified
after a connection is established. Possible values are:
com.ibm.db2.jcc.DB2BaseDataSource.XML_FORMAT_NOT_SET
(-Integer.MAX_VALUE)
Specifies that binary XML format (Extensible Dynamic Binary XML
DB2 Client/Server Binary XML Format) is used if the data server
supports it. If the data server does not support binary XML format,
textual XML format is used. This is the default.
com.ibm.db2.jcc.DB2BaseDataSource.XML_FORMAT_TEXTUAL (0)
Specifies that the XML textual format is used.
com.ibm.db2.jcc.DB2BaseDataSource.XML_FORMAT_BINARY (1)
Specifies that the binary XML format is used.
When binary XML is used, the XML data that is passed to the IBM
Data Server Driver for JDBC and SQLJ cannot refer to external entities,
internal entities, or internal DTDs. External DTDs are supported only if
those DTDs were previously registered in the data source.
Related reference
DDF/RRSAF ACCUM field (ACCUMACC subsystem parameter) (DB2
Installation Guide)
IBM Data Server Driver for JDBC and SQLJ properties for IBM
Informix
Some of the IBM Data Server Driver for JDBC and SQLJ properties apply only to
IBM Informix databases. Those properties correspond to IBM Informix
environment variables.
Properties that are shown in uppercase characters in the following information
must be specified in uppercase. For those properties, getXXX and setXXX methods
are formed by prepending the uppercase property name with get or set. For
example:
boolean dbDate = DB2BaseDateSource.getDBDATE();
The IBM Informix-specific properties are:
DBANSIWARN
Specifies whether the IBM Data Server Driver for JDBC and SQLJ instructs the
IBM Informix database to return an SQLWarning to the application if an SQL
statement does not use ANSI-standard syntax. The data type of this property is
boolean. Possible values are:
262
Application Programming Guide and Reference for Java
false or 0
Do not send a value to the IBM Informix database that instructs the
database to return an SQLWarning to the application if an SQL
statement does not use ANSI-standard syntax. This is the default.
true or 1
Send a value to the IBM Informix database that instructs the database
to return an SQLWarning to the application if an SQL statement does not
use ANSI-standard syntax.
You can use the DBANSIWARN IBM Data Server Driver for JDBC and SQLJ
property to set the DBANSIWARN IBM Informix property, but you cannot use
the DBANSIWARN IBM Data Server Driver for JDBC and SQLJ property to
reset the DBANSIWARN IBM Informix property.
DBDATE
Specifies the end-user format of DATE values. The data type of this property is
String. Possible values are in the description of the DBDATE environment
variable in IBM Informix Guide to SQL: Reference.
The default value is "Y4MD-".
DBPATH
Specifies a colon-separated list of values that identify the database servers that
contain databases. The date type of this property is String. Each value can be:
v A full path name
v A relative path name
v The server name of an IBM Informix database server
v A server name and full path name
The default ".".
DBSPACETEMP
Specifies a comma-separated or colon-separated list of existing dbspaces in
which temporary tables are placed. The data type of this property is String.
If this property is not set, no value is sent to the server. The value for the
DBSPACETEMP environment variable is used.
DBTEMP
Specifies the full path name of an existing directory in which temporary files
and temporary tables are placed. The data type of this property is String. The
default is "/tmp".
DBUPSPACE
Specifies the maximum amount of system disk space and maximum amount of
memory, in kilobytes, that the UPDATE STATISTICS statement can use when it
constructs multiple column distributions simultaneously. The data type of this
property is String.
The format of DBUPSPACE is "maximum-disk-space:maximum-memory".
If this property is not set, no value is sent to the server. The value for the
DBUPSPACE environment variable is used.
DB_LOCALE
Specifies the database locale, which the database server uses to process
locale-sensitive data. The data type of this property is String. Valid values are
the same as valid values for the DB_LOCALE environment variable. The
default value is null.
Chapter 7. JDBC and SQLJ reference information
263
DELIMIDENT
Specifies whether delimited SQL identifiers can be used in an application. The
data type of this property is boolean. Possible values are:
false
The application cannot contain delimited SQL identifiers. Double
quotation marks (") or single quotation marks (') delimit literal strings.
This is the default.
true
The application can contain delimited SQL identifiers. Delimited SQL
identifiers must be enclosed in double quotation marks ("). Single
quotation marks (') delimit literal strings.
IFX_DIRECTIVES
Specifies whether the optimizer allows query optimization directives from
within a query. The data type of this property is String. Possible values are:
"1" or "ON"
Optimization directives are accepted.
"0" or "OFF"
Optimization directives are not accepted.
If this property is not set, no value is sent to the server. The value for the
IFX_DIRECTIVES environment variable is used.
IFX_EXTDIRECTIVES
Specifies whether the optimizer allows external query optimization directives
from the sysdirectives system catalog table to be applied to queries in existing
applications. Possible values are:
"1" or "ON"
External query optimization directives are accepted.
"0" or "OFF"
External query optimization are not accepted.
If this property is not set, no value is sent to the server. The value for the
IFX_EXTDIRECTIVES environment variable is used.
IFX_UPDDESC
Specifies whether a DESCRIBE of an UPDATE statement is permitted. The data
type of this property is String.
Any non-null value indicates that a DESCRIBE of an UPDATE statement is
permitted. The default is "1".
IFX_XASTDCOMPLIANCE_XAEND
Specifies whether global transactions are freed only after an explicit rollback, or
after any rollback. The data type of this property is String. Possible values are:
"0"
Global transactions are freed only after an explicit rollback. This
behavior conforms to the X/Open XA standard.
"1"
Global transactions are freed after any rollback.
If this property is not set, no value is sent to the server. The value for the
IFX_XASTDCOMPLIANCE_XAEND environment variable is used.
INFORMIXOPCACHE
Specifies the size of the memory cache, in kilobytes, for the staging-area
blobspace of the client application. The data type of this property is String. A
value of "0" indicates that the cache is not used.
If this property is not set, no value is sent to the server. The value for the
INFORMIXOPCACHE environment variable is used.
264
Application Programming Guide and Reference for Java
INFORMIXSTACKSIZE
Specifies the stack size, in kilobytes, that the database server uses for the
primary thread of a client session. The data type of this property is String.
If this property is not set, no value is sent to the server. The value for the
INFORMIXSTACKSIZE environment variable is used.
NODEFDAC
Specifies whether the database server prevents default table privileges
(SELECT, INSERT, UPDATE, and DELETE) from being granted to PUBLIC
when a new table is created during the current session, in a database that is
not ANSI compliant. The data type of this property is String. Possible values
are:
"yes"
The database server prevents default table privileges from being
granted to PUBLIC when a new table is created during the current
session, in a database that is not ANSI compliant.
"no"
The database server does not prevent default table privileges from
being granted to PUBLIC when a new table is created during the
current session, in a database that is not ANSI compliant. This is the
default.
OPTCOMPIND
Specifies the preferred method for performing a join operation on an ordered
pair of tables. The data type of this property is String. Possible values are:
"0"
The optimizer chooses a nested-loop join, where possible, over a
sort-merge join or a hash join.
"1"
When the isolation level is repeatable read, the optimizer chooses a
nested-loop join, where possible, over a sort-merge join or a hash join.
When the isolation level is not repeatable read, the optimizer chooses a
join method based on costs.
"2"
The optimizer chooses a join method based on costs, regardless of the
transaction isolation mode.
If this property is not set, no value is sent to the server. The value for the
OPTCOMPIND environment variable is used.
OPTOFC
Specifies whether to enable optimize-OPEN-FETCH-CLOSE functionality. The
data type of this property is String. Possible values are:
"0"
Disable optimize-OPEN-FETCH-CLOSE functionality for all threads of
applications.
"1"
Enable optimize-OPEN-FETCH-CLOSE functionality for all cursors in
all threads of applications.
If this property is not set, no value is sent to the server. The value for the
OPTOFCD environment variable is used.
PDQPRIORITY
Specifies the degree of parallelism that the database server uses. The
PDQPRIORITY value affects how the database server allocates resources,
including memory, processors, and disk reads. The data type of this property is
String. Possible values are:
"HIGH"
When the database server allocates resources among all users, it gives
as many resources as possible to queries.
Chapter 7. JDBC and SQLJ reference information
265
"LOW" or "1"
The database server fetches values from fragmented tables in parallel.
"OFF" or "0"
Parallel processing is disabled.
If this property is not set, no value is sent to the server. The value for the
PDQPRIORITY environment variable is used.
PSORT_DBTEMP
Specifies the full path name of a directory in which the database server writes
temporary files that are used for a sort operation. The data type of this
property is String.
If this property is not set, no value is sent to the server. The value for the
PSORT_DBTEMP environment variable is used.
PSORT_NPROCS
Specifies the maximum number of threads that the database server can use to
sort a query. The data type of this property is String. The maximum value of
PSORT_NPROCS is "10".
If this property is not set, no value is sent to the server. The value for the
PSORT_NPROCS environment variable is used.
STMT_CACHE
Specifies whether the shared-statement cache is enabled. The data type of this
property is String. Possible values are:
"0"
The shared-statement cache is disabled.
"1"
A 512 KB shared-statement cache is enabled.
If this property is not set, no value is sent to the server. The value for the
STMT_CACHE environment variable is used.
dumpPool
Specifies the types of statistics on global transport pool events that are written,
in addition to summary statistics. The global transport pool is used for the
connection concentrator and Sysplex workload balancing.
The data type of dumpPool is int. dumpPoolStatisticsOnSchedule and
dumpPoolStatisticsOnScheduleFile must also be set for writing statistics before
any statistics are written.
You can specify one or more of the following types of statistics with the
db2.jcc.dumpPool property:
v DUMP_REMOVE_OBJECT (hexadecimal: X'01', decimal: 1)
v DUMP_GET_OBJECT (hexadecimal: X'02', decimal: 2)
v DUMP_WAIT_OBJECT (hexadecimal: X'04', decimal: 4)
v DUMP_SET_AVAILABLE_OBJECT (hexadecimal: X'08', decimal: 8)
v DUMP_CREATE_OBJECT (hexadecimal: X'10', decimal: 16)
v DUMP_SYSPLEX_MSG (hexadecimal: X'20', decimal: 32)
v DUMP_POOL_ERROR (hexadecimal: X'80', decimal: 128)
To trace more than one type of event, add the values for the types of events
that you want to trace. For example, suppose that you want to trace
DUMP_GET_OBJECT and DUMP_CREATE_OBJECT events. The numeric
equivalents of these values are 2 and 16, so you specify 18 for the dumpPool
value.
The default is 0, which means that only summary statistics for the global
transport pool are written.
266
Application Programming Guide and Reference for Java
This property does not have a setXXX or a getXXX method.
dumpPoolStatisticsOnSchedule
Specifies how often, in seconds, global transport pool statistics are written to
the file that is specified by dumpPoolStatisticsOnScheduleFile. The global
transport object pool is used for the connection concentrator and Sysplex
workload balancing.
The default is -1. -1 means that global transport pool statistics are not written.
This property does not have a setXXX or a getXXX method.
dumpPoolStatisticsOnScheduleFile
Specifies the name of the file to which global transport pool statistics are
written. The global transport pool is used for the connection concentrator and
Sysplex workload balancing.
If dumpPoolStatisticsOnScheduleFile is not specified, global transport pool
statistics are not written.
This property does not have a setXXX or a getXXX method.
maxTransportObjectIdleTime
Specifies the amount of time in seconds that an unused transport object stays
in a global transport object pool before it can be deleted from the pool.
Transport objects are used for the connection concentrator and Sysplex
workload balancing.
The default value for maxTransportObjectIdleTime is 60. Setting
maxTransportObjectIdleTime to a value less than 0 causes unused transport
objects to be deleted from the pool immediately. Doing this is not
recommended because it can cause severe performance degradation.
This property does not have a setXXX or a getXXX method.
maxTransportObjectWaitTime
Specifies the maximum amount of time in seconds that an application waits for
a transport object if the maxTransportObjects value has been reached. Transport
objects are used for the connection concentrator and Sysplex workload
balancing. When an application waits for longer than the
maxTransportObjectWaitTime value, the global transport object pool throws an
SQLException.
The default value for maxTransportObjectWaitTime is -1. Any negative value
means that applications wait forever.
This property does not have a setXXX or a getXXX method.
minTransportObjects
Specifies the lower limit for the number of transport objects in a global
transport object pool for the connection concentrator and Sysplex workload
balancing. When a JVM is created, there are no transport objects in the pool.
Transport objects are added to the pool as they are needed. After the
minTransportObjects value is reached, the number of transport objects in the
global transport object pool never goes below the minTransportObjects value
for the lifetime of that JVM.
The default value for minTransportObjects is 0. Any value that is less than or
equal to 0 means that the global transport object pool can become empty.
This property does not have a setXXX or a getXXX method.
Chapter 7. JDBC and SQLJ reference information
267
IBM Data Server Driver for JDBC and SQLJ configuration properties
The IBM Data Server Driver for JDBC and SQLJ configuration properties have
driver-wide scope.
The following table summarizes the configuration properties and corresponding
Connection or DataSource properties, if they exist.
Table 38. Summary of Configuration properties and corresponding Connection and DataSource properties
Configuration property name
Connection or DataSource property name:
com.ibm.db2.jcc.DB2BaseDataSource. ...
db2.jcc.accountingInterval
accountingInterval
db2.jcc.allowSqljDuplicateStaticQueries
Notes
1 on page 269, 4 on page
269
4 on page 269
db2.jcc.charOutputSize
charOutputSize
1 on page 269, 4 on page
269
db2.jcc.currentSchema
currentSchema
1 on page 269, 4 on page
269, 6 on page 269
db2.jcc.override.currentSchema
currentSchema
2 on page 269, 4 on page
269, 6 on page 269
db2.jcc.currentSQLID
currentSQLID
1 on page 269, 4 on page
269
db2.jcc.override.currentSQLID
currentSQLID
2 on page 269, 4 on page
269
db2.jcc.decimalRoundingMode
decimalRoundingMode
1 on page 269, 4 on page
269, 6 on page 269
db2.jcc.override.decimalRoundingMode
decimalRoundingMode
2 on page 269, 4 on page
269, 6 on page 269
db2.jcc.defaultSQLState
4 on page 269
db2.jcc.disableSQLJProfileCaching
4 on page 269
db2.jcc.dumpPool
dumpPool
1 on page 269, 3 on page
269, 4 on page 269, 5 on
page 269
db2.jcc.dumpPoolStatisticsOnSchedule
dumpPoolStatisticsOnSchedule
1 on page 269, 3 on page
269, 4 on page 269, 5 on
page 269
db2.jcc.dumpPoolStatisticsOnScheduleFile
dumpPoolStatisticsOnScheduleFile
1 on page 269, 3 on page
269, 4 on page 269, 5 on
page 269
db2.jcc.jmxEnabled
4 on page 269, 5 on page
269, 6 on page 269
db2.jcc.lobOutputSize
4 on page 269
db2.jcc.maxRefreshInterval
4 on page 269, 5 on page
269, 6 on page 269
db2.jcc.maxTransportObjectIdleTime
maxTransportObjectIdleTime
1 on page 269, 4 on page
269, 5 on page 269
db2.jcc.maxTransportObjectWaitTime
maxTransportObjectWaitTime
1 on page 269, 4 on page
269, 5 on page 269
db2.jcc.maxTransportObjects
maxTransportObjects
1 on page 269, 4 on page
269, 5 on page 269
db2.jcc.minTransportObjects
minTransportObjects
1 on page 269, 4 on page
269, 5 on page 269
pkList
1 on page 269, 4 on page
269
db2.jcc.outputDirectory
db2.jcc.pkList
268
6 on page 269
Application Programming Guide and Reference for Java
Table 38. Summary of Configuration properties and corresponding Connection and DataSource properties (continued)
Connection or DataSource property name:
com.ibm.db2.jcc.DB2BaseDataSource. ...
Configuration property name
Notes
db2.jcc.planName
planName
1, 4
db2.jcc.progressiveStreaming
progressiveStreaming
1, 4, 5, 6
db2.jcc.override.progressiveStreaming
progressiveStreaming
2, 4, 5, 6
db2.jcc.rollbackOnShutdown
4
db2.jcc.sendCharInputsUTF8
sendCharInputsUTF8
4
db2.jcc.sqljUncustomizedWarningOrException
db2.jcc.ssid
4, 6
ssid
1, 4
db2.jcc.traceDirectory
traceDirectory
1, 4, 5, 6
db2.jcc.override.traceDirectory
traceDirectory
2, 4, 5, 6
db2.jcc.traceFile
traceFile
1, 4, 5, 6
db2.jcc.override.traceFile
traceFile
2, 4, 5, 6
db2.jcc.traceFileAppend
traceFileAppend
1, 4, 5, 6
db2.jcc.override.traceFileAppend
traceFileAppend
2, 4, 5, 6
db2.jcc.traceLevel
traceLevel
1, 4, 5, 6
db2.jcc.override.traceLevel
traceLevel
2, 4, 5, 6
db2.jcc.tracePolling
4, 5, 6
db2.jcc.tracePollingInterval
4, 5, 6
db2.jcc.t2zosTraceFile
4
db2.jcc.t2zosTraceBufferSize
4
db2.jcc.t2zosTraceWrap
4
db2.jcc.useCcsid420ShapedConverter
4
Note:
1. The Connection or DataSource property setting overrides the configuration property setting. The configuration property provides
a default value for the Connection or DataSource property.
2. The configuration property setting overrides the Connection or DataSource property.
3. The corresponding Connection or DataSource property is defined only for IBM Informix.
4. The configuration property applies to DB2 for z/OS.
5. The configuration property applies to IBM Informix.
6. The configuration property applies to DB2 Database for Linux, UNIX, and Windows.
The meanings of the configuration properties are:
db2.jcc.accountingInterval
Specifies whether DB2 accounting records are produced at commit points or on
termination of the physical connection to the data source. If the value of
db2.jcc.accountingInterval is COMMIT, DB2 accounting records are produced at
commit points. For example:
db2.jcc.accountingInterval=COMMIT
Otherwise, accounting records are produced on termination of the physical
connection to the data source.
db2.jcc.accountingInterval applies only to IBM Data Server Driver for JDBC
and SQLJ type 2 connectivity on DB2 for z/OS. db2.jcc.accountingInterval is
not applicable to connections under CICS or IMS, or for Java stored
procedures.
Chapter 7. JDBC and SQLJ reference information
269
You can override db2.jcc.accountingInterval by setting the accountingInterval
property for a Connection or DataSource object.
This configuration property applies only to DB2 for z/OS.
db2.jcc.allowSqljDuplicateStaticQueries
Specifies whether multiple open iterators on a single SELECT statement in an
SQLJ application are allowed under IBM Data Server Driver for JDBC and
SQLJ type 2 connectivity.
To enable this support, set db2.jcc.allowSqljDuplicateStaticQueries to YES or
true.
db2.jcc.charOutputSize
Specifies the maximum number of bytes to use for INOUT or OUT stored
procedure parameters that are registered as Types.CHAR.
Because DESCRIBE information for stored procedure INOUT and OUT
parameters is not available at run time, by default, the IBM Data Server Driver
for JDBC and SQLJ sets the maximum length of each character INOUT or OUT
parameter to 32767. For stored procedures with many Types.CHAR parameters,
this maximum setting can result in allocation of much more storage than is
necessary.
To use storage more efficiently, set db2.jcc.charOutputSize to the largest
expected length for any Types.CHAR INOUT or OUT parameter.
db2.jcc.charOutputSize has no effect on INOUT or OUT parameters that are
registered as Types.VARCHAR or Types.LONGVARCHAR. The driver uses the default
length of 32767 for Types.VARCHAR and Types.LONGVARCHAR parameters.
The value that you choose for db2.jcc.charOutputSize needs to take into
account the possibility of expansion during character conversion. Because the
IBM Data Server Driver for JDBC and SQLJ has no information about the
server-side CCSID that is used for output parameter values, the driver requests
the stored procedure output data in UTF-8 Unicode. The
db2.jcc.charOutputSize value needs to be the maximum number of bytes that
are needed after the parameter value is converted to UTF-8 Unicode. UTF-8
Unicode characters can require up to three bytes. (The euro symbol is an
example of a three-byte UTF-8 character.) To ensure that the value of
db2.jcc.charOutputSize is large enough, if you have no information about the
output data, set db2.jcc.charOutputSize to three times the defined length of the
largest CHAR parameter.
This configuration property applies only to DB2 for z/OS.
db2.jcc.currentSchema or db2.jcc.override.currentSchema
Specifies the default schema name that is used to qualify unqualified database
objects in dynamically prepared SQL statements. This value of this property
sets the value in the CURRENT SCHEMA special register on the database
server. The schema name is case-sensitive, and must be specified in uppercase
characters.
This configuration property applies only to DB2 for z/OS or DB2 Database for
Linux, UNIX, and Windows.
db2.jcc.currentSQLID or db2.jcc.override.currentSQLID
Specifies:
v The authorization ID that is used for authorization checking on dynamically
prepared CREATE, GRANT, and REVOKE SQL statements.
270
Application Programming Guide and Reference for Java
v The owner of a table space, database, storage group, or synonym that is
created by a dynamically issued CREATE statement.
v The implicit qualifier of all table, view, alias, and index names specified in
dynamic SQL statements.
currentSQLID sets the value in the CURRENT SQLID special register on a DB2
for z/OS server. If the currentSQLID property is not set, the default schema
name is the value in the CURRENT SQLID special register.
This configuration property applies only to DB2 for z/OS.
db2.jcc.decimalRoundingMode or db2.jcc.override.decimalRoundingMode
Specifies the rounding mode for decimal or decimal floating-point values on
DB2 for z/OS or DB2 Database for Linux, UNIX, and Windows database
servers, and for decimal values on all other data sources that support the
decimal data type.
Possible values are:
com.ibm.db2.jcc.DB2BaseDataSource.ROUND_DOWN (1)
Rounds the value towards 0 (truncation). The discarded digits are
ignored.
com.ibm.db2.jcc.DB2BaseDataSource.ROUND_CEILING (2)
Rounds the value towards positive infinity. If all of the discarded digits
are zero or if the sign is negative the result is unchanged other than
the removal of the discarded digits. Otherwise, the result coefficient is
incremented by 1.
com.ibm.db2.jcc.DB2BaseDataSource.ROUND_HALF_EVEN (3)
Rounds the value to the nearest value; if the values are equidistant,
rounds the value so that the final digit is even. If the discarded digits
represents greater than half (0.5) of the value of one in the next left
position then the result coefficient is incremented by 1. If they
represent less than half, then the result coefficient is not adjusted (that
is, the discarded digits are ignored). Otherwise the result coefficient is
unaltered if its rightmost digit is even, or is incremented by 1 if its
rightmost digit is odd (to make an even digit).
com.ibm.db2.jcc.DB2BaseDataSource.ROUND_HALF_UP (4)
Rounds the value to the nearest value; if the values are equidistant,
rounds the value away from zero. If the discarded digits represent
greater than or equal to half (0.5) of the value of one in the next left
position then the result coefficient is incremented by 1. Otherwise the
discarded digits are ignored.
com.ibm.db2.jcc.DB2BaseDataSource.ROUND_FLOOR (6)
Rounds the value towards negative infinity. If all of the discarded
digits are zero or if the sign is positive the result is unchanged other
than the removal of discarded digits. Otherwise, the sign is negative
and the result coefficient is incremented by 1.
com.ibm.db2.jcc.DB2BaseDataSource.ROUND_UNSET (-2147483647)
No rounding mode was explicitly set. The IBM Data Server Driver for
JDBC and SQLJ does not use the decimalRoundingMode to set the
rounding mode on the data source.
The IBM Data Server Driver for JDBC and SQLJ uses the following
values for its rounding mode:
Chapter 7. JDBC and SQLJ reference information
271
v If the data source is DB2 for z/OS or DB2 Database for Linux,
UNIX, and Windows, the rounding mode is ROUND_HALF_EVEN
for decimal or decimal floating-point values.
v For any other data source, the rounding mode is ROUND_DOWN
for decimal values.
This configuration property applies only to DB2 for z/OS Version 9 or later, or
DB2 Database for Linux, UNIX, and Windows Version 9.1 or later.
db2.jcc.defaultSQLState
Specifies the SQLSTATE value that the IBM Data Server Driver for JDBC and
SQLJ returns to the client for SQLException or SQLWarning objects that have null
SQLSTATE values. This configuration property can be specified in the
following ways:
db2.jcc.defaultSQLState
If db2.jcc.defaultSQLState is specified with no value, the IBM Data
Server Driver for JDBC and SQLJ returns 'FFFFF'.
db2.jcc.defaultSQLState=xxxxx
xxxxx is the value that the IBM Data Server Driver for JDBC and SQLJ
returns when the SQLSTATE value is null. If xxxxx is longer than five
bytes, the driver truncates the value to five bytes. If xxxxx is shorter
than five bytes, the driver pads xxxxx on the right with blanks.
If db2.jcc.defaultSQLState is not specified, the IBM Data Server Driver for
JDBC and SQLJ returns a null SQLSTATE value.
This configuration property applies only to DB2 for z/OS.
db2.jcc.disableSQLJProfileCaching
Specifies whether serialized profiles are cached when the JVM under which
their application is running is reset. db2.jcc.disableSQLJProfileCaching applies
only to applications that run in a resettable JVM (applications that run in the
CICS, IMS, or Java stored procedure environment), and use IBM Data Server
Driver for JDBC and SQLJ type 2 connectivity on DB2 for z/OS. Possible
values are:
YES
SQLJ serialized profiles are not cached every time the JVM is reset, so
that new versions of the serialized profiles are loaded when the JVM is
reset. Use this option when an application is under development, and
new versions of the application and its serialized profiles are produced
frequently.
NO
SQLJ serialized profiles are cached when the JVM is reset. NO is the
default.
This configuration property applies only to DB2 for z/OS.
db2.jcc.dumpPool
Specifies the types of statistics on global transport pool events that are written,
in addition to summary statistics. The global transport pool is used for the
connection concentrator and Sysplex workload balancing.
db2.jcc.dumpPoolStatisticsOnSchedule and
db2.jcc.dumpPoolStatisticsOnScheduleFile must also be set for writing statistics
before any statistics are written.
You can specify one or more of the following types of statistics with the
db2.jcc.dumpPool property:
v DUMP_REMOVE_OBJECT (hexadecimal: X'01', decimal: 1)
v DUMP_GET_OBJECT (hexadecimal: X'02', decimal: 2)
272
Application Programming Guide and Reference for Java
v
v
v
v
v
DUMP_WAIT_OBJECT (hexadecimal: X'04', decimal: 4)
DUMP_SET_AVAILABLE_OBJECT (hexadecimal: X'08', decimal: 8)
DUMP_CREATE_OBJECT (hexadecimal: X'10', decimal: 16)
DUMP_SYSPLEX_MSG (hexadecimal: X'20', decimal: 32)
DUMP_POOL_ERROR (hexadecimal: X'80', decimal: 128)
To trace more than one type of event, add the values for the types of events
that you want to trace. For example, suppose that you want to trace
DUMP_GET_OBJECT and DUMP_CREATE_OBJECT events. The numeric
equivalents of these values are 2 and 16, so you specify 18 for the
db2.jcc.dumpPool value.
The default is 0, which means that only summary statistics for the global
transport pool are written.
This configuration property applies only to DB2 for z/OS or IBM Informix.
db2.jcc.dumpPoolStatisticsOnSchedule
Specifies how often, in seconds, global transport pool statistics are written to
the file that is specified by db2.jcc.dumpPoolStatisticsOnScheduleFile. The
global transport object pool is used for the connection concentrator and
Sysplex workload balancing.
The default is -1. -1 means that global transport pool statistics are not written.
This configuration property applies only to DB2 for z/OS or IBM Informix.
db2.jcc.dumpPoolStatisticsOnScheduleFile
Specifies the name of the file to which global transport pool statistics are
written. The global transport pool is used for the connection concentrator and
Sysplex workload balancing.
If db2.jcc.dumpPoolStatisticsOnScheduleFile is not specified, global transport
pool statistics are not written.
This configuration property applies only to DB2 for z/OS or IBM Informix.
db2.jcc.jmxEnabled
Specifies whether the Java Management Extensions (JMX) is enabled for the
IBM Data Server Driver for JDBC and SQLJ instance. JMX must be enabled
before applications can use the remote trace controller.
Possible values are:
true or yes
Indicates that JMX is enabled.
Any other value
Indicates that JMX is disabled. This is the default.
db2.jcc.lobOutputSize
Specifies the number of bytes of storage that the IBM Data Server Driver for
JDBC and SQLJ needs to allocate for output LOB values when the driver
cannot determine the size of those LOBs. This situation occurs for LOB stored
procedure output parameters. db2.jcc.lobOutputSize applies only to IBM Data
Server Driver for JDBC and SQLJ type 2 connectivity on DB2 for z/OS.
The default value for db2.jcc.lobOutputSize is 1048576. For systems with
storage limitations and smaller LOBs, set the db2.jcc.lobOutputSize value to a
lower number.
For example, if you know that the output LOB size is at most 64000, set
db2.jcc.lobOutputSize to 64000.
Chapter 7. JDBC and SQLJ reference information
273
This configuration property applies only to DB2 for z/OS.
db2.jcc.maxRefreshInterval
For workload balancing, specifies the maximum amount of time in seconds
between refreshes of the client copy of the server list. The default is 30. The
minimum valid value is 1.
db2.jcc.maxTransportObjectIdleTime
Specifies the amount of time in seconds that an unused transport object stays
in a global transport object pool before it can be deleted from the pool.
Transport objects are used for the connection concentrator and Sysplex
workload balancing.
The default value for db2.jcc.maxTransportObjectIdleTime is 60. Setting
db2.jcc.maxTransportObjectIdleTime to a value less than 0 causes unused
transport objects to be deleted from the pool immediately. Doing this is not
recommended because it can cause severe performance degradation.
This configuration property applies only to DB2 for z/OS or IBM Informix.
db2.jcc.maxTransportObjects
Specifies the upper limit for the number of transport objects in a global
transport object pool for the connection concentrator and Sysplex workload
balancing. When the number of transport objects in the pool reaches the
db2.jcc.maxTransportObjects value, transport objects that have not been used
for longer than the db2.jcc.maxTransportObjectIdleTime value are deleted from
the pool.
The default value for db2.jcc.maxTransportObjects is -1. Any value that is less
than or equal to 0 means that there is no limit to the number of transport
objects in the global transport object pool.
This configuration property applies only to DB2 for z/OS or IBM Informix.
db2.jcc.maxTransportObjectWaitTime
Specifies the maximum amount of time in seconds that an application waits for
a transport object if the db2.jcc.maxTransportObjects value has been reached.
Transport objects are used for the connection concentrator and Sysplex
workload balancing. When an application waits for longer than the
db2.jcc.maxTransportObjectWaitTime value, the global transport object pool
throws an SQLException.
The default value for db2.jcc.maxTransportObjectWaitTime is -1. Any negative
value means that applications wait forever.
This configuration property applies only to DB2 for z/OS or IBM Informix.
db2.jcc.minTransportObjects
Specifies the lower limit for the number of transport objects in a global
transport object pool for the connection concentrator and Sysplex workload
balancing. When a JVM is created, there are no transport objects in the pool.
Transport objects are added to the pool as they are needed. After the
db2.jcc.minTransportObjects value is reached, the number of transport objects
in the global transport object pool never goes below the
db2.jcc.minTransportObjects value for the lifetime of that JVM.
The default value for db2.jcc.minTransportObjects is 0. Any value that is less
than or equal to 0 means that the global transport object pool can become
empty.
This configuration property applies only to DB2 for z/OS or IBM Informix.
274
Application Programming Guide and Reference for Java
db2.jcc.outputDirectory
Specifies where the IBM Data Server Driver for JDBC and SQLJ stores
temporary log or cache files.
If this property is set, the IBM Data Server Driver for JDBC and SQLJ stores
the following files in the specified directory:
jccServerListCache.bin
Contains a copy of the primary and alternate server information for
automatic client reroute in a DB2 pureScale™ environment.
This file applies only to IBM Data Server Driver for JDBC and SQLJ
type 4 connectivity to DB2 Database for Linux, UNIX, and Windows.
If db2.jcc.outputDirectory is not specified, the IBM Data Server Driver
for JDBC and SQLJ searches for a directory that is specified by the
java.io.tmpdir system property. If the java.io.tmpdir system property is
also not specified, the driver uses only the in-memory cache for the
primary and alternate server information. If a directory is specified, but
jccServerListCache.bin cannot be accessed, the driver uses only the
in-memory cache for the server list.
jccdiag.log
Contains diagnostic information that is written by the IBM Data Server
Driver for JDBC and SQLJ.
If db2.jcc.outputDirectory is not specified, the IBM Data Server Driver
for JDBC and SQLJ searches for a directory that is specified by the
java.io.tmpdir system property. If the java.io.tmpdir system property is
also not specified, the driver does not write diagnostic information to
jccdiag.log. If a directory is specified, but jccdiag.log cannot be
accessed, the driver does not write diagnostic information to
jccdiag.log.
connlicj.bin
Contains information about IBM Data Server Driver for JDBC and
SQLJ license verification, for direct connections to DB2 for z/OS. The
IBM Data Server Driver for JDBC and SQLJ writes this file when server
license verification is performed successfully for a data server. When a
copy of the license verification information is stored at the client,
performance of license verification on subsequent connections can be
improved.
If db2.jcc.outputDirectory is not specified, the IBM Data Server Driver
for JDBC and SQLJ searches for a directory that is specified by the
java.io.tmpdir system property. If the java.io.tmpdir system property is
also not specified, the driver does not store a copy of server license
verification information at the client. If a directory is specified, but
connlicj.bin cannot be accessed, the driver does not store a copy of
server license verification information at the client.
The IBM Data Server Driver for JDBC and SQLJ does not create the directory.
You must create the directory and assign the required file permissions.
db2.jcc.outputDirectory can specify an absolute path or a relative path.
However, an absolute path is recommended.
db2.jcc.pkList
Specifies a package list that is used for the underlying RRSAF CREATE
THREAD call when a JDBC or SQLJ connection to a data source is established.
Chapter 7. JDBC and SQLJ reference information
275
Specify this property if you do not bind plans for your SQLJ programs or for
the JDBC driver. If you specify this property, do not specify db2.jcc.planName.
db2.jcc.pkList applies only to IBM Data Server Driver for JDBC and SQLJ type
2 connectivity on DB2 for z/OS. db2.jcc.pkList does not apply to applications
that run under CICS or IMS, or to Java stored procedures. The JDBC driver
ignores the db2.jcc.pkList setting in those cases.
Recommendation: Use db2.jcc.pkList instead of db2.jcc.planName.
The format of the package list is:
,
collection-ID.*
The default value of db2.jcc.pkList is NULLID.*.
If you specify the -collection parameter when you run
com.ibm.db2.jcc.DB2Binder, the collection ID that you specify for IBM Data
Server Driver for JDBC and SQLJ packages when you run
com.ibm.db2.jcc.DB2Binder must also be in the package list for the
db2.jcc.pkList property.
You can override db2.jcc.pkList by setting the pkList property for a Connection
or DataSource object.
The following example specifies a package list for a IBM Data Server Driver
for JDBC and SQLJ instance whose packages are in collection JDBCCID. SQLJ
applications that are prepared under this driver instance are bound into
collections SQLJCID1, SQLJCID2, or SQLJCID3.
db2.jcc.pkList=JDBCCID.*,SQLJCID1.*,SQLJCID2.*,SQLJCID3.*
This configuration property applies only to DB2 for z/OS.
db2.jcc.planName
Specifies a DB2 for z/OS plan name that is used for the underlying RRSAF
CREATE THREAD call when a JDBC or SQLJ connection to a data source is
established. Specify this property if you bind plans for your SQLJ programs
and for the JDBC driver packages. If you specify this property, do not specify
db2.jcc.pkList.
db2.jcc.planName applies only to IBM Data Server Driver for JDBC and SQLJ
type 2 connectivity on DB2 for z/OS. db2.jcc.planName does not apply to
applications that run under CICS or IMS, or to Java stored procedures. The
JDBC driver ignores the db2.jcc.planName setting in those cases.
If you do not specify this property or the db2.jcc.pkList property, the IBM Data
Server Driver for JDBC and SQLJ uses the db2.jcc.pkList default value of
NULLID.*.
If you specify db2.jcc.planName, you need to bind the packages that you
produce when you run com.ibm.db2.jcc.DB2Binder into a plan whose name is
the value of this property. You also need to bind all SQLJ packages into a plan
whose name is the value of this property.
You can override db2.jcc.planName by setting the planName property for a
Connection or DataSource object.
The following example specifies a plan name of MYPLAN for the IBM Data
Server Driver for JDBC and SQLJ JDBC packages and SQLJ packages.
276
Application Programming Guide and Reference for Java
db2.jcc.planName=MYPLAN
This configuration property applies only to DB2 for z/OS.
db2.jcc.progressiveStreaming or db2.jcc.override.progressiveStreaming
Specifies whether the JDBC driver uses progressive streaming when
progressive streaming is supported on the data source.
With progressive streaming, also known as dynamic data format, the data
source dynamically determines the most efficient mode in which to return LOB
or XML data, based on the size of the LOBs or XML objects.
Valid values are:
1
Use progressive streaming, if the data source supports it.
2
Do not use progressive streaming.
db2.jcc.rollbackOnShutdown
Specifies whether DB2 for z/OS forces a rollback operation and disables
further operations on JDBC connections that are in a unit of work during
processing of JVM shutdown hooks.
db2.jcc.rollbackOnShutdown applies to IBM Data Server Driver for JDBC and
SQLJ type 2 connectivity only.
db2.jcc.rollbackOnShutdown does not apply to the CICS, IMS, stored
procedure, or WebSphere Application Server environments.
Possible values are:
yes or true
The IBM Data Server Driver for JDBC and SQLJ directs DB2 for z/OS
to force a rollback operation and disables further operations on JDBC
connections that are in a unit of work during processing of JVM
shutdown hooks.
Any other value
The IBM Data Server Driver for JDBC and SQLJ takes no action with
respect to rollback processing during processing of JVM shutdown
hooks. This is the default.
This configuration property applies only to DB2 for z/OS.
db2.jcc.sendCharInputsUTF8
Specifies whether the IBM Data Server Driver for JDBC and SQLJ converts
character input data to the CCSID of the DB2 for z/OS database server, or
sends the data in UTF-8 encoding for conversion by the database server.
db2.jcc.sendCharInputsUTF8 applies to IBM Data Server Driver for JDBC and
SQLJ type 2 connectivity to DB2 for z/OS database servers only. If this
property is also set at the connection level, the connection-level setting
overrides this value.
Possible values are:
no, false, or 2
Specifies that the IBM Data Server Driver for JDBC and SQLJ converts
character input data to the target encoding before the data is sent to
the DB2 for z/OS database server. This is the default.
yes, true, or 1
Specifies that the IBM Data Server Driver for JDBC and SQLJ sends
Chapter 7. JDBC and SQLJ reference information
277
character input data to the DB2 for z/OS database server in UTF-8
encoding. The data source converts the data from UTF-8 encoding to
the target CCSID.
Specify yes, true, or 1 only if conversion to the target CCSID by the
SDK for Java causes character conversion problems. The most common
problem occurs when you use IBM Data Server Driver for JDBC and
SQLJ type 2 connectivity to insert a Unicode line feed character
(U+000A) into a table column that has CCSID 37, and then retrieve that
data from a non-z/OS client. If the SDK for Java does the conversion
during insertion of the character into the column, the line feed
character is converted to the EBCDIC new line character X'15'.
However, during retrieval, some SDKs for Java on operating systems
other than z/OS convert the X'15' character to the Unicode next line
character (U+0085) instead of the line feed character (U+000A). The
next line character causes unexpected behavior for some XML parsers.
If you set db2.jcc.sendCharInputsUTF8 to yes, the DB2 for z/OS
database server converts the U+000A character to the EBCDIC line feed
character X'25' during insertion into the column, so the character is
always retrieved as a line feed character.
Conversion of data to the target CCSID on the data source might cause
the IBM Data Server Driver for JDBC and SQLJ to use more memory
than conversion by the driver. The driver allocates memory for
conversion of character data from the source encoding to the encoding
of the data that it sends to the data source. The amount of space that
the driver allocates for character data that is sent to a table column is
based on the maximum possible length of the data. UTF-8 data can
require up to three bytes for each character. Therefore, if the driver
sends UTF-8 data to the data source, the driver needs to allocate three
times the maximum number of characters in the input data. If the
driver does the conversion, and the target CCSID is a single-byte
CCSID, the driver needs to allocate only the maximum number of
characters in the input data.
For example, any of the following settings for db2.jcc.sendCharInputsUTF8
causes the IBM Data Server Driver for JDBC and SQLJ to convert input
character strings to UTF-8, rather than the target encoding, before sending the
data to the data source:
db2.jcc.sendCharInputsUTF8=yes
db2.jcc.sendCharInputsUTF8=true
db2.jcc.sendCharInputsUTF8=1
This configuration property applies only to DB2 for z/OS.
db2.jcc.sqljUncustomizedWarningOrException
Specifies the action that the IBM Data Server Driver for JDBC and SQLJ takes
when an uncustomized SQLJ application runs.
db2.jcc.sqljUncustomizedWarningOrException can have the following values:
278
0
The IBM Data Server Driver for JDBC and SQLJ does not throw a
Warning or Exception when an uncustomized SQLJ application is run.
This is the default.
1
The IBM Data Server Driver for JDBC and SQLJ throws a Warning
when an uncustomized SQLJ application is run.
2
The IBM Data Server Driver for JDBC and SQLJ throws an Exception
when an uncustomized SQLJ application is run.
Application Programming Guide and Reference for Java
This configuration property applies only to DB2 for z/OS or DB2 Database for
Linux, UNIX, and Windows.
db2.jcc.traceDirectory or db2.jcc.override.traceDirectory
Enables the IBM Data Server Driver for JDBC and SQLJ trace for Java driver
code, and specifies a directory into which trace information is written. These
properties do not apply to IBM Data Server Driver for JDBC and SQLJ type 2
connectivity on DB2 for z/OS. When db2.jcc.override.traceDirectory is
specified, trace information for multiple connections on the same DataSource is
written to multiple files.
When db2.jcc.override.traceDirectory is specified, a connection is traced to a
file named file-name_origin_n.
v n is the nth connection for a DataSource.
v If neither db2.jcc.traceFileName nor db2.jcc.override.traceFileName is
specified, file-name is traceFile. If db2.jcc.traceFileName or
db2.jcc.override.traceFileName is also specified, file-name is the value of
db2.jcc.traceFileName or db2.jcc.override.traceFileName.
v origin indicates the origin of the log writer that is in use. Possible values of
origin are:
cpds
The log writer for a DB2ConnectionPoolDataSource object.
driver The log writer for a DB2Driver object.
global The log writer for a DB2TraceManager object.
sds
The log writer for a DB2SimpleDataSource object.
xads
The log writer for a DB2XADataSource object.
The db2.jcc.override.traceDirectory property overrides the traceDirectory
property for a Connection or DataSource object.
For example, specifying the following setting for db2.jcc.override.traceDirectory
enables tracing of the IBM Data Server Driver for JDBC and SQLJ Java code to
files in a directory named /SYSTEM/tmp:
db2.jcc.override.traceDirectory=/SYSTEM/tmp
You should set the trace properties under the direction of IBM Software
Support.
db2.jcc.traceLevel or db2.jcc.override.traceLevel
Specifies what to trace.
The db2.jcc.override.traceLevel property overrides the traceLevel property for
a Connection or DataSource object.
You specify one or more trace levels by specifying a decimal value. The trace
levels are the same as the trace levels that are defined for the traceLevel
property on a Connection or DataSource object.
To specify more than one trace level, do an OR (|) operation on the values,
and specify the result in decimal in the db2.jcc.traceLevel or
db2.jcc.override.traceLevel specification.
For example, suppose that you want to specify TRACE_DRDA_FLOWS and
TRACE_CONNECTIONS for db2.jcc.override.traceLevel.
TRACE_DRDA_FLOWS has a hexadecimal value of X'40'.
TRACE_CONNECTION_CALLS has a hexadecimal value of X'01'. To specify
both traces, do a bitwise OR operation on the two values, which results in
X'41'. The decimal equivalent is 65, so you specify:
Chapter 7. JDBC and SQLJ reference information
279
db2.jcc.override.traceLevel=65
db2.jcc.ssid
Specifies the DB2 for z/OS subsystem to which applications make connections
with IBM Data Server Driver for JDBC and SQLJ type 2 connectivity on DB2
for z/OS.
The db2.jcc.ssid value can be the name of the local DB2 subsystem or a group
attachment name or subgroup attachment name.
For example:
db2.jcc.ssid=DB2A
The ssid Connection and DataSource property overrides db2.jcc.ssid.
If you specify a group attachment name or subgroup attachment name, and the
DB2 subsystem to which an application is connected fails, the connection
terminates. However, when new connections use that group attachment name
or subgroup attachment name, DB2 for z/OS uses group attachment or
subgroup attachment processing to find an active DB2 subsystem to which to
connect.
If you do not specify the db2.jcc.ssid property, the IBM Data Server Driver for
JDBC and SQLJ uses the SSID value from the application defaults load module.
When you install DB2 for z/OS, an application defaults load module is created
in the prefix.SDSNEXIT data set and the prefix.SDSNLOAD data set. Other
application defaults load modules might be created in other data sets for
selected applications.
The IBM Data Server Driver for JDBC and SQLJ must load an application
defaults load module before it can read the SSID value. z/OS searches data
sets in the following places, and in the following order, for the application
defaults load module:
1. Job pack area (JPA)
2. TASKLIB
3. STEPLIB or JOBLIB
4. LPA
5. Libraries in the link list
You need to ensure that if your system has more than one copy of the
application defaults load module, z/OS finds the data set that contains the
correct copy for the IBM Data Server Driver for JDBC and SQLJ first.
This configuration property applies only to DB2 for z/OS.
db2.jcc.traceFile or db2.jcc.override.traceFile
Enables the IBM Data Server Driver for JDBC and SQLJ trace for Java driver
code, and specifies the name on which the trace file names are based.The
db2.jcc.traceFile property does not apply to IBM Data Server Driver for JDBC
and SQLJ type 2 connectivity on DB2 for z/OS.
Specify a fully qualified z/OS UNIX System Services file name for the
db2.jcc.override.traceFile property value.
The db2.jcc.override.traceFile property overrides the traceFile property for a
Connection or DataSource object.
For example, specifying the following setting for db2.jcc.override.traceFile
enables tracing of the IBM Data Server Driver for JDBC and SQLJ Java code to
a file named /SYSTEM/tmp/jdbctrace:
db2.jcc.override.traceFile=/SYSTEM/tmp/jdbctrace
280
Application Programming Guide and Reference for Java
You should set the trace properties under the direction of IBM Software
Support.
db2.jcc.traceFileAppend or db2.jcc.override.traceFileAppend
Specifies whether to append to or overwrite the file that is specified by the
db2.jcc.override.traceFile property. These properties do not apply to IBM Data
Server Driver for JDBC and SQLJ type 2 connectivity on DB2 for z/OS. Valid
values are true or false. The default is false, which means that the file that is
specified by the traceFile property is overwritten.
The db2.jcc.override.traceFileAppend property overrides the traceFileAppend
property for a Connection or DataSource object.
For example, specifying the following setting for
db2.jcc.override.traceFileAppend causes trace data to be added to the existing
trace file:
db2.jcc.override.traceFileAppend=true
You should set the trace properties under the direction of IBM Software
Support.
db2.jcc.tracePolling
Indicates whether the IBM Data Server Driver for JDBC and SQLJ polls the
global configuration file for changes in trace directives and modifies the trace
behavior to match the new trace directives. Possible values are true or false.
False is the default.
The IBM Data Server Driver for JDBC and SQLJ modifies the trace behavior at
the beginning of the next polling interval after the configuration properties file
is changed. If db2.jcc.tracePolling is set to true while an application is running,
the trace is enabled, and information about all the PreparedStatement objects
that were created by the application before the trace was enabled are dumped
to the trace destination.
db2.jcc.tracePolling polls the following global configuration properties:
v db2.jcc.override.traceLevel
v db2.jcc.override.traceFile
v db2.jcc.override.traceDirectory
v db2.jcc.override.traceFileAppend
v db2.jcc.t2zosTraceFile
v db2.jcc.t2zosTraceBufferSize
v db2.jcc.t2zosTraceWrap
db2.jcc.tracePollingInterval
Specifies the interval, in seconds, for polling the IBM Data Server Driver for
JDBC and SQLJ global configuration file for changes in trace directives. The
property value is a positive integer. The default is 60. For the specified trace
polling interval to be used, the db2.jcc.tracePollingInterval property must be
set before the driver is loaded and initialized. Changes to
db2.jcc.tracePollingInterval after the driver is loaded and initialized have no
effect.
db2.jcc.t2zosTraceFile
Enables the IBM Data Server Driver for JDBC and SQLJ trace for C/C++ native
driver code for IBM Data Server Driver for JDBC and SQLJ type 2 connectivity,
and specifies the name on which the trace file names are based. This property
is required for collecting trace data for C/C++ native driver code.
Specify a fully qualified z/OS UNIX System Services file name for the
db2.jcct.t2zosTraceFile property value.
Chapter 7. JDBC and SQLJ reference information
281
For example, specifying the following setting for db2.jcct.t2zosTraceFile enables
tracing of the IBM Data Server Driver for JDBC and SQLJ C/C++ native code
to a file named /SYSTEM/tmp/jdbctraceNative:
db2.jcc.t2zosTraceFile=/SYSTEM/tmp/jdbctraceNative
You should set the trace properties under the direction of IBM Software
Support.
This configuration property applies only to DB2 for z/OS.
db2.jcc.t2zosTraceBufferSize
Specifies the size, in kilobytes, of a trace buffer in virtual storage that is used
for tracing the processing that is done by the C/C++ native driver code. This
value is also the maximum amount of C/C++ native driver trace information
that can be collected.
Specify an integer between 64 (64 KB) and 4096 (4096 KB). The default is 256
(256 KB).
The JDBC driver determines the trace buffer size as shown in the following
table:
Specified value (n)
Trace buffer size (KB)
<64
64
64<=n<128
64
128<=n<256
128
256<=n<512
256
512<=n<1024
512
1024<=n<2048
1024
2048<=n<4096
2048
n>=4096
4096
db2.jcc.t2zosTraceBufferSize is used only if the db2.jcc.t2zosTraceFile property
is set.
Recommendation: To avoid a performance impact, specify a value of 1024 or
less.
For example, to set a trace buffer size of 1024 KB, use this setting:
db2.jcc.t2zosTraceBufferSize=1024
You should set the trace properties under the direction of IBM Software
Support.
This configuration property applies only to DB2 for z/OS.
db2.jcc.t2zosTraceWrap
Enables or disables wrapping of the SQLJ trace. db2.jcc.t2zosTraceWrap can
have one of the following values:
1
Wrap the trace
0
Do not wrap the trace
The default is 1. This parameter is optional. For example:
DB2SQLJ_TRACE_WRAP=0
282
Application Programming Guide and Reference for Java
You should set db2.jcc.t2zosTraceWrap only under the direction of IBM
Software Support.
This configuration property applies only to DB2 for z/OS.
db2.jcc.useCcsid420ShapedConverter
Specifies whether Arabic character data that is in EBCDIC CCSID 420 maps to
Cp420S encoding.
db2.jcc.useCcsid420ShapedConverter applies only to connections to DB2 for
z/OS database servers.
If the value of db2.jcc.useCcsid420ShapedConverter is true, CCSID 420 maps
to Cp420S encoding. If the value of db2.jcc.useCcsid420ShapedConverter is
false, CCSID 420 maps to Cp420 encoding. false is the default.
This configuration property applies only to DB2 for z/OS.
Related concepts
“Customization of IBM Data Server Driver for JDBC and SQLJ configuration
properties” on page 476
Driver support for JDBC APIs
The JDBC drivers that are supported by DB2 and IBM Informix database systems
have different levels of support for JDBC methods.
The following tables list the JDBC interfaces and indicate which drivers supports
them. The drivers and their supported platforms are:
Table 39. JDBC drivers for DB2 and IBM Informix database systems
JDBC driver name
Associated data source
IBM Data Server Driver for JDBC and SQLJ
DB2 Database for Linux, UNIX, and
Windows, DB2 for z/OS, or IBM Informix
IBM Informix JDBC Driver (IBM Informix
JDBC Driver)
IBM Informix
If a method has JDBC 2.0 and JDBC 3.0 forms, the IBM Data Server Driver for
JDBC and SQLJ supports all forms. The DB2 JDBC Type 2 Driver for Linux, UNIX
and Windows supports only the JDBC 2.0 forms.
Table 40. Support for Array methods
JDBC method
IBM Data Server
Driver for JDBC and
SQLJ1 support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
free2
Yes
No
No
getArray
Yes
No
Yes
getBaseType
Yes
No
Yes
getBaseTypeName
Yes
No
Yes
getResultSet
Yes
No
Yes
Notes:
1. Under the IBM Data Server Driver for JDBC and SQLJ, Array methods are supported for connections to DB2
Database for Linux, UNIX, and Windows data sources only.
2. This is a JDBC 4.0 method.
Chapter 7. JDBC and SQLJ reference information
283
Table 41. Support for BatchUpdateException methods
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
Methods inherited from
java.lang.Exception
Yes
Yes
Yes
getUpdateCounts
Yes
Yes
Yes
JDBC method
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
free1
Yes
No
No
Yes
Yes
JDBC method
Table 42. Support for Blob methods
2
getBinaryStream
Yes
getBytes
Yes
Yes
Yes
length
Yes
Yes
Yes
Yes
Yes
Yes
position
Yes
No
No
3
Yes
No
No
3
Yes
No
No
setBinaryStream
setBytes
3
truncate
Notes:
1. This is a JDBC 4.0 method.
2. Supported forms of this method include the following JDBC 4.0 form:
getBinaryStream(long pos, long length)
3. For versions of the IBM Data Server Driver for JDBC and SQLJ before version 3.50, these methods cannot be used
if a Blob is passed to a stored procedure as an IN or INOUT parameter, and the methods are used on the Blob in
the stored procedure.
Table 43. Support for CallableStatement methods
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
Methods inherited from
java.sql.Statement
Yes
Yes
Yes
Methods inherited from
java.sql.PreparedStatement
Yes1
Yes
Yes
getArray
No
JDBC method
getBigDecimal
getBlob
getBoolean
getByte
getBytes
getClob
getDate
getDouble
getFloat
284
No
No
Yes
3
Yes
Yes
Yes
3
Yes
Yes
Yes
3
Yes
Yes
Yes
3
Yes
Yes
Yes
3
Yes
Yes
Yes
3
Yes
Yes
Yes
3,4
Yes
Yes
Yes
3
Yes
Yes
Yes
3
Yes
Yes
Application Programming Guide and Reference for Java
4
Table 43. Support for CallableStatement methods (continued)
JDBC method
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
getInt
Yes3
Yes
Yes
Yes
3
Yes
Yes
Yes
3,5
getLong
getObject
getRef
No
2
Yes
Yes
No
No
No
No
Yes
3
Yes
Yes
Yes
3
Yes
Yes
Yes
3,4
getTimestamp
Yes
3,4
getURL
Yes
getRowId
getShort
getString
getTime
Yes
5
4
Yes
4
Yes
Yes
No
No
Yes
registerOutParameter
Yes
6
Yes
Yes6
setAsciiStream
Yes7
No
Yes
Yes
7
No
Yes
Yes
7
No
Yes
Yes
7
No
Yes
Yes
7
No
Yes
Yes
7
No
Yes
Yes
7
No
Yes
Yes
7
No
Yes
Yes
7
No
Yes
setFloat
Yes
7
No
Yes
setInt
Yes7
No
Yes
setLong
Yes7
No
Yes
setNull
Yes7,,8
No
Yes
setObject
Yes7,
No
Yes
setShort
Yes7
No
Yes
setString
Yes7
No
Yes
setTime
Yes7
No
Yes
7
No
Yes
setBigDecimal
setBinaryStream
setBoolean
setByte
setBytes
setCharacterStream
setDate
setDouble
6
setTimestamp
Yes
setURL
Yes
No
No
wasNull
Yes
Yes
Yes
Chapter 7. JDBC and SQLJ reference information
285
Table 43. Support for CallableStatement methods (continued)
IBM Data Server
Driver for JDBC and
SQLJ support
JDBC method
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
Notes:
1. The inherited getParameterMetaData method is not supported if the data source is DB2 for z/OS.
2. This is a JDBC 4.0 method.
3. The following forms of CallableStatement.getXXX methods are not supported if the data source is DB2 for z/OS:
getXXX(String parameterName)
4. The database server does no timezone adjustment for datetime values. The JDBC driver adjusts a value for the
local timezone after retrieving the value from the server if you specify a form of the getDate, getTime, or
getTimestamp method that includes a java.util.Calendar parameter.
5. The following form of the getObject method is not supported:
getObject(int parameterIndex, java.util.Map
map)
6. The following form of the registerOutParameter method is not supported:
registerOutParameter(int parameterIndex, int jdbcType, String typeName)
7. The following forms of CallableStatement.setXXX methods are not supported if the data source is DB2 for z/OS:
setXXX(String parameterName,...)
8. The following form of setNull is not supported:
setNull(int parameterIndex, int jdbcType, String typeName)
Table 44. Support for Clob methods
JDBC method
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
free1
Yes
No
No
getAsciiStream
Yes
Yes
Yes
getCharacterStream
Yes2
Yes
Yes
getSubString
Yes
Yes
Yes
length
Yes
Yes
Yes
Yes
Yes
Yes
Yes
No
Yes
Yes
No
Yes
Yes
No
Yes
Yes
No
Yes
position
setAsciiStream
3
setCharacterStream
setString
truncate
3
3
3
Notes:
1. This is a JDBC 4.0 method.
2. Supported forms of this method include the following JDBC 4.0 form:
getCharacterStream(long pos, long length)
3. For versions of the IBM Data Server Driver for JDBC and SQLJ before version 3.50, these methods cannot be used
if a Clob is passed to a stored procedure as an IN or INOUT parameter, and the methods are used on the Clob in
the stored procedure.
286
Application Programming Guide and Reference for Java
Table 45. Support for Connection methods
JDBC method
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
clearWarnings
Yes
Yes
Yes
close
Yes
Yes
Yes
commit
createBlob
Yes
Yes
Yes
1
Yes
No
No
1
Yes
No
createClob
No
2
Yes
createStatement
Yes
Yes
getAutoCommit
Yes
Yes
Yes
getCatalog
Yes
Yes
Yes
Yes
No
No
getHoldability
Yes
No
No
getMetaData
Yes
Yes
Yes
getTransactionIsolation
Yes
Yes
Yes
getTypeMap
No
No
Yes
getWarnings
Yes
Yes
Yes
isClosed
Yes
Yes
Yes
isReadOnly
Yes
Yes
Yes
Yes
No
No
Yes
Yes
Yes
getClientInfo
isValid
1
1,3
nativeSQL
prepareCall
Yes
4
Yes
2
Yes
Yes
prepareStatement
Yes
Yes
releaseSavepoint
Yes
No
No
rollback
Yes
Yes2
Yes
setAutoCommit
Yes
Yes
Yes
setCatalog
Yes
Yes
No
setClientInfo1
Yes
No
No
setReadOnly
Yes5
Yes
No
setSavepoint
Yes
No
No
setTransactionIsolation
Yes
Yes
Yes
setTypeMap
No
No
Yes
Notes:
1. This is a JDBC 4.0 method.
2. The DB2 JDBC Type 2 Driver for Linux, UNIX and Windows does not support the JDBC 3.0 forms of this method.
3. Under IBM Data Server Driver for JDBC and SQLJ type 4 connectivity, an SQLException is thrown if the timeout
parameter value is less than 0. Under IBM Data Server Driver for JDBC and SQLJ type 2 connectivity, an
SQLException is thrown if the if the timeout parameter value is not 0.
4. If the stored procedure in the CALL statement is on DB2 for z/OS, the parameters of the CALL statement cannot
be expressions.
5. The driver does not use the setting. For the IBM Data Server Driver for JDBC and SQLJ, a connection can be set
as read-only through the readOnly property for a Connection or DataSource object.
Chapter 7. JDBC and SQLJ reference information
287
Table 46. Support for ConnectionEvent methods
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
Methods inherited from
java.util.EventObject
Yes
Yes
Yes
getSQLException
Yes
Yes
Yes
JDBC method
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
connectionClosed
Yes
Yes
Yes
connectionErrorOccurred
Yes
Yes
Yes
JDBC method
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
getLoginTimeout
Yes
Yes
Yes
getLogWriter
Yes
Yes
Yes
getPooledConnection
Yes
Yes
Yes
Yes
Yes
Yes
Yes
JDBC method
Table 47. Support for ConnectionEventListener methods
Table 48. Support for ConnectionPoolDataSource methods
setLoginTimeout
Yes
setLogWriter
Yes
1
Note:
1. This method is not supported for IBM Data Server Driver for JDBC and SQLJ type 2 connectivity on DB2 for
z/OS.
Table 49. Support for DatabaseMetaData methods
JDBC method
IBM Data
Server Driver
for JDBC and
SQLJ support
DB2 JDBC
Type 2 Driver
for Linux,
UNIX and
Windows
support
IBM Informix
JDBC Driver
support
allProceduresAreCallable
Yes
Yes
Yes
Yes
Yes1
1
allTablesAreSelectable
Yes
dataDefinitionCausesTransactionCommit
Yes
Yes
Yes
dataDefinitionIgnoredInTransactions
Yes
Yes
Yes
deletesAreDetected
Yes
Yes
Yes
doesMaxRowSizeIncludeBlobs
Yes
Yes
Yes
No
No
2
getAttributes
Yes
getBestRowIdentifier
Yes
Yes
Yes
getCatalogs
Yes
Yes
Yes
getCatalogSeparator
Yes
Yes
Yes
Yes
Yes
Yes
Yes
No
No
getCatalogTerm
getClientInfoProperties
288
6
Application Programming Guide and Reference for Java
Table 49. Support for DatabaseMetaData methods (continued)
JDBC method
IBM Data
Server Driver
for JDBC and
SQLJ support
DB2 JDBC
Type 2 Driver
for Linux,
UNIX and
Windows
support
IBM Informix
JDBC Driver
support
getColumnPrivileges
Yes
Yes
Yes
7
getColumns
Yes
Yes
Yes10
getConnection
Yes
Yes
Yes
getCrossReference
Yes
Yes
Yes
getDatabaseMajorVersion
Yes
No
No
getDatabaseMinorVersion
Yes
No
No
getDatabaseProductName
Yes
Yes
Yes
getDatabaseProductVersion
Yes
Yes
Yes
getDefaultTransactionIsolation
Yes
Yes
Yes
getDriverMajorVersion
Yes
Yes
Yes
getDriverMinorVersion
Yes
Yes
Yes
Yes
Yes
8
10
getDriverName
Yes
getDriverVersion
Yes
Yes
Yes
Yes
Yes
Yes
Yes
No
No
Yes
No
No
getExtraNameCharacters
Yes
Yes
Yes
getIdentifierQuoteString
Yes
Yes
Yes
getImportedKeys
Yes
Yes
Yes
getIndexInfo
Yes
Yes
Yes
getJDBCMajorVersion
Yes
No
No
getJDBCMinorVersion
Yes
No
No
getMaxBinaryLiteralLength
Yes
Yes
Yes
getMaxCatalogNameLength
Yes
Yes
Yes
getMaxCharLiteralLength
Yes
Yes
Yes
getMaxColumnNameLength
Yes
Yes
Yes
getMaxColumnsInGroupBy
Yes
Yes
Yes
getMaxColumnsInIndex
Yes
Yes
Yes
getMaxColumnsInOrderBy
Yes
Yes
Yes
getMaxColumnsInSelect
Yes
Yes
Yes
getMaxColumnsInTable
Yes
Yes
Yes
getMaxConnections
Yes
Yes
Yes
getMaxCursorNameLength
Yes
Yes
Yes
getMaxIndexLength
Yes
Yes
Yes
getMaxProcedureNameLength
Yes
Yes
Yes
getMaxRowSize
Yes
Yes
Yes
getExportedKeys
getFunctionColumns
getFunctions
6
6
Chapter 7. JDBC and SQLJ reference information
289
Table 49. Support for DatabaseMetaData methods (continued)
JDBC method
IBM Data
Server Driver
for JDBC and
SQLJ support
DB2 JDBC
Type 2 Driver
for Linux,
UNIX and
Windows
support
IBM Informix
JDBC Driver
support
getMaxSchemaNameLength
Yes
Yes
Yes
getMaxStatementLength
Yes
Yes
Yes
getMaxStatements
Yes
Yes
Yes
getMaxTableNameLength
Yes
Yes
Yes
getMaxTablesInSelect
Yes
Yes
Yes
getMaxUserNameLength
Yes
Yes
Yes
getNumericFunctions
Yes
Yes
Yes
getPrimaryKeys
Yes
Yes
Yes
getProcedureColumns
Yes7 on page
293
Yes
Yes
getProcedures
Yes7 on page
293
Yes
Yes
getProcedureTerm
Yes
Yes
Yes
getResultSetHoldability
Yes
No
No
Yes
No
getRowIdLifetime
6
No
getSchemas
Yes9 on page
293
Yes
Yes10
getSchemaTerm
Yes
Yes
Yes
getSearchStringEscape
Yes
Yes
Yes
getSQLKeywords
Yes
Yes
Yes
getSQLStateType
Yes
No
No
getStringFunctions
Yes
getSuperTables
10
Yes
Yes
2
No
No
2
No
No
Yes
Yes
getSuperTypes
Yes
getSystemFunctions
Yes
Yes
getTablePrivileges
Yes
Yes
Yes
10
Yes10
getTables
Yes
Yes
getTableTypes
Yes
Yes
Yes
getTimeDateFunctions
Yes
Yes
Yes
getTypeInfo
Yes
Yes
Yes
getUDTs
No
Yes
Yes11
getURL
Yes
Yes
Yes
getUserName
Yes
Yes
Yes
getVersionColumns
Yes
Yes
Yes
insertsAreDetected
Yes
Yes
Yes
isCatalogAtStart
Yes
Yes
Yes
isReadOnly
Yes
Yes
Yes
290
Application Programming Guide and Reference for Java
11
Table 49. Support for DatabaseMetaData methods (continued)
JDBC method
IBM Data
Server Driver
for JDBC and
SQLJ support
DB2 JDBC
Type 2 Driver
for Linux,
UNIX and
Windows
support
IBM Informix
JDBC Driver
support
locatorsUpdateCopy
Yes3
Yes
Yes3
nullPlusNonNullIsNull
Yes
Yes
Yes
Yes
Yes4
nullsAreSortedAtEnd
Yes
nullsAreSortedAtStart
Yes
4
Yes
Yes
nullsAreSortedHigh
Yes
5
Yes
Yes5
nullsAreSortedLow
Yes1
Yes
Yes1
othersDeletesAreVisible
Yes
Yes
Yes
othersInsertsAreVisible
Yes
Yes
Yes
othersUpdatesAreVisible
Yes
Yes
Yes
ownDeletesAreVisible
Yes
Yes
Yes
ownInsertsAreVisible
Yes
Yes
Yes
ownUpdatesAreVisible
Yes
Yes
Yes
storesLowerCaseIdentifiers
Yes
1
Yes
Yes1
storesLowerCaseQuotedIdentifiers
Yes4
Yes
Yes4
storesMixedCaseIdentifiers
Yes
Yes
Yes
storesMixedCaseQuotedIdentifiers
Yes
Yes
Yes
Yes
Yes5
Yes
Yes
Yes
Yes
Yes
Yes1
storesUpperCaseIdentifiers
Yes
storesUpperCaseQuotedIdentifiers
Yes
supportsAlterTableWithAddColumn
Yes
5
1
supportsAlterTableWithDropColumn
Yes
supportsANSI92EntryLevelSQL
Yes
Yes
Yes
supportsANSI92FullSQL
Yes
Yes
Yes
supportsANSI92IntermediateSQL
Yes
Yes
Yes
supportsBatchUpdates
Yes
Yes
Yes
Yes
Yes1
Yes
Yes
Yes
Yes
Yes
Yes1
supportsCatalogsInDataManipulation
Yes
supportsCatalogsInIndexDefinitions
Yes
supportsCatalogsInPrivilegeDefinitions
Yes
1
1
supportsCatalogsInProcedureCalls
Yes
supportsCatalogsInTableDefinitions
Yes
Yes
Yes
SupportsColumnAliasing
Yes
Yes
Yes
supportsConvert
Yes
Yes
Yes
supportsCoreSQLGrammar
Yes
Yes
Yes
supportsCorrelatedSubqueries
Yes
Yes
Yes
supportsDataDefinitionAndDataManipulationTransactions
Yes
Yes
Yes
supportsDataManipulationTransactionsOnly
Yes
Yes
Yes
Yes
Yes4
supportsDifferentTableCorrelationNames
Yes
4
Chapter 7. JDBC and SQLJ reference information
291
Table 49. Support for DatabaseMetaData methods (continued)
JDBC method
IBM Data
Server Driver
for JDBC and
SQLJ support
DB2 JDBC
Type 2 Driver
for Linux,
UNIX and
Windows
support
IBM Informix
JDBC Driver
support
supportsExpressionsInOrderBy
Yes
Yes
Yes
supportsExtendedSQLGrammar
Yes
Yes
Yes
Yes
Yes3
3
supportsFullOuterJoins
Yes
supportsGetGeneratedKeys
Yes
No
No
supportsGroupBy
Yes
Yes
Yes
supportsGroupByBeyondSelect
Yes
Yes
Yes
supportsGroupByUnrelated
Yes
Yes
Yes
supportsIntegrityEnhancementFacility
Yes
Yes
Yes
supportsLikeEscapeClause
Yes
Yes
Yes
supportsLimitedOuterJoins
Yes
Yes
Yes
supportsMinimumSQLGrammar
Yes
Yes
Yes
supportsMixedCaseIdentifiers
Yes
Yes
Yes
supportsMixedCaseQuotedIdentifiers
Yes
3
Yes
Yes3
supportsMultipleOpenResults
Yes5
No
Yes5
supportsMultipleResultSets
Yes5
Yes
Yes5
supportsMultipleTransactions
Yes
Yes
Yes
supportsNamedParameters
Yes
No
No
supportsNonNullableColumns
Yes
Yes
Yes
Yes
Yes3
supportsOpenCursorsAcrossCommit
Yes
supportsOpenCursorsAcrossRollback
Yes
3
Yes
Yes
supportsOpenStatementsAcrossCommit
Yes
3
Yes
Yes3
supportsOpenStatementsAcrossRollback
Yes3
Yes
Yes3
supportsOrderByUnrelated
Yes
Yes
Yes
supportsOuterJoins
Yes
Yes
Yes
supportsPositionedDelete
Yes
Yes
Yes
supportsPositionedUpdate
Yes
Yes
Yes
supportsResultSetConcurrency
Yes
Yes
Yes
supportsResultSetHoldability
Yes
No
No
supportsResultSetType
Yes
Yes
Yes
supportsSavepoints
Yes
No
Yes
supportsSchemasInDataManipulation
Yes
Yes
Yes
supportsSchemasInIndexDefinitions
Yes
Yes
Yes
supportsSchemasInPrivilegeDefinitions
Yes
Yes
Yes
supportsSchemasInProcedureCalls
Yes
Yes
Yes
supportsSchemasInTableDefinitions
Yes
Yes
Yes
supportsSelectForUpdate
Yes
Yes
Yes
292
Application Programming Guide and Reference for Java
Table 49. Support for DatabaseMetaData methods (continued)
JDBC method
IBM Data
Server Driver
for JDBC and
SQLJ support
DB2 JDBC
Type 2 Driver
for Linux,
UNIX and
Windows
support
IBM Informix
JDBC Driver
support
supportsStoredProcedures
Yes
Yes
Yes
supportsSubqueriesInComparisons
Yes
Yes
Yes
supportsSubqueriesInExists
Yes
Yes
Yes
supportsSubqueriesInIns
Yes
Yes
Yes
supportsSubqueriesInQuantifieds
Yes
Yes
Yes
supportsSuperTables
Yes
No
No
supportsSuperTypes
Yes
No
No
supportsTableCorrelationNames
Yes
Yes
Yes
supportsTransactionIsolationLevel
Yes
Yes
Yes
supportsTransactions
Yes
Yes
Yes
supportsUnion
Yes
Yes
Yes
supportsUnionAll
Yes
Yes
Yes
updatesAreDetected
Yes
Yes
Yes
usesLocalFilePerTable
Yes
Yes
Yes
usesLocalFiles
Yes
Yes
Yes
Notes:
1. DB2 data sources return false for this method. IBM Informix data sources return true.
2. This method is supported for connections to DB2 Database for Linux, UNIX, and Windows and IBM Informix
only.
3. Under the IBM Data Server Driver for JDBC and SQLJ, DB2 data sources and IBM Informix data sources return
true for this method. Under the IBM Informix JDBC Driver, IBM Informix data sources return false.
4. Under the IBM Data Server Driver for JDBC and SQLJ, DB2 data sources and IBM Informix data sources return
false for this method. Under the IBM Informix JDBC Driver, IBM Informix data sources return true.
5. DB2 data sources return true for this method. IBM Informix data sources return false.
6. This is a JDBC 4.0 method.
7. This method returns the additional column that is described by the JDBC 4.0 specification.
8. JDBC 3.0 and earlier implementations of the IBM Data Server Driver for JDBC and SQLJ return "IBM DB2 JDBC
Universal Driver Architecture."
The JDBC 4.0 implementation of the IBM Data Server Driver for JDBC and SQLJ returns "IBM Data Server
Driver for JDBC and SQLJ."
9. The JDBC 4.0 form and previous forms of this method are supported.
10. The DB2 JDBC Type 2 Driver for Linux, UNIX and Windows does not support the JDBC 3.0 form of this
method.
11. The method can be executed, but it returns an empty ResultSet.
Table 50. Support for DataSource methods
JDBC method
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
getConnection
Yes
Yes
Yes
getLoginTimeout
Yes
Yes
1
Yes
Chapter 7. JDBC and SQLJ reference information
293
Table 50. Support for DataSource methods (continued)
JDBC method
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
getLogWriter
Yes
Yes
Yes
setLoginTimeout
Yes
setLogWriter
Yes
2
1
Yes
Yes
Yes
Yes
Notes:
1. The DB2 JDBC Type 2 Driver does not use this setting.
2. This method is not supported for IBM Data Server Driver for JDBC and SQLJ type 2 connectivity on DB2 for
z/OS.
Table 51. Support for DataTruncation methods
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
Methods inherited from
java.lang.Throwable
Yes
Yes
Yes
Methods inherited from
java.sql.SQLException
Yes
Yes
Yes
Methods inherited from
java.sql.SQLWarning
Yes
Yes
Yes
getDataSize
Yes
Yes
Yes
getIndex
Yes
Yes
Yes
getParameter
Yes
Yes
Yes
getRead
Yes
Yes
Yes
getTransferSize
Yes
Yes
Yes
JDBC method
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
acceptsURL
Yes
Yes
Yes
connect
Yes
Yes
Yes
getMajorVersion
Yes
Yes
Yes
getMinorVersion
Yes
Yes
Yes
getPropertyInfo
Yes
Yes
Yes
jdbcCompliant
Yes
Yes
Yes
JDBC method
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
deregisterDriver
Yes
Yes
Yes
getConnection
Yes
Yes
Yes
getDriver
Yes
Yes
Yes
JDBC method
Table 52. Support for Driver methods
Table 53. Support for DriverManager methods
294
Application Programming Guide and Reference for Java
Table 53. Support for DriverManager methods (continued)
JDBC method
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
getDrivers
Yes
Yes
Yes
1
Yes
getLoginTimeout
Yes
Yes
getLogStream
Yes
Yes
Yes
getLogWriter
Yes
Yes
Yes
println
Yes
Yes
Yes
registerDriver
Yes
Yes
2
Yes
1
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
setLoginTimeout
Yes
setLogStream
setLogWriter
Notes:
1. The DB2 JDBC Type 2 Driver does not use this setting.
2. This method is not supported for IBM Data Server Driver for JDBC and SQLJ type 2 connectivity on DB2 for
z/OS.
Table 54. Support for ParameterMetaData methods
JDBC method
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
getParameterClassName
No
No
No
getParameterCount
Yes
No
No
getParameterMode
Yes
No
No
getParameterType
Yes
No
No
getParameterTypeName
Yes
No
No
getPrecision
Yes
No
No
getScale
Yes
No
No
isNullable
Yes
No
No
isSigned
Yes
No
No
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
Yes
Yes
Yes
Yes
No
No
close
Yes
Yes
Yes
getConnection
Yes
Yes
Yes
Yes
Yes
Yes
Yes
No
No
Table 55. Support for PooledConnection methods
JDBC method
addConnectionEventListener
addStatementEventListener
1
removeConnectionEventListener
removeStatementEventListener
1
Notes:
1. This is a JDBC 4.0 method.
Chapter 7. JDBC and SQLJ reference information
295
Table 56. Support for PreparedStatement methods
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
Methods inherited from
java.sql.Statement
Yes
Yes
Yes
addBatch
Yes
Yes
Yes
clearParameters
Yes
Yes
Yes
execute
Yes
Yes
Yes
executeQuery
Yes
Yes
Yes
executeUpdate
Yes
Yes
Yes
getMetaData
Yes
Yes
Yes
getParameterMetaData
Yes
Yes
Yes
setArray
No
No
No
Yes
Yes
JDBC method
setAsciiStream
Yes
setBigDecimal
Yes
1,2
Yes
Yes
Yes
1,3
Yes
Yes
setBlob
Yes
4
Yes
Yes
setBoolean
Yes
Yes
Yes
setByte
Yes
Yes
Yes
setBytes
Yes
setBinaryStream
Yes
Yes
Yes
1,5
Yes
Yes
Yes
6
Yes
Yes
setDate
Yes
8
setDouble
setCharacterStream
setClob
Yes
Yes8
Yes
Yes
Yes
setFloat
Yes
Yes
Yes
setInt
Yes
Yes
Yes
setLong
Yes
Yes
Yes
Yes
Yes9
Yes
Yes
Yes
No
No
No
Yes
No
No
Yes
Yes
setNull
Yes
setObject
setRef
setRowId
7
setShort
9
8
Yes
Yes
Yes10
Yes8
Yes8
Yes8
setTimestamp
Yes8
Yes8
Yes8
setUnicodeStream
Yes
Yes
Yes
setURL
Yes
Yes
Yes
setString
Yes
setTime
296
10
9
Application Programming Guide and Reference for Java
10
Table 56. Support for PreparedStatement methods (continued)
JDBC method
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
Notes:
1. If the value of the length parameter is -1, all of the data from the InputStream or Reader is read and sent to the
data source.
2. Supported forms of this method include the following JDBC 4.0 forms:
setAsciiStream(int parameterIndex, InputStream x, long length)
setAsciiStream(int parameterIndex, InputStream x)
3. Supported forms of this method include the following JDBC 4.0 forms:
setBinaryStream(int parameterIndex, InputStream x, long length)
setBinaryStream(int parameterIndex, InputStream x)
4. Supported forms of this method include the following JDBC 4.0 form:
setBlob(int parameterIndex, InputStream inputStream, long length)
5. Supported forms of this method include the following JDBC 4.0 forms:
setCharacterStream(int parameterIndex, Reader reader, long length)
setCharacterStream(int parameterIndex, Reader reader)
6. Supported forms of this method include the following JDBC 4.0 form:
setClob(int parameterIndex, Reader reader, long length)
7. This is a JDBC 4.0 method.
8. The database server does no timezone adjustment for datetime values. The JDBC driver adjusts a value for the
local timezone before sending the value to the server if you specify a form of the setDate, setTime, or
setTimestamp method that includes a java.util.Calendar parameter.
9. The following form of setNull is not supported:
setNull(int parameterIndex, int jdbcType, String typeName)
10. setString is not supported if the column has the FOR BIT DATA attribute or the data type is BLOB.
Table 57. Support for Ref methods
JDBC method
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
get BaseTypeName
No
No
No
JDBC method
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
absolute
Yes
Yes
Yes
afterLast
Yes
Yes
Yes
beforeFirst
Yes
Yes
Yes
cancelRowUpdates
Yes
No
No
clearWarnings
Yes
Yes
Yes
close
Yes
Yes
Yes
deleteRow
Yes
No
No
findColumn
Yes
Yes
Yes
first
Yes
Yes
Yes
getArray
No
No
No
Table 58. Support for ResultSet methods
Chapter 7. JDBC and SQLJ reference information
297
Table 58. Support for ResultSet methods (continued)
JDBC method
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
getAsciiStream
Yes
Yes
Yes
getBigDecimal
Yes
Yes
Yes
Yes
Yes
1
getBinaryStream
Yes
getBlob
Yes
Yes
Yes
getBoolean
Yes
Yes
Yes
getByte
Yes
Yes
Yes
getBytes
Yes
Yes
Yes
getCharacterStream
Yes
Yes
Yes
getClob
Yes
Yes
Yes
getConcurrency
Yes
Yes
Yes
getCursorName
Yes
Yes
Yes
Yes
Yes3
Yes
Yes
Yes
getFetchDirection
Yes
Yes
Yes
getFetchSize
Yes
Yes
Yes
getFloat
Yes
Yes
Yes
getInt
Yes
Yes
Yes
getLong
Yes
Yes
Yes
getMetaData
Yes
Yes
Yes
getDate
Yes
getDouble
3
Yes
Yes4
No
No
No
Yes
Yes
Yes
getRowId10
Yes
No
No
getShort
Yes
Yes
Yes
getStatement
Yes
Yes
Yes
getString
Yes
Yes
Yes
getTime
Yes3
Yes3
Yes3
getTimestamp
Yes3
Yes3
Yes3
getType
Yes
Yes
Yes
getUnicodeStream
Yes
Yes
Yes
getURL
Yes
Yes
Yes
getWarnings
Yes
Yes
Yes
insertRow
Yes
No
No
isAfterLast
Yes
Yes
Yes
isBeforeFirst
Yes
Yes
Yes
isFirst
Yes
Yes
Yes
isLast
Yes
Yes
Yes
last
Yes
Yes
Yes
getObject
Yes
getRef
getRow
298
4
3
Application Programming Guide and Reference for Java
4
Table 58. Support for ResultSet methods (continued)
JDBC method
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
moveToCurrentRow
Yes
No
No
moveToInsertRow
Yes
No
No
next
Yes
Yes
Yes
previous
Yes
Yes
Yes
refreshRow
Yes
No
No
relative
Yes
Yes
Yes
rowDeleted
Yes
No
No
rowInserted
Yes
No
No
rowUpdated
Yes
No
No
setFetchDirection
Yes
Yes
Yes
setFetchSize
Yes
Yes
Yes
updateArray
No
No
No
No
No
updateAsciiStream
Yes
updateBigDecimal
Yes
5
No
No
Yes
6
No
No
updateBlob
Yes
7
No
No
updateBoolean
Yes
No
No
updateByte
Yes
No
No
updateBytes
Yes
No
No
No
No
updateBinaryStream
Yes
8
updateClob
Yes
9
No
No
updateDate
Yes
No
No
updateDouble
Yes
No
No
updateFloat
Yes
No
No
updateInt
Yes
No
No
updateLong
Yes
No
No
updateNull
Yes
No
No
updateObject
Yes
No
No
updateRef
No
No
No
Yes
No
No
Yes
No
No
updateShort
Yes
No
No
updateString
Yes
No
No
updateTime
Yes
No
No
updateTimestamp
Yes
No
No
wasNull
Yes
Yes
Yes
updateCharacterStream
updateRow
updateRowId
10
Chapter 7. JDBC and SQLJ reference information
299
Table 58. Support for ResultSet methods (continued)
JDBC method
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
Notes:
1. getBinaryStream is not supported for CLOB columns.
2. getMetaData pads the schema name, if the returned schema name is less than 8 characters, to fill 8 characters.
3. The database server does no timezone adjustment for datetime values. The JDBC driver adjusts a value for the
local timezone after retrieving the value from the server if you specify a form of the getDate, getTime, or
getTimestamp method that includes a java.util.Calendar parameter.
4. The following form of the getObject method is not supported:
getObject(int parameterIndex, java.util.Map
map)
5. Supported forms of this method include the following JDBC 4.0 forms:
updateAsciiStream(int columnIndex, InputStream x)
updateAsciiStream(String columnLabel, InputStream x)
updateAsciiStream(int columnIndex, InputStream x, long length)
updateAsciiStream(String columnLabel, InputStream x, long length)
6. Supported forms of this method include the following JDBC 4.0 forms:
updateBinaryStream(int columnIndex, InputStream x)
updateBinaryStream(String columnLabel, InputStream x)
updateBinaryStream(int columnIndex, InputStream x, long length)
updateBinaryStream(String columnLabel, InputStream x, long length)
7. Supported forms of this method include the following JDBC 4.0 forms:
updateBlob(int columnIndex, InputStream x)
updateBlob(String columnLabel, InputStream x)
updateBlob(int columnIndex, InputStream x, long length)
updateBlob(String columnLabel, InputStream x, long length)
8. Supported forms of this method include the following JDBC 4.0 forms:
updateCharacterStream(int columnIndex, Reader reader)
updateCharacterStream(String columnLabel, Reader reader)
updateCharacterStream(int columnIndex, Reader reader, long length)
updateCharacterStream(String columnLabel, Reader reader, long length)
9. Supported forms of this method include the following JDBC 4.0 forms:
updateClob(int columnIndex, Reader reader)
updateClob(String columnLabel, Reader reader)
updateClob(int columnIndex, Reader reader, long length)
updateClob(String columnLabel, Reader reader, long length)
10. This is a JDBC 4.0 method.
Table 59. Support for ResultSetMetaData methods
JDBC method
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
getCatalogName
Yes
Yes
Yes
getColumnClassName
No
Yes
Yes
getColumnCount
Yes
Yes
Yes
getColumnDisplaySize
Yes
Yes
Yes
getColumnLabel
Yes
Yes
Yes
getColumnName
Yes
Yes
Yes
getColumnType
Yes
Yes
Yes
getColumnTypeName
Yes
Yes
Yes
300
Application Programming Guide and Reference for Java
Table 59. Support for ResultSetMetaData methods (continued)
JDBC method
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
getPrecision
Yes
Yes
Yes
getScale
Yes
Yes
Yes
getSchemaName
Yes
Yes
Yes
Yes
Yes
1
getTableName
Yes
isAutoIncrement
Yes
Yes
Yes
isCaseSensitive
Yes
Yes
Yes
isCurrency
Yes
Yes
Yes
isDefinitelyWritable
Yes
Yes
Yes
isNullable
Yes
Yes
Yes
isReadOnly
Yes
Yes
Yes
isSearchable
Yes
Yes
Yes
isSigned
Yes
Yes
Yes
isWritable
Yes
Yes
Yes
Notes:
1. For IBM Informix data sources, getTableName does not return a value.
2. getSchemaName pads the schema name, if the returned schema name is less than 8 characters, to fill 8 characters.
Table 60. Support for RowId methods1
JDBC method
IBM Data Server
Driver for JDBC and
SQLJ support2
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
equals
Yes
No
No
getBytes
Yes
No
No
hashCode
No
No
No
toString
Yes
No
No
Notes:
1. These methods are JDBC 4.0 methods.
2. These methods are supported for connections to DB2 for z/OS, DB2 for i, and IBM Informix data sources.
Table 61. Support for SQLClientInfoException methods1
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
Methods inherited from
java.lang.Exception
Yes
No
No
Methods inherited from
java.lang.Throwable
Yes
No
No
Methods inherited from
java.lang.Object
Yes
No
No
getFailedProperties
Yes
No
No
JDBC method
Note:
1. This is a JDBC 4.0 class.
Chapter 7. JDBC and SQLJ reference information
301
Table 62. Support for SQLData methods
JDBC method
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
getSQLTypeName
No
No
No
readSQL
No
No
No
writeSQL
No
No
No
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
Methods inherited from
java.lang.Exception
Yes
No
No
Methods inherited from
java.lang.Throwable
Yes
No
No
Methods inherited from
java.lang.Object
Yes
No
No
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
Methods inherited from
java.lang.Exception
Yes
No
No
Methods inherited from
java.lang.Throwable
Yes
No
No
Methods inherited from
java.lang.Object
Yes
No
No
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
Methods inherited from
java.lang.Exception
Yes
Yes
Yes
getSQLState
Yes
Yes
Yes
getErrorCode
Yes
Yes
Yes
getNextException
Yes
Yes
Yes
setNextException
Yes
Yes
Yes
Table 63. Support for SQLDataException methods1
JDBC method
Note:
1. This is a JDBC 4.0 class.
Table 64. Support for SQLDataException methods1
JDBC method
Note:
1. This is a JDBC 4.0 class.
Table 65. Support for SQLException methods
JDBC method
302
Application Programming Guide and Reference for Java
Table 66. Support for SQLFeatureNotSupported methods1
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
Methods inherited from
java.lang.Exception
Yes
No
No
Methods inherited from
java.lang.Throwable
Yes
No
No
Methods inherited from
java.lang.Object
Yes
No
No
JDBC method
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
readArray
No
No
No
readAsciiStream
No
No
No
readBigDecimal
No
No
No
readBinaryStream
No
No
No
readBlob
No
No
No
readBoolean
No
No
No
readByte
No
No
No
readBytes
No
No
No
readCharacterStream
No
No
No
readClob
No
No
No
readDate
No
No
No
readDouble
No
No
No
readFloat
No
No
No
readInt
No
No
No
readLong
No
No
No
readObject
No
No
No
readRef
No
No
No
readShort
No
No
No
readString
No
No
No
readTime
No
No
No
readTimestamp
No
No
No
wasNull
No
No
No
JDBC method
Note:
1. This is a JDBC 4.0 class.
Table 67. Support for SQLInput methods
Chapter 7. JDBC and SQLJ reference information
303
Table 68. Support for SQLIntegrityConstraintViolationException methods1
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
Methods inherited from
java.lang.Exception
Yes
No
No
Methods inherited from
java.lang.Throwable
Yes
No
No
Methods inherited from
java.lang.Object
Yes
No
No
JDBC method
Note:
1. This is a JDBC 4.0 class.
Table 69. Support for SQLInvalidAuthorizationSpecException methods1
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
Methods inherited from
java.lang.Exception
Yes
No
No
Methods inherited from
java.lang.Throwable
Yes
No
No
Methods inherited from
java.lang.Object
Yes
No
No
JDBC method
Note:
1. This is a JDBC 4.0 class.
Table 70. Support for SQLNonTransientConnectionException methods1
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
Methods inherited from
java.lang.Exception
Yes
No
No
Methods inherited from
java.lang.Throwable
Yes
No
No
Methods inherited from
java.lang.Object
Yes
No
No
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
Methods inherited from
java.lang.Exception
Yes
No
No
Methods inherited from
java.lang.Throwable
Yes
No
No
Methods inherited from
java.lang.Object
Yes
No
No
JDBC method
Note:
1. This is a JDBC 4.0 class.
Table 71. Support for SQLNonTransientException methods1
JDBC method
304
Application Programming Guide and Reference for Java
Table 71. Support for SQLNonTransientException methods1 (continued)
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
JDBC method
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
writeArray
No
No
No
writeAsciiStream
No
No
No
writeBigDecimal
No
No
No
writeBinaryStream
No
No
No
writeBlob
No
No
No
writeBoolean
No
No
No
writeByte
No
No
No
writeBytes
No
No
No
writeCharacterStream
No
No
No
writeClob
No
No
No
writeDate
No
No
No
writeDouble
No
No
No
writeFloat
No
No
No
writeInt
No
No
No
writeLong
No
No
No
writeObject
No
No
No
writeRef
No
No
No
writeShort
No
No
No
writeString
No
No
No
writeStruct
No
No
No
writeTime
No
No
No
writeTimestamp
No
No
No
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
Methods inherited from
java.lang.Exception
Yes
No
No
Methods inherited from
java.lang.Throwable
Yes
No
No
Methods inherited from
java.lang.Object
Yes
No
No
JDBC method
IBM Data Server
Driver for JDBC and
SQLJ support
Note:
1. This is a JDBC 4.0 class.
Table 72. Support for SQLOutput methods
Table 73. Support for SQLRecoverableException methods1
JDBC method
Chapter 7. JDBC and SQLJ reference information
305
Table 73. Support for SQLRecoverableException methods1 (continued)
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
Methods inherited from
java.lang.Exception
Yes
No
No
Methods inherited from
java.lang.Throwable
Yes
No
No
Methods inherited from
java.lang.Object
Yes
No
No
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
Methods inherited from
java.lang.Exception
Yes
No
No
Methods inherited from
java.lang.Throwable
Yes
No
No
Methods inherited from
java.lang.Object
Yes
No
No
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
Methods inherited from
java.lang.Exception
Yes
No
No
Methods inherited from
java.lang.Throwable
Yes
No
No
Methods inherited from
java.lang.Object
Yes
No
No
JDBC method
IBM Data Server
Driver for JDBC and
SQLJ support
Note:
1. This is a JDBC 4.0 class.
Table 74. Support for SQLSyntaxErrorException methods1
JDBC method
Note:
1. This is a JDBC 4.0 class.
Table 75. Support for SQLTimeoutException methods1
JDBC method
Note:
1. This is a JDBC 4.0 class.
Table 76. Support for SQLTransientConnectionException methods1
JDBC method
Note:
1. This is a JDBC 4.0 class.
306
Application Programming Guide and Reference for Java
Table 77. Support for SQLTransientException methods1
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
Methods inherited from
java.lang.Exception
Yes
No
No
Methods inherited from
java.lang.Throwable
Yes
No
No
Methods inherited from
java.lang.Object
Yes
No
No
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
Methods inherited from
java.lang.Exception
Yes
No
No
Methods inherited from
java.lang.Throwable
Yes
No
No
Methods inherited from
java.lang.Object
Yes
No
No
JDBC method
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
free
Yes
No
No
getBinaryStream
Yes
No
No
getCharacterStream
Yes
No
No
getSource
Yes
No
No
getString
Yes
No
No
setBinaryStream
Yes
No
No
setCharacterStream
Yes
No
No
setResult
Yes
No
No
setString
Yes
No
No
JDBC method
Note:
1. This is a JDBC 4.0 class.
Table 78. Support for SQLTransientRollbackException methods1
JDBC method
Note:
1. This is a JDBC 4.0 class.
Table 79. Support for SQLXML methods1
Notes:
1. These are JDBC 4.0 methods. These methods are not supported for connections to IBM Informix servers.
Table 80. Support for Statement methods
JDBC method
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
addBatch
Yes
Yes
Yes
Chapter 7. JDBC and SQLJ reference information
307
Table 80. Support for Statement methods (continued)
JDBC method
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
cancel
Yes1
Yes2
Yes
clearBatch
Yes
Yes
Yes
clearWarnings
Yes
Yes
Yes
close
Yes
Yes
execute
Yes
Yes
executeBatch
Yes
Yes
executeQuery
Yes
Yes
Yes
3
Yes
Yes
Yes
3
Yes
executeUpdate
Yes
Yes
getConnection
Yes
Yes
Yes
getFetchDirection
Yes
Yes
Yes
getFetchSize
Yes
Yes
Yes
getGeneratedKeys
Yes
No
No
getMaxFieldSize
Yes
Yes
Yes
getMaxRows
Yes
Yes
getMoreResults
Yes
Yes
6
Yes
3
Yes
Yes
Yes
Yes
Yes
Yes
getResultSetConcurrency
Yes
Yes
Yes
getResultSetHoldability
Yes
No
No
getResultSetType
Yes
Yes
Yes
getQueryTimeout
Yes
getResultSet
4
Yes
Yes
Yes
getWarnings
Yes
Yes
Yes
isClosed7
Yes
No
No
isPoolable7
Yes
No
No
setCursorName
Yes
Yes
Yes
setEscapeProcessing
Yes
Yes
Yes
setFetchDirection
Yes
Yes
Yes
setFetchSize
Yes
Yes
Yes
setMaxFieldSize
Yes
Yes
Yes
setMaxRows
Yes
Yes
Yes
No
No
Yes
Yes
getUpdateCount
setPoolable
7
setQueryTimeout
308
Yes
Yes
5,6
Application Programming Guide and Reference for Java
Table 80. Support for Statement methods (continued)
JDBC method
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
Notes:
1. For the IBM Data Server Driver for JDBC and SQLJ, Statement.cancel is supported only in the following
environments:
v Type 2 and type 4 connectivity from a Linux, UNIX, or Windows client to a DB2 Database for Linux, UNIX,
and Windows server, Version 8 or later
v Type 2 and type 4 connectivity from a Linux, UNIX, or Windows client to a DB2 for z/OS server, Version 9 or
later
v Type 4 connectivity from a z/OS client to a DB2 Database for Linux, UNIX, and Windows server, Version 8 or
later
v Type 4 connectivity from a z/OS client to a DB2 for z/OS server, Version 8 or later
The action that the IBM Data Server Driver for JDBC and SQLJ takes when the application executes
Statement.cancel is also dependent on the setting of the DB2BaseDataSource.interruptProcessingMode property.
2. For the DB2 JDBC Type 2 Driver for Linux, UNIX and Windows, Statement.cancel is supported only in the
following environments:
v Connections to a DB2 Database for Linux, UNIX, and Windows server, Version 8 or later
v Connections to a DB2 for z/OS server, Version 9 or later
3. The DB2 JDBC Type 2 Driver for Linux, UNIX and Windows does not support the JDBC 3.0 form of this method.
4. Not supported for stored procedure ResultSets.
5. For DB2 for i, this method is supported only for a seconds value of 0.
6. For the IBM Data Server Driver for JDBC and SQLJ Version 4.0 and later, Statement.setQueryTimeout is
supported for the following methods:
v Statement.execute
v Statement.executeUpdate
v Statement.executeQuery
Statement.setQueryTimeout is not supported for the Statement.executeBatch method.
7. This is a JDBC 4.0 method.
Table 81. Support for Struct methods
JDBC method
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
getSQLTypeName
No
No
No
getAttributes
No
No
No
JDBC method1
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
isWrapperFor
Yes
No
No
unWrap
Yes
No
No
Table 82. Support for Wrapper methods
Notes:
1. These are JDBC 4.0 methods.
Chapter 7. JDBC and SQLJ reference information
309
Table 83. Support for javax.sql.XAConnection methods
IBM Data Server
Driver for JDBC and
SQLJ support1
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
Methods inherited from
javax.sql.PooledConnection
Yes
Yes
Yes
getXAResource
Yes
Yes
Yes
JDBC method
Notes:
1. These methods are supported for IBM Data Server Driver for JDBC and SQLJ type 2 connectivity to a DB2
Database for Linux, UNIX, and Windows server or IBM Data Server Driver for JDBC and SQLJ type 4
connectivity.
Table 84. Support for XADataSource methods
JDBC method
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
getLoginTimeout
Yes
Yes
Yes
getLogWriter
Yes
Yes
Yes
getXAConnection
Yes
Yes
Yes
setLoginTimeout
Yes
Yes
Yes
setLogWriter
Yes
Yes
Yes
JDBC method
IBM Data Server
Driver for JDBC and
SQLJ support
DB2 JDBC Type 2
Driver for Linux, UNIX
and Windows support
IBM Informix JDBC
Driver support
commit
Yes1
Yes
Yes
Yes
1
Yes
Yes
Yes
1
Yes
Yes
Yes
2
Yes
Yes
Yes
1
Yes
Yes
Yes
1
Yes
Yes
Yes
1
Yes
Yes
Yes
1
Yes
Yes
Yes
2
Yes
Yes
Yes
1
Yes
Yes
Table 85. Support for javax.transaction.xa.XAResource methods
end
forget
getTransactionTimeout
isSameRM
prepare
recover
rollback
setTransactionTimeout
start
Notes:
1. This method is supported for IBM Data Server Driver for JDBC and SQLJ type 2 connectivity to a DB2 Database
for Linux, UNIX, and Windows server or IBM Data Server Driver for JDBC and SQLJ type 4 connectivity.
2. This method is supported for IBM Data Server Driver for JDBC and SQLJ type 4 connectivity to DB2 Database for
Linux, UNIX, and Windows Version 9.1 or later.
IBM Data Server Driver for JDBC and SQLJ support for SQL escape
syntax
The IBM Data Server Driver for JDBC and SQLJ supports SQL escape syntax, as
described in the JDBC 1.0 specification.
310
Application Programming Guide and Reference for Java
This is the same syntax that is used in vendor escape clauses in ODBC and CLI
applications.
SQL escape syntax is supported in JDBC and SQLJ applications.
SQLJ statement reference information
SQLJ statements are used for transaction control and SQL statement execution.
SQLJ clause
The SQL statements in an SQLJ program are in SQLJ clauses.
Syntax
#sql
connection-declaration-clause
iterator-declaration-clause
executable-clause
;
Usage notes
Keywords in an SQLJ clause are case sensitive, unless those keywords are part of
an SQL statement in an executable clause.
Related reference
“SQLJ connection-declaration-clause” on page 315
“SQLJ executable-clause” on page 317
“SQLJ iterator-declaration-clause” on page 316
SQLJ host-expression
A host expression is a Java variable or expression that is referenced by SQLJ
clauses in an SQLJ application program.
Syntax
:
IN
OUT
INOUT
simple-variable
(complex-expression)
INDICATOR
:
simple-variable
(complex-expression)
Description
:
Indicates that the variable or expression that follows is a host expression. The
colon must immediately precede the variable or expression.
IN|OUT|INOUT
For a host expression that is used as a parameter in a stored procedure call,
identifies whether the parameter provides data to the stored procedure (IN),
retrieves data from the stored procedure (OUT), or does both (INOUT). The
default is IN.
simple-variable
Specifies a Java unqualified identifier.
complex-expression
Specifies a Java expression that results in a single value.
Chapter 7. JDBC and SQLJ reference information
311
INDICATOR :simple-variable or INDICATOR :(complex-expression)
Specifies the optional indicator variable for the corresponding Java host
variable. The data type of the indicator variable must be the Java short type.
The only valid values for :simple-variable or :(complex-expression) are:
For customized applications, and for input, only these values are valid:
Indicator value
Equivalent constant
Meaning of value
-1
sqlj.runtime.ExecutionContext.DBNull
Null
-5
sqlj.runtime.ExecutionContext.DBDefault
Default
-7
sqlj.runtime.ExecutionContext.DBUnassigned
Unassigned
short-value >=0
sqlj.runtime.ExecutionContext.DBNonNull
Non-null
-2, -3, -4, -6
For uncustomized applications, and for input, only these values are valid:
Indicator value
Equivalent constant
Meaning of value
-1
sqlj.runtime.ExecutionContext.DBNull
Null
sqlj.runtime.ExecutionContext.DBNonNull
Non-null
-7 <= short-value < -1
0
short-value >0
For customized or uncustomized applications, and for output, SQLJ sets one of
these values:
Indicator value
Equivalent constant
Meaning of value
-1
sqlj.runtime.ExecutionContext.DBNull
Retrieved value is SQL NULL
0
Retrieved value is not SQL NULL
Usage notes
v A complex expression must be enclosed in parentheses.
v ANSI/ISO rules govern where a host expression can appear in a static SQL
statement.
v Indicator variables are required in the following cases:
– For input, when a Java primitive type is used to assign the NULL value to a
table column.
– For output, when a Java primitive type is used for a host variable, and the
source column can return NULL values.
If an SQL NULL value is returned, and no indicator variable is defined, an
SQLNullException is thrown.
Indicator variables are not required for input or output of a Java null value as an
SQL NULL, if the data type of the host variable is:
– The data type of a Java class
– A custom database type that the driver supports
v , ... variable-n
v For output, indicator variables are valid in the following types of statements:
– CALL statement with OUT or INOUT parameters
– FETCH positioned-iterator INTO variable-1, ... variable-n
– SELECT column-1, ... column-n INTO variable-1, ... variable-n
312
Application Programming Guide and Reference for Java
Related concepts
“Variables in SQLJ applications” on page 120
SQLJ implements-clause
The implements clause derives one or more classes from a Java interface.
Syntax
,
implements interface-element
interface-element:
sqlj.runtime.ForUpdate
sqlj.runtime.Scrollable
user-specified-interface-class
Description
interface-element
Specifies a user-defined Java interface, the SQLJ interface
sqlj.runtime.ForUpdate or the SQLJ interface sqlj.runtime.Scrollable.
You need to implement sqlj.runtime.ForUpdate when you declare an iterator
for a positioned UPDATE or positioned DELETE operation. See "Perform
positioned UPDATE and DELETE operations in an SQLJ application" for
information on performing a positioned UPDATE or positioned DELETE
operation in SQLJ.
You need to implement sqlj.runtime.Scrollable when you declare a
scrollable iterator. See "Use scrollable iterators in an SQLJ application" for
information on scrollable iterators.
Related tasks
“Performing positioned UPDATE and DELETE operations in an SQLJ application”
on page 127
“Using scrollable iterators in an SQLJ application” on page 143
SQLJ with-clause
The with clause specifies a set of one or more attributes for an iterator or a
connection context.
Syntax
,
with ( with-element
)
with-element:
Chapter 7. JDBC and SQLJ reference information
313
holdability=true
holdability=false
sensitivity=ASENSITIVE
sensitivity=INSENSITIVE
sensitivity=SENSITIVE
,
dynamic=false
dynamic=true
,
updateColumns= " column-name
"
Java-ID=Java-constant-expression
dataSource= " logical-datasource-name "
Description
holdability
For an iterator, specifies whether an iterator keeps its position in a table after a
COMMIT is executed. The value for holdability must be true or false.
sensitivity
For an iterator, specifies whether changes that are made to the underlying table
can be visible to the iterator after it is opened. The value must be
INSENSITIVE, SENSITIVE, or ASENSITIVE. The default is ASENSITIVE.
For connections to IBM Informix, only INSENSITIVE is supported.
dynamic
For an iterator that is defined with sensitivity=SENSITIVE, specifies whether
the following cases are true:
v When the application executes positioned UPDATE and DELETE statements
with the iterator, those changes are visible to the iterator.
v When the application executes INSERT, UPDATE, and DELETE statements
within the application but outside the iterator, those changes are visible to
the iterator.
The value for dynamic must be true or false. The default is false.
DB2 Database for Linux, UNIX, and Windows servers do not support dynamic
scrollable cursors. Specify true only if your application accesses data on DB2
for z/OS servers, at Version 9 or later.
For connections to IBM Informix, only false is supported. IBM Informix does
not support dynamic cursors.
updateColumns
For an iterator, specifies the columns that are to be modified when the iterator
is used for a positioned UPDATE statement. The value for updateColumns
must be a literal string that contains the column names, separated by commas.
column-name
For an iterator, specifies a column of the result table that is to be updated
using the iterator.
Java-ID
For an iterator or connection context, specifies a Java variable that identifies a
user-defined attribute of the iterator or connection context. The value of
Java-constant-expression is also user-defined.
dataSource
For a connection context, specifies the logical name of a separately-created
314
Application Programming Guide and Reference for Java
DataSource object that represents the data source to which the application will
connect. This option is available only for the IBM Data Server Driver for JDBC
and SQLJ.
Usage notes
v The value on the left side of a with element must be unique within its with
clause.
v If you specify updateColumns in a with element of an iterator declaration
clause, the iterator declaration clause must also contain an implements clause
that specifies the sqlj.runtime.ForUpdate interface.
v If you do not customize your SQLJ program, the JDBC driver ignores the value
of holdability that is in the with clause. Instead, the driver uses the JDBC driver
setting for holdability.
Related concepts
“SQLJ and JDBC in the same application” on page 152
Related tasks
“Connecting to a data source using SQLJ” on page 113
“Performing positioned UPDATE and DELETE operations in an SQLJ application”
on page 127
“Using scrollable iterators in an SQLJ application” on page 143
SQLJ connection-declaration-clause
The connection declaration clause declares a connection to a data source in an
SQLJ application program.
Syntax
context Java-class-name
Java-modifiers
implements-clause
with-clause
Description
Java-modifiers
Specifies modifiers that are valid for Java class declarations, such as static,
public, private, or protected.
Java-class-name
Specifies a valid Java identifier. During the program preparation process, SQLJ
generates a connection context class whose name is this identifier.
implements-clause
See "SQLJ implements-clause" for a description of this clause. In a connection
declaration clause, the interface class to which the implements clause refers
must be a user-defined interface class.
with-clause
See "SQLJ with-clause" for a description of this clause.
Usage notes
v SQLJ generates a connection class declaration for each connection declaration
clause you specify. SQLJ data source connections are objects of those generated
connection classes.
v You can specify a connection declaration clause anywhere that a Java class
definition can appear in a Java program.
Chapter 7. JDBC and SQLJ reference information
315
Related tasks
“Connecting to a data source using SQLJ” on page 113
Related reference
“SQLJ implements-clause” on page 313
“SQLJ with-clause” on page 313
SQLJ iterator-declaration-clause
An iterator declaration clause declares a positioned iterator class or a named
iterator class in an SQLJ application program.
An iterator contains the result table from a query. SQLJ generates an iterator class
for each iterator declaration clause you specify. An iterator is an object of an
iterator class.
An iterator declaration clause has a form for a positioned iterator and a form for a
named iterator. The two kinds of iterators are distinct and incompatible Java types
that are implemented with different interfaces.
Syntax
iterator Java-class-name
Java-modifiers
(
implements-clause
positioned-iterator-column-declarations
named-iterator-column-declarations
with-clause
)
positioned-iterator-column declarations:
,
Java-data-type
named-iterator-column-declarations:
,
Java-data-type Java-ID
Description
Java-modifiers
Any modifiers that are valid for Java class declarations, such as static, public,
private, or protected.
Java-class-name
Any valid Java identifier. During the program preparation process, SQLJ
generates an iterator class whose name is this identifier.
implements-clause
See "SQLJ implements-clause" for a description of this clause. For an iterator
declaration clause that declares an iterator for a positioned UPDATE or
positioned DELETE operation, the implements clause must specify interface
316
Application Programming Guide and Reference for Java
sqlj.runtime.ForUpdate. For an iterator declaration clause that declares a
scrollable iterator, the implements clause must specify interface
sqlj.runtime.Scrollable.
with-clause
See "SQLJ with-clause" for a description of this clause.
positioned-iterator-column-declarations
Specifies a list of Java data types, which are the data types of the columns in
the positioned iterator. The data types in the list must be separated by
commas. The order of the data types in the positioned iterator declaration is
the same as the order of the columns in the result table. For online checking
during serialized profile customization to succeed, the data types of the
columns in the iterator must be compatible with the data types of the columns
in the result table. See "Java, JDBC, and SQL data types" for a list of compatible
data types.
named-iterator-column-declarations
Specifies a list of Java data types and Java identifiers, which are the data types
and names of the columns in the named iterator. Pairs of data types and names
must be separated by commas. The name of a column in the iterator must
match, except for case, the name of a column in the result table. For online
checking during serialized profile customization to succeed, the data types of
the columns in the iterator must be compatible with the data types of the
columns in the result table. See "Java, JDBC, and SQL data types" for a list of
compatible data types.
Usage notes
v An iterator declaration clause can appear anywhere in a Java program that a
Java class declaration can appear.
v When a named iterator declaration contains more than one pair of Java data
types and Java IDs, all Java IDs within the list must be unique. Two Java IDs are
not unique if they differ only in case.
Related concepts
“Data retrieval in SQLJ applications” on page 137
Related tasks
“Using a named iterator in an SQLJ application” on page 137
“Using a positioned iterator in an SQLJ application” on page 139
“Using scrollable iterators in an SQLJ application” on page 143
Related reference
“SQLJ implements-clause” on page 313
“SQLJ with-clause” on page 313
SQLJ executable-clause
An executable clause contains an SQL statement or an assignment statement. An
assignment statement assigns the result of an SQL operation to a Java variable.
This topic describes the general form of an executable clause.
Syntax
context-clause
statement-clause
assignment-clause
Chapter 7. JDBC and SQLJ reference information
317
Usage notes
v An executable clause can appear anywhere in a Java program that a Java
statement can appear.
v SQLJ reports negative SQL codes from executable clauses through class
java.sql.SQLException.
If SQLJ raises a run-time exception during the execution of an executable clause,
the value of any host expression of type OUT or INOUT is undefined.
Related reference
“SQLJ assignment-clause” on page 322
“SQLJ context-clause”
“SQLJ statement-clause”
SQLJ context-clause
A context clause specifies a connection context, an execution context, or both. You
use a connection context to connect to a data source. You use an execution context
to monitor and modify SQL statement execution.
Syntax
[
connection-context
execution-context
connection-context ,
]
execution context
Description
connection-context
Specifies a valid Java identifier that is declared earlier in the SQLJ program.
That identifier must be declared as an instance of the connection context class
that SQLJ generates for a connection declaration clause.
execution-context
Specifies a valid Java identifier that is declared earlier in the SQLJ program.
That identifier must be declared as an instance of class
sqlj.runtime.ExecutionContext.
Usage notes
v If you do not specify a connection context in an executable clause, SQLJ uses the
default connection context.
v If you do not specify an execution context, SQLJ obtains the execution context
from the connection context of the statement.
Related tasks
“Connecting to a data source using SQLJ” on page 113
“Controlling the execution of SQL statements in SQLJ” on page 155
SQLJ statement-clause
A statement clause contains an SQL statement or a SET TRANSACTION clause.
Syntax
{
318
SQL-statement
SET-TRANSACTION-clause
}
Application Programming Guide and Reference for Java
Description
SQL-statement
You can include SQL statements in Table 86 in a statement clause.
SET-TRANSACTION-clause
Sets the isolation level for SQL statements in the program and the access mode
for the connection. The SET TRANSACTION clause is equivalent to the SET
TRANSACTION statement, which is described in the ANSI/ISO SQL standard
of 1992 and is supported in some implementations of SQL.
Table 86. Valid SQL statements in an SQLJ statement clause
Statement
Applicable data sources
ALTER DATABASE
1 on page 321, 2 on page 321
ALTER FUNCTION
1 on page 321, 2 on page 321, 3 on page 321
ALTER INDEX
1 on page 321, 2 on page 321, 3 on page 321
ALTER PROCEDURE
1 on page 321, 2 on page 321, 3 on page 321
ALTER STOGROUP
1 on page 321, 2 on page 321
ALTER TABLE
1 on page 321, 2 on page 321, 3 on page 321
ALTER TABLESPACE
1 on page 321, 2 on page 321
CALL
1 on page 321, 2 on page 321, 3 on page 321
COMMENT ON
1 on page 321, 2 on page 321
COMMIT
1 on page 321, 2 on page 321, 3 on page 321
Compound SQL (BEGIN ATOMIC...END)
2 on page 321
CREATE ALIAS
1 on page 321, 2 on page 321
CREATE DATABASE
1 on page 321, 2 on page 321, 3a on page 321
CREATE DISTINCT TYPE
1 on page 321, 2 on page 321, 3 on page 321
CREATE FUNCTION
1 on page 321, 2 on page 321, 3 on page 321
CREATE GLOBAL TEMPORARY TABLE
1 on page 321, 2 on page 321
CREATE TEMP TABLE
3 on page 321
CREATE INDEX
1 on page 321, 2 on page 321, 3 on page 321
CREATE PROCEDURE
1 on page 321, 2 on page 321, 3 on page 321
CREATE STOGROUP
1 on page 321, 2 on page 321
CREATE SYNONYM
1 on page 321, 2 on page 321, 3 on page 321
CREATE TABLE
1 on page 321, 2 on page 321, 3 on page 321
CREATE TABLESPACE
1 on page 321, 2 on page 321
CREATE TYPE (cursor)
2 on page 321
CREATE TRIGGER
1 on page 321, 2 on page 321, 3 on page 321
CREATE VIEW
1 on page 321, 2 on page 321, 3 on page 321
DECLARE GLOBAL TEMPORARY TABLE
1 on page 321, 2 on page 321
DELETE
1 on page 321, 2 on page 321, 3 on page 321
DROP ALIAS
1 on page 321, 2 on page 321
DROP DATABASE
1 on page 321, 2 on page 321, 3a on page 321
DROP DISTINCT TYPE
1 on page 321, 2 on page 321
DROP TYPE
3 on page 321
DROP FUNCTION
1 on page 321, 2 on page 321, 3 on page 321
Chapter 7. JDBC and SQLJ reference information
319
Table 86. Valid SQL statements in an SQLJ statement clause (continued)
Statement
Applicable data sources
DROP INDEX
1 on page 321, 2 on page 321, 3 on page 321
DROP PACKAGE
1 on page 321, 2 on page 321
DROP PROCEDURE
1 on page 321, 2 on page 321, 3 on page 321
DROP STOGROUP
1 on page 321, 2 on page 321
DROP SYNONYM
1 on page 321, 2 on page 321, 3 on page 321
DROP TABLE
1 on page 321, 2 on page 321, 3 on page 321
DROP TABLESPACE
1 on page 321, 2 on page 321
DROP TRIGGER
1 on page 321, 2 on page 321, 3 on page 321
DROP VIEW
1 on page 321, 2 on page 321, 3 on page 321
FETCH
1 on page 321, 2 on page 321, 3 on page 321
GRANT
1 on page 321, 2 on page 321, 3 on page 321
INSERT
1 on page 321, 2 on page 321, 3 on page 321
LOCK TABLE
1 on page 321, 2 on page 321, 3 on page 321
MERGE
1 on page 321, 2 on page 321
REVOKE
1 on page 321, 2 on page 321, 3 on page 321
ROLLBACK
1 on page 321, 2 on page 321, 3 on page 321
SAVEPOINT
1 on page 321, 2 on page 321, 3 on page 321
SELECT INTO
1 on page 321, 2 on page 321, 3 on page 321
SET CURRENT APPLICATION ENCODING SCHEME
1 on page 321
SET CURRENT DEBUG MODE
1 on page 321
SET CURRENT DEFAULT TRANSFORM GROUP
2 on page 321
SET CURRENT DEGREE
1 on page 321, 2 on page 321
SET CURRENT EXPLAIN MODE
2 on page 321
SET CURRENT EXPLAIN SNAPSHOT
2 on page 321
SET CURRENT ISOLATION
1 on page 321, 2 on page 321
SET CURRENT LOCALE LC_CTYPE
1 on page 321
SET CURRENT MAINTAINED TABLE TYPES FOR
OPTIMIZATION
1 on page 321, 2 on page 321
SET CURRENT OPTIMIZATION HINT
1 on page 321, 2 on page 321
SET CURRENT PACKAGE PATH
1 on page 321
SET CURRENT PACKAGESET (USER is not supported)
1 on page 321, 2 on page 321
SET CURRENT PRECISION
1 on page 321, 2 on page 321
SET CURRENT QUERY OPTIMIZATION
2 on page 321
SET CURRENT REFRESH AGE
1 on page 321, 2 on page 321
SET CURRENT ROUTINE VERSION
1 on page 321
SET CURRENT RULES
1 on page 321
SET CURRENT SCHEMA
2 on page 321
SET CURRENT SQLID
1 on page 321
SET PATH
1 on page 321, 2 on page 321
TRUNCATE
1 on page 321
320
Application Programming Guide and Reference for Java
Table 86. Valid SQL statements in an SQLJ statement clause (continued)
Statement
Applicable data sources
UPDATE
1, 2, 3
Note: The SQL statement applies to connections to the following data sources:
1. DB2 for z/OS
2. DB2 Database for Linux, UNIX, and Windows
3. IBM Informix
a. IBM Informix, for the SYSMASTER database only.
Usage notes
v SQLJ supports both positioned and searched DELETE and UPDATE operations.
v For a FETCH statement, a positioned DELETE statement, or a positioned
UPDATE statement, you must use an iterator to refer to rows in a result table.
Related tasks
“Setting the isolation level for an SQLJ transaction” on page 168
Related reference
“SQLJ SET-TRANSACTION-clause”
Statements (DB2 SQL)
SQLJ SET-TRANSACTION-clause
The SET TRANSACTION clause sets the isolation level for the current unit of
work.
Syntax
SET TRANSACTION ISOLATION LEVEL
READ COMMITTED
READ UNCOMMITTED
REPEATABLE READ
SERIALIZABLE
Description
ISOLATION LEVEL
Specifies one of the following isolation levels:
READ COMMITTED
Specifies that the current DB2 isolation level is cursor stability.
READ UNCOMMITTED
Specifies that the current DB2 isolation level is uncommitted read.
REPEATABLE READ
Specifies that the current DB2 isolation level is read stability.
SERIALIZABLE
Specifies that the current DB2 isolation level is repeatable read.
Usage notes
You can execute SET TRANSACTION only at the beginning of a transaction.
Chapter 7. JDBC and SQLJ reference information
321
Related tasks
“Setting the isolation level for an SQLJ transaction” on page 168
SQLJ assignment-clause
The assignment clause assigns the result of an SQL operation to a Java variable.
Syntax
Java-ID
= {
fullselect
}
order-by-clause
optimize-for-clause
isolation-clause
queryno-clause
fetch-first-clause
iterator-conversion-clause
Description
Java-ID
Identifies an iterator that was declared previously as an instance of an iterator
class.
fullselect
Generates a result table.
iterator-conversion-clause
See "SQLJ iterator-conversion-clause" for a description of this clause.
Usage notes
v If the object that is identified by Java-ID is a positioned iterator, the number of
columns in the result set must match the number of columns in the iterator. In
addition, the data type of each column in the result set must be compatible with
the data type of the corresponding column in the iterator. See "Java, JDBC, and
SQL data types" for a list of compatible Java and SQL data types.
v If the object that is identified by Java-ID is a named iterator, the name of each
accessor method must match, except for case, the name of a column in the result
set. In addition, the data type of the object that an accessor method returns must
be compatible with the data type of the corresponding column in the result set.
v You can put an assignment clause anywhere in a Java program that a Java
assignment statement can appear. However, you cannot put an assignment
clause where a Java assignment expression can appear. For example, you cannot
specify an assignment clause in the control list of a for statement.
Related concepts
“SQLJ and JDBC in the same application” on page 152
Related reference
“SQLJ iterator-conversion-clause”
SQLJ iterator-conversion-clause
The iterator conversion clause converts a JDBC ResultSet to an iterator.
Syntax
CAST
322
host-expression
Application Programming Guide and Reference for Java
Description
host-expression
Identifies the JDBC ResultSet that is to be converted to an SQLJ iterator.
Usage notes
v If the iterator to which the JDBC ResultSet is to be converted is a positioned
iterator, the number of columns in the ResultSet must match the number of
columns in the iterator. In addition, the data type of each column in the
ResultSet must be compatible with the data type of the corresponding column
in the iterator.
v If the iterator is a named iterator, the name of each accessor method must match,
except for case, the name of a column in the ResultSet. In addition, the data
type of the object that an accessor method returns must be compatible with the
data type of the corresponding column in the ResultSet.
v When an iterator that is generated through the iterator conversion clause is
closed, the ResultSet from which the iterator is generated is also closed.
Related concepts
“SQLJ and JDBC in the same application” on page 152
Interfaces and classes in the sqlj.runtime package
The sqlj.runtime package defines the run-time classes and interfaces that are used
directly or indirectly by the SQLJ programmer.
Classes such as AsciiStream are used directly by the SQLJ programmer. Interfaces
such as ResultSetIterator are implemented as part of generated class
declarations.
sqlj.runtime interfaces
The following table summarizes the interfaces in sqlj.runtime.
Table 87. Summary of sqlj.runtime interfaces
Interface name
Purpose
ConnectionContext
Manages the SQL operations that are performed during a connection to a data
source.
ForUpdate
Implemented by iterators that are used in a positioned UPDATE or DELETE
statement.
NamedIterator
Implemented by iterators that are declared as named iterators.
PositionedIterator
Implemented by iterators that are declared as positioned iterators.
ResultSetIterator
Implemented by all iterators to allow query results to be processed using a JDBC
ResultSet.
Scrollable
Provides a set of methods for manipulating scrollable iterators.
sqlj.runtime classes
The following table summarizes the classes in sqlj.runtime.
Table 88. Summary of sqlj.runtime classes
Class name
Purpose
AsciiStream
A class for handling an input stream whose bytes should be interpreted as ASCII.
Chapter 7. JDBC and SQLJ reference information
323
Table 88. Summary of sqlj.runtime classes (continued)
Class name
Purpose
BinaryStream
A class for handling an input stream whose bytes should be interpreted as binary.
CharacterStream
A class for handling an input stream whose bytes should be interpreted as
Character.
DefaultRuntime
Implemented by SQLJ to satisfy the expected runtime behavior of SQLJ for most
JVM environments. This class is for internal use only and is not described in this
documentation.
ExecutionContext
Implemented when an SQLJ execution context is declared, to control the execution
of SQL operations.
Indicator
Defines constants for indicator variable values.
RuntimeContext
Defines system-specific services that are provided by the runtime environment. This
class is for internal use only and is not described in this documentation.
SQLNullException
Derived from the java.sql.SQLException class. An sqlj.runtime.SQLNullException
is thrown when an SQL NULL value is fetched into a host identifier with a Java
primitive type.
StreamWrapper
Wraps a java.io.InputStream instance.
UnicodeStream
A class for handling an input stream whose bytes should be interpreted as Unicode.
sqlj.runtime.ConnectionContext interface
The sqlj.runtime.ConnectionContext interface provides a set of methods that
manage SQL operations that are performed during a session with a specific data
source.
Translation of an SQLJ connection declaration clause causes SQLJ to create a
connection context class. A connection context object maintains a JDBC Connection
object on which dynamic SQL operations can be performed. A connection context
object also maintains a default ExecutionContext object.
Variables
CLOSE_CONNECTION
Format:
public static final boolean CLOSE_CONNECTION=true;
A constant that can be passed to the close method. It indicates that the
underlying JDBC Connection object should be closed.
KEEP_CONNECTION
Format:
public static final boolean KEEP_CONNECTION=false;
A constant that can be passed to the close method. It indicates that the
underlying JDBC Connection object should not be closed.
Methods
close()
Format:
public abstract void close() throws SQLException
Performs the following functions:
v Releases all resources that are used by the given connection context object
324
Application Programming Guide and Reference for Java
v Closes any open ConnectedProfile objects
v Closes the underlying JDBC Connection object
close() is equivalent to close(CLOSE_CONNECTION).
close(boolean)
Format:
public abstract void close (boolean close-connection)
throws SQLException
Performs the following functions:
v Releases all resources that are used by the given connection context object
v Closes any open ConnectedProfile objects
v Closes the underlying JDBC Connection object, depending on the value of
the close-connection parameter
Parameters:
close-connection
Specifies whether the underlying JDBC Connection object is closed when a
connection context object is closed:
CLOSE_CONNECTION
Closes the underlying JDBC Connection object.
KEEP_CONNECTION
Does not close the underlying JDBC Connection object.
getConnectedProfile
Format:
public abstract ConnectedProfile getConnectedProfile(Object profileKey)
throws SQLException
This method is used by code that is generated by the SQLJ translator. It is not
intended for direct use by application programs.
getConnection
Format:
public abstract Connection getConnection()
Returns the underlying JDBC Connection object for the given connection
context object.
getExecutionContext
Format:
public abstract ExecutionContext getExecutionContect()
Returns the default ExecutionContext object that is associated with the given
connection context object.
isClosed
Format:
public abstract boolean isClosed()
Returns true if the given connection context object has been closed. Returns
false if the connection context object has not been closed.
Chapter 7. JDBC and SQLJ reference information
325
Constructors
The following constructors are defined in a concrete implementation of the
ConnectionContext interface that results from translation of the statement #sql
context Ctx;:
Ctx(String, boolean)
Format:
public Ctx(String url, boolean autocommit)
throws SQLException
Parameters:
url The representation of a data source, as specified in the JDBC getConnection
method.
autocommit
Whether autocommit is enabled for the connection. A value of true means
that autocommit is enabled. A value of false means that autocommit is
disabled.
Ctx(String, String, String, boolean)
Format:
public Ctx(String url, String user, String password,
boolean autocommit)
throws SQLException
Parameters:
url The representation of a data source, as specified in the JDBC getConnection
method.
user
The user ID under which the connection to the data source is made.
password
The password for the user ID under which the connection to the data
source is made.
autocommit
Whether autocommit is enabled for the connection. A value of true means
that autocommit is enabled. A value of false means that autocommit is
disabled.
Ctx(String, Properties, boolean)
Format:
public Ctx(String url, Properties info, boolean autocommit)
throws SQLException
Parameters:
url The representation of a data source, as specified in the JDBC getConnection
method.
info
An object that contains a set of driver properties for the connection. Any of
the IBM Data Server Driver for JDBC and SQLJ properties can be specified.
autocommit
Whether autocommit is enabled for the connection. A value of true means
that autocommit is enabled. A value of false means that autocommit is
disabled.
326
Application Programming Guide and Reference for Java
Ctx(Connection)
Format:
public Ctx(java.sql.Connection JDBC-connection-object)
throws SQLException
Parameters:
JDBC-connection-object
A previously created JDBC Connection object.
If the constructor call throws an SQLException, the JDBC Connection object
remains open.
Ctx(ConnectionContext)
Format:
public Ctx(sqlj.runtime.ConnectionContext SQLJ-connection-context-object)
throws SQLException
Parameters:
SQLJ-connection-context-object
A previously created SQLJ ConnectionContext object.
The following constructors are defined in a concrete implementation of the
ConnectionContext interface that results from translation of the statement #sql
context Ctx with (dataSource ="jdbc/TestDS");:
Ctx()
Format:
public Ctx()
throws SQLException
Ctx(String, String)
Format:
public Ctx(String user, String password,
)
throws SQLException
Parameters:
user
The user ID under which the connection to the data source is made.
password
The password for the user ID under which the connection to the data
source is made.
Ctx(Connection)
Format:
public Ctx(java.sql.Connection JDBC-connection-object)
throws SQLException
Parameters:
JDBC-connection-object
A previously created JDBC Connection object.
If the constructor call throws an SQLException, the JDBC Connection object
remains open.
Chapter 7. JDBC and SQLJ reference information
327
Ctx(ConnectionContext)
Format:
public Ctx(sqlj.runtime.ConnectionContext SQLJ-connection-context-object)
throws SQLException
Parameters:
SQLJ-connection-context-object
A previously created SQLJ ConnectionContext object.
Methods
The following additional methods are generated in a concrete implementation of
the ConnectionContext interface that results from translation of the statement #sql
context Ctx;:
getDefaultContext
Format:
public static Ctx getDefaultContext()
Returns the default connection context object for the Ctx class.
getProfileKey
Format:
public static Object getProfileKey(sqlj.runtime.profile.Loader loader,
String profileName) throws SQLException
This method is used by code that is generated by the SQLJ translator. It is not
intended for direct use by application programs.
getProfile
Format:
public static sqlj.runtime.profile.Profile getProfile(Object key)
This method is used by code that is generated by the SQLJ translator. It is not
intended for direct use by application programs.
getTypeMap
Format:
public static java.util.Map getTypeMap()
Returns an instance of a class that implements java.util.Map, which is the
user-defined type map that is associated with the ConnectionContext. If there is
no associated type map, Java null is returned.
This method is used by code that is generated by the SQLJ translator for
executable clauses and iterator declaration clauses, but it can also be invoked
in an SQLJ application for direct use in JDBC statements.
SetDefaultContext
Format:
public static void Ctx setDefaultContext(Ctx default-context)
Sets the default connection context object for the Ctx class.
Recommendation: Do not use this method for multithreaded applications.
Instead, use explicit contexts.
328
Application Programming Guide and Reference for Java
sqlj.runtime.ForUpdate interface
SQLJ implements the sqlj.runtime.ForUpdate interface in SQLJ programs that
contain an iterator declaration clause with implements sqlj.runtime.ForUpdate.
An SQLJ program that does positioned UPDATE or DELETE operations
(UPDATE...WHERE CURRENT OF or DELETE...WHERE CURRENT OF) must
include an iterator declaration clause with implements sqlj.runtime.ForUpdate.
Methods
getCursorName
Format:
public abstract String getCursorName() throws SQLException
This method is used by code that is generated by the SQLJ translator. It is not
intended for direct use by application programs.
sqlj.runtime.NamedIterator interface
The sqlj.runtime.NamedIterator interface is implemented when an SQLJ
application executes an iterator declaration clause for a named iterator.
A named iterator includes result table column names, and the order of the columns
in the iterator is not important.
An implementation of the sqlj.runtime.NamedIterator interface includes an
accessor method for each column in the result table. An accessor method returns
the data from its column of the result table. The name of an accessor method
matches the name of the corresponding column in the named iterator.
Methods (inherited from the ResultSetIterator interface)
close
Format:
public abstract void close() throws SQLException
Releases database resources that the iterator uses.
isClosed
Format:
public abstract boolean isClosed() throws SQLException
Returns a value of true if the close method has been invoked. Returns false if
the close method has not been invoked.
next
Format:
public abstract boolean next() throws SQLException
Advances the iterator to the next row. Before an instance of the next method is
invoked for the first time, the iterator is positioned before the first row of the
result table. next returns a value of true when a next row is available and
false when all rows have been retrieved.
sqlj.runtime.PositionedIterator interface
The sqlj.runtime.PositionedIterator interface is implemented when an SQLJ
application executes an iterator declaration clause for a positioned iterator.
Chapter 7. JDBC and SQLJ reference information
329
The order of columns in a positioned iterator must be the same as the order of
columns in the result table, and a positioned iterator does not include result table
column names.
Methods
sqlj.runtime.PositionedIterator inherits all ResultSetIterator methods, and
includes the following additional method:
endFetch
Format:
public abstract boolean endFetch() throws SQLException
Returns a value of true if the iterator is not positioned on a row. Returns a
value of false if the iterator is positioned on a row.
sqlj.runtime.ResultSetIterator interface
The sqlj.runtime.ResultSetIterator interface is implemented by SQLJ for all
iterator declaration clauses.
An untyped iterator can be generated by declaring an instance of the
sqlj.runtime.ResultSetIterator interface directly. In general, use of untyped
iterators is not recommended.
Variables
ASENSITIVE
Format:
public static final int ASENSITIVE
A constant that can be returned by the getSensitivity method. It indicates that
the iterator is defined as ASENSITIVE.
This value is not returned by IBM Informix.
FETCH_FORWARD
Format:
public static final int FETCH_FORWARD
A constant that can be used by the following methods:
v Set by sqlj.runtime.Scrollable.setFetchDirection and
sqlj.runtime.ExecutionContext.setFetchDirection
v Returned by sqlj.runtime.ExecutionContext.getFetchDirection
It indicates that the iterator fetches rows in a result table in the forward
direction, from first to last.
FETCH_REVERSE
Format:
public static final int FETCH_REVERSE
A constant that can be used by the following methods:
v Set by sqlj.runtime.Scrollable.setFetchDirection and
sqlj.runtime.ExecutionContext.setFetchDirection
v Returned by sqlj.runtime.ExecutionContext.getFetchDirection
It indicates that the iterator fetches rows in a result table in the backward
direction, from last to first.
330
Application Programming Guide and Reference for Java
This value is not returned by IBM Informix.
FETCH_UNKNOWN
Format:
public static final int FETCH_UNKNOWN
A constant that can be used by the following methods:
v Set by sqlj.runtime.Scrollable.setFetchDirection and
sqlj.runtime.ExecutionContext.setFetchDirection
v Returned by sqlj.runtime.ExecutionContext.getFetchDirection
It indicates that the iterator fetches rows in a result table in an unknown order.
This value is not returned by IBM Informix.
INSENSITIVE
Format:
public static final int INSENSITIVE
A constant that can be returned by the getSensitivity method. It indicates that
the iterator is defined as INSENSITIVE.
SENSITIVE
Format:
public static final int SENSITIVE
A constant that can be returned by the getSensitivity method. It indicates that
the iterator is defined as SENSITIVE.
This value is not returned by IBM Informix.
Methods
clearWarnings
Format:
public abstract void clearWarnings() throws SQLException
After clearWarnings is called, getWarnings returns null until a new warning is
reported for the iterator.
close
Format:
public abstract void close() throws SQLException
Closes the iterator and releases underlying database resources.
getFetchSize
Format:
synchronized public int getFetchSize() throws SQLException
Returns the number of rows that should be fetched by SQLJ when more rows
are needed. The returned value is the value that was set by the setFetchSize
method, or 0 if no value was set by setFetchSize.
getResultSet
Format:
public abstract ResultSet getResultSet() throws SQLException
Returns the JDBC ResultSet object that is associated with the iterator.
Chapter 7. JDBC and SQLJ reference information
331
getRow
Format:
synchronized public int getRow() throws SQLException
Returns the current row number. The first row is number 1, the second is
number 2, and so on. If the iterator is not positioned on a row, 0 is returned.
getSensitivity
Format:
synchronized public int getSensitivity() throws SQLException
Returns the sensitivity of the iterator. The sensitivity is determined by the
sensitivity value that was specified or defaulted in the with clause of the
iterator declaration clause.
getWarnings
Format:
public abstract SQLWarning getWarnings() throws SQLException
Returns the first warning that is reported by calls on the iterator. Subsequent
iterator warnings are be chained to this SQLWarning. The warning chain is
automatically cleared each time the iterator moves to a new row.
isClosed
Format:
public abstract boolean isClosed() throws SQLException
Returns a value of true if the iterator is closed. Returns false otherwise.
next
Format:
public abstract boolean next() throws SQLException
Advances the iterator to the next row. Before next is invoked for the first time,
the iterator is positioned before the first row of the result table. next returns a
value of true when a next row is available and false when all rows have been
retrieved.
setFetchSize
Format:
synchronized public void setFetchSize(int number-of-rows) throws SQLException
Gives SQLJ a hint as to the number of rows that should be fetched when more
rows are needed.
Parameters:
number-of-rows
The expected number of rows that SQLJ should fetch for the iterator that is
associated with the given execution context.
If number-of-rows is less than 0 or greater than the maximum number of rows
that can be fetched, an SQLException is thrown.
sqlj.runtime.Scrollable interface
sqlj.runtime.Scrollable provides methods to move around in the result table and
to check the position in the result table.
332
Application Programming Guide and Reference for Java
sqlj.runtime.Scrollable is implemented when a scrollable iterator is declared.
Methods
absolute(int)
Format:
public abstract boolean absolute (int n) throws SQLException
Moves the iterator to a specified row.
If n>0, positions the iterator on row n of the result table. If n<0, and m is the
number of rows in the result table, positions the iterator on row m+n+1 of the
result table.
If the absolute value of n is greater than the number of rows in the result table,
positions the cursor after the last row if n is positive, or before the first row if
n is negative.
absolute(0) is the same as beforeFirst(). absolute(1) is the same as first().
absolute(-1) is the same as last().
Returns true if the iterator is on a row. Otherwise, returns false.
afterLast()
Format:
public abstract void afterLast() throws SQLException
Moves the iterator after the last row of the result table.
beforeFirst()
Format:
public abstract void beforeFirst() throws SQLException
Moves the iterator before the first row of the result table.
first()
Format:
public abstract boolean first() throws SQLException
Moves the iterator to the first row of the result table.
Returns true if the iterator is on a row. Otherwise, returns false.
getFetchDirection()
Format:
public abstract int getFetchDirection() throws SQLException
Returns the fetch direction of the iterator. Possible values are:
sqlj.runtime.ResultSetIterator.FETCH_FORWARD
Rows are processed in a forward direction, from first to last.
sqlj.runtime.ResultSetIterator.FETCH_REVERSE
Rows are processed in a backward direction, from last to first.
sqlj.runtime.ResultSetIterator.FETCH_UNKNOWN
The order of processing is not known.
isAfterLast()
Format:
public abstract boolean isAfterLast() throws SQLException
Chapter 7. JDBC and SQLJ reference information
333
Returns true if the iterator is positioned after the last row of the result table.
Otherwise, returns false.
isBeforeFirst()
Format:
public abstract boolean isBeforeFirst() throws SQLException
Returns true if the iterator is positioned before the first row of the result table.
Otherwise, returns false.
isFirst()
Format:
public abstract boolean isFirst() throws SQLException
Returns true if the iterator is positioned on the first row of the result table.
Otherwise, returns false.
isLast()
Format:
public abstract boolean isLast() throws SQLException
Returns true if the iterator is positioned on the last row of the result table.
Otherwise, returns false.
last()
Format:
public abstract boolean last() throws SQLException
Moves the iterator to the last row of the result table.
Returns true if the iterator is on a row. Otherwise, returns false.
previous()
Format:
public abstract boolean previous() throws SQLException
Moves the iterator to the previous row of the result table.
Returns true if the iterator is on a row. Otherwise, returns false.
relative(int)
Format:
public abstract boolean relative(int n) throws SQLException
If n>0, positions the iterator on the row that is n rows after the current row. If
n<0, positions the iterator on the row that is n rows before the current row. If
n=0, positions the iterator on the current row.
The cursor must be on a valid row of the result table before you can use this
method. If the cursor is before the first row or after the last throw, the method
throws an SQLException.
Suppose that m is the number of rows in the result table and x is the current
row number in the result table. If n>0 and x+n>m, the iterator is positioned
after the last row. If n<0 and x+n<1, the iterator is positioned before the first
row.
Returns true if the iterator is on a row. Otherwise, returns false.
setFetchDirection(int)
Format:
334
Application Programming Guide and Reference for Java
public abstract void setFetchDirection (int) throws SQLException
Gives the SQLJ runtime environment a hint as to the direction in which rows
of this iterator object are processed. Possible values are:
sqlj.runtime.ResultSetIterator.FETCH_FORWARD
Rows are processed in a forward direction, from first to last.
sqlj.runtime.ResultSetIterator.FETCH_REVERSE
Rows are processed in a backward direction, from last to first.
sqlj.runtime.ResultSetIterator.FETCH_UNKNOWN
The order of processing is not known.
sqlj.runtime.AsciiStream class
The sqlj.runtime.AsciiStream class is for an input stream of ASCII data with a
specified length.
The sqlj.runtime.AsciiStream class is derived from the java.io.InputStream
class, and extends the sqlj.runtime.StreamWrapper class. SQLJ interprets the bytes
in an sqlj.runtime.AsciiStream object as ASCII characters. An InputStream object
with ASCII characters needs to be passed as a sqlj.runtime.AsciiStream object.
Constructors
AsciiStream(InputStream)
Format:
public AsciiStream(java.io.InputStream input-stream)
Creates an ASCII java.io.InputStream object with an unspecified length.
Parameters:
input-stream
The InputStream object that SQLJ interprets as an AsciiStream object.
AsciiStream(InputStream, int)
Format:
public AsciiStream(java.io.InputStream input-stream, int length)
Creates an ASCII java.io.InputStream object with a specified length.
Parameters:
input-stream
The InputStream object that SQLJ interprets as an AsciiStream object.
length
The length of the InputStream object that SQLJ interprets as an
AsciiStream object.
sqlj.runtime.BinaryStream class
The sqlj.runtime.BinaryStream class is for an input stream of binary data with a
specified length.
The sqlj.runtime.BinaryStream class is derived from the java.io.InputStream class,
and extends the sqlj.runtime.StreamWrapper class. SQLJ interprets the bytes in an
sqlj.runtime.BinaryStream object are interpreted as Binary characters. An
InputStream object with Binary characters needs to be passed as a
sqlj.runtime.BinaryStream object.
Chapter 7. JDBC and SQLJ reference information
335
Constructors
BinaryStream(InputStream)
Format:
public BinaryStream(java.io.InputStream input-stream)
Creates an Binary java.io.InputStream object with an unspecified length.
Parameters:
input-stream
The InputStream object that SQLJ interprets as an BinaryStream object.
BinaryStream(InputStream, int)
Format:
public BinaryStream(java.io.InputStream input-stream, int length)
Creates an Binary java.io.InputStream object with a specified length.
Parameters:
input-stream
The InputStream object that SQLJ interprets as an BinaryStream object.
length
The length of the InputStream object that SQLJ interprets as an
BinaryStream object.
sqlj.runtime.CharacterStream class
The sqlj.runtime.CharacterStream class is for an input stream of character data
with a specified length.
The sqlj.runtime.CharacterStream class is derived from the java.io.Reader class,
and extends the java.io.FilterReader class. SQLJ interprets the bytes in an
sqlj.runtime.CharacterStream object are interpreted as Unicode data. A Reader
object with Unicode data needs to be passed as a sqlj.runtime.CharacterStream
object.
Constructors
CharacterStream(InputStream)
Format:
public CharacterStream(java.io.Reader input-stream)
Creates a character java.io.Reader object with an unspecified length.
Parameters:
input-stream
The Reader object that SQLJ interprets as an CharacterStream object.
CharacterStream(InputStream, int)
Format:
public CharacterStream(java.io.Reader input-stream, int length)
Creates a character java.io.Reader object with a specified length.
Parameters:
input-stream
The Reader object that SQLJ interprets as an CharacterStream object.
336
Application Programming Guide and Reference for Java
length
The length of the Reader object that SQLJ interprets as an CharacterStream
object.
Methods
getReader
Format:
public Reader getReader()
Returns the underlying Reader object that is wrapped by the CharacterStream
object.
getLength
Format:
public void getLength()
Returns the length in characters of the wrapped Reader object, as specified by
the constructor or in the last call to setLength.
setLength
Format:
public void setLength (int length)
Sets the number of characters that are read from the Reader object when the
object is passed as an input argument to an SQL operation.
Parameters:
length
The number of characters that are read from the Reader object.
sqlj.runtime.ExecutionContext class
The sqlj.runtime.ExecutionContext class is defined for execution contexts. An
execution context is used to control the execution of SQL statements.
Variables
ADD_BATCH_COUNT
Format:
public static final int ADD_BATCH_COUNT
A constant that can be returned by the getUpdateCount method. It indicates
that the previous statement was not executed but was added to the existing
statement batch.
AUTO_BATCH
Format:
public static final int AUTO_BATCH
A constant that can be passed to the setBatchLimit method. It indicates that
implicit batch execution should be performed, and that SQLJ should determine
the batch size.
DBDefault
Format:
public static final short DBDefault=-5;
Chapter 7. JDBC and SQLJ reference information
337
A constant that can be assigned to an indicator variable. It specifies that the
corresponding host variable value that is passed to the data server is the
default value.
DBNonNull
Format:
public static final short DBNonNull=0;
A constant that can be assigned to an indicator variable. It specifies that the
corresponding host variable value that is passed to the data server is a
non-null value.
DBNull
Format:
public static final short DBNull=-1;
A constant that can be assigned to an indicator variable. It specifies that the
corresponding host variable value that is passed to the data server is the SQL
NULL value.
DBUnassigned
Format:
public static final short DBUnassigned=-7;
A constant that can be assigned to an indicator variable. It specifies that no
value for the corresponding host variable is passed to the data server.
EXEC_BATCH_COUNT
Format:
public static final int EXEC_BATCH_COUNT
A constant that can be returned from the getUpdateCount method. It indicates
that a statement batch was just executed.
EXCEPTION_COUNT
Format:
public static final int EXCEPTION_COUNT
A constant that can be returned from the getUpdateCount method. It indicates
that an exception was thrown before the previous execution completed, or that
no operation has been performed on the execution context object.
NEW_BATCH_COUNT
Format:
public static final int NEW_BATCH_COUNT
A constant that can be returned from the getUpdateCount method. It indicates
that the previous statement was not executed, but was added to a new
statement batch.
QUERY_COUNT
Format:
public static final int QUERY_COUNT
A constant that can be passed to the setBatchLimit method. It indicates that the
previous execution produced a result set.
UNLIMITED_BATCH
Format:
338
Application Programming Guide and Reference for Java
public static final int UNLIMITED_BATCH
A constant that can be returned from the getUpdateCount method. It indicates
that statements should continue to be added to a statement batch, regardless of
the batch size.
Constructors:
ExecutionContext
Format:
public ExecutionContext()
Creates an ExecutionContext instance.
Methods
cancel
Format:
public void cancel() throws SQLException
Cancels an SQL operation that is currently being executed by a thread that
uses the execution context object. If there is a pending statement batch on the
execution context object, the statement batch is canceled and cleared.
The cancel method throws an SQLException if the statement cannot be
canceled.
execute
Format:
public boolean execute ( ) throws SQLException
This method is used by code that is generated by the SQLJ translator. It is not
intended for direct use by application programs.
executeBatch
Format:
public synchronized int[] executeBatch() throws SQLException
Executes the pending statement batch and returns an array of update counts. If
no pending statement batch exists, null is returned. When this method is
called, the statement batch is cleared, even if the call results in an exception.
Each element in the returned array can be one of the following values:
-2 This value indicates that the SQL statement executed successfully, but the
number of rows that were updated could not be determined.
-3 This value indicates that the SQL statement failed.
Other integer
This value is the number of rows that were updated by the statement.
The executeBatch method throws an SQLException if a database error occurs
while the statement batch executes.
executeQuery
Format:
public RTResultSet executeQuery ( ) throws SQLException
This method is used by code that is generated by the SQLJ translator. It is not
intended for direct use by application programs.
Chapter 7. JDBC and SQLJ reference information
339
executeUpdate
Format:
public int executeUpdate() throws SQLException
This method is used by code that is generated by the SQLJ translator. It is not
intended for direct use by application programs.
getBatchLimit
Format:
synchronized public int getBatchLimit()
Returns the number of statements that are added to a batch before the batch is
implicitly executed.
The returned value is one of the following values:
UNLIMITED_BATCH
This value indicates that the batch size is unlimited.
AUTO_BATCH
This value indicates that the batch size is finite but unknown.
Other integer
The current batch limit.
getBatchUpdateCounts
Format:
public synchronized int[] getBatchUpdateCounts()
Returns an array that contains the number of rows that were updated by each
statement that successfully executed in a batch. The order of elements in the
array corresponds to the order in which statements were inserted into the
batch. Returns null if no statements in the batch completed successfully.
Each element in the returned array can be one of the following values:
-2 This value indicates that the SQL statement executed successfully, but the
number of rows that were updated could not be determined.
-3 This value indicates that the SQL statement failed.
Other integer
This value is the number of rows that were updated by the statement.
getFetchDirection
Format:
synchronized public int getFetchDirection() throws SQLException
Returns the current fetch direction for scrollable iterator objects that were
generated from the given execution context. If a fetch direction was not set for
the execution context, sqlj.runtime.ResultSetIterator.FETCH_FORWARD is
returned.
getFetchSize
Format:
synchronized public int getFetchSize() throws SQLException
Returns the number of rows that should be fetched by SQLJ when more rows
are needed. This value applies only to iterator objects that were generated from
the given execution context. The returned value is the value that was set by the
setFetchSize method, or 0 if no value was set by setFetchSize.
340
Application Programming Guide and Reference for Java
getMaxFieldSize
Format:
public synchronized int getMaxFieldSize()
Returns the maximum number of bytes that are returned for any string
(character, graphic, or varying-length binary) column in queries that use the
given execution context. If this limit is exceeded, SQLJ discards the remaining
bytes. A value of 0 means that the maximum number of bytes is unlimited.
getMaxRows
Format:
public synchronized int getMaxRows()
Returns the maximum number of rows that are returned for any query that
uses the given execution context. If this limit is exceeded, SQLJ discards the
remaining rows. A value of 0 means that the maximum number of rows is
unlimited.
getNextResultSet()
Format:
public ResultSet getNextResultSet() throws SQLException
After a stored procedure call, returns a result set from the stored procedure.
A null value is returned if any of the following conditions are true:
v There are no more result sets to be returned.
v The stored procedure call did not produce any result sets.
v A stored procedure call has not been executed under the execution context.
When you invoke getNextResultSet(), SQLJ closes the currently-open result
set and advances to the next result set.
If an error occurs during a call to getNextResultSet, resources for the current
JDBC ResultSet object are released, and an SQLException is thrown.
Subsequent calls to getNextResultSet return null.
getNextResultSet(int)
Formats:
public ResultSet getNextResultSet(int current)
After a stored procedure call, returns a result set from the stored procedure.
A null value is returned if any of the following conditions are true:
v There are no more result sets to be returned.
v The stored procedure call did not produce any result sets.
v A stored procedure call has not been executed under the execution context.
If an error occurs during a call to getNextResultSet, resources for the current
JDBC ResultSet object are released, and an SQLException is thrown.
Subsequent calls to getNextResultSet return null.
Parameters:
current
Indicates what SQLJ does with the currently open result set before it
advances to the next result set:
Chapter 7. JDBC and SQLJ reference information
341
java.sql.Statement.CLOSE_CURRENT_RESULT
Specifies that the current ResultSet object is closed when the next
ResultSet object is returned.
java.sql.Statement.KEEP_CURRENT_RESULT
Specifies that the current ResultSet object stays open when the next
ResultSet object is returned.
java.sql.Statement.CLOSE_ALL_RESULTS
Specifies that all open ResultSet objects are closed when the next
ResultSet object is returned.
getQueryTimeout
Format:
public synchronized int getQueryTimeout()
Returns the maximum number of seconds that SQL operations that use the
given execution context object can execute. If an SQL operation exceeds the
limit, an SQLException is thrown. The returned value is the value that was set
by the setQueryTimeout method, or 0 if no value was set by setQueryTimeout.
0 means that execution time is unlimited.
getUpdateCount
Format:
public abstract int getUpdateCount() throws SQLException
Returns:
ExecutionContext.ADD_BATCH_COUNT
If the statement was added to an existing batch.
ExecutionContext.NEW_BATCH_COUNT
If the statement was the first statement in a new batch.
ExecutionContext.EXCEPTION_COUNT
If the previous statement generated an SQLException, or no previous
statement was executed.
ExecutionContext.EXEC_BATCH_COUNT
If the statement was part of a batch, and the batch was executed.
ExecutionContext.QUERY_COUNT
If the previous statement created an iterator object or JDBC ResultSet.
Other integer
If the statement was executed rather than added to a batch. This value is
the number of rows that were updated by the statement.
getWarnings
Format:
public synchronized SQLWarning getWarnings()
Returns the first warning that was reported by the last SQL operation that was
executed using the given execution context. Subsequent warnings are chained
to the first warning. If no warnings occurred, null is returned.
getWarnings is used to retrieve positive SQLCODEs.
isBatching
Format:
public synchronized boolean isBatching()
342
Application Programming Guide and Reference for Java
Returns true if batching is enabled for the execution context. Returns false if
batching is disabled.
registerStatement
Format:
public RTStatement registerStatement(ConnectionContext connCtx,
Object profileKey, int stmtNdx)
throws SQLException
This method is used by code that is generated by the SQLJ translator. It is not
intended for direct use by application programs.
releaseStatement
Format:
public void releaseStatement() throws SQLException
This method is used by code that is generated by the SQLJ translator. It is not
intended for direct use by application programs.
setBatching
Format:
public synchronized void setBatching(boolean batching)
Parameters:
batching
Indicates whether batchable statements that are registered with the given
execution context can be added to a statement batch:
true
Statements can be added to a statement batch.
false
Statements are executed individually.
setBatching affects only statements that occur in the program after setBatching
is called. It does not affect previous statements or an existing statement batch.
setBatchLimit
Format:
public synchronized void setBatchLimit(int batch-size)
Sets the maximum number of statements that are added to a batch before the
batch is implicitly executed.
Parameters:
batch-size
One of the following values:
ExecutionContext.UNLIMITED_BATCH
Indicates that implicit execution occurs only when SQLJ encounters a
statement that is batchable but incompatible, or not batchable. Setting
this value is the same as not invoking setBatchLimit.
ExecutionContext.AUTO_BATCH
Indicates that implicit execution occurs when the number of statements
in the batch reaches a number that is set by SQLJ.
Positive integer
The number of statements that are added to the batch before SQLJ
executes the batch implicitly. The batch might be executed before this
Chapter 7. JDBC and SQLJ reference information
343
many statements have been added if SQLJ encounters a statement that
is batchable but incompatible, or not batchable.
setBatchLimit affects only statements that occur in the program after
setBatchLimit is called. It does not affect an existing statement batch.
setFetchDirection
Format:
public synchronized void setFetchDirection(int direction) throws SQLException
Gives SQLJ a hint as to the current fetch direction for scrollable iterator objects
that were generated from the given execution context.
Parameters:
direction
One of the following values:
sqlj.runtime.ResultSetIterator.FETCH_FORWARD
Rows are fetched in a forward direction. This is the default.
sqlj.runtime.ResultSetIterator.FETCH_REVERSE
Rows are fetched in a backward direction.
sqlj.runtime.ResultSetIterator.FETCH_UNKNOWN
The order of fetching is unknown.
Any other input value results in an SQLException.
setFetchSize
Format:
synchronized public void setFetchSize(int number-of-rows) throws SQLException
Gives SQLJ a hint as to the number of rows that should be fetched when more
rows are needed.
Parameters:
number-of-rows
The expected number of rows that SQLJ should fetch for the iterator that is
associated with the given execution context.
If number-of-rows is less than 0 or greater than the maximum number of rows
that can be fetched, an SQLException is thrown.
setMaxFieldSize
Format:
public void setMaxFieldSize(int max-bytes)
Specifies the maximum number of bytes that are returned for any string
(character, graphic, or varying-length binary) column in queries that use the
given execution context. If this limit is exceeded, SQLJ discards the remaining
bytes.
Parameters:
max-bytes
The maximum number of bytes that SQLJ should return from a BINARY,
VARBINARY, CHAR, VARCHAR, GRAPHIC, or VARGRAPHIC column. A
value of 0 means that the number of bytes is unlimited. 0 is the default.
344
Application Programming Guide and Reference for Java
setMaxRows
Format:
public synchronized void setMaxRows(int max-rows)
Specifies the maximum number of rows that are returned for any query that
uses the given execution context. If this limit is exceeded, SQLJ discards the
remaining rows.
Parameters:
max-rows
The maximum number of rows that SQLJ should return for a query that
uses the given execution context. A value of 0 means that the number of
rows is unlimited. 0 is the default.
setQueryTimeout
Format:
public synchronized void setQueryTimeout(int timeout-value)
Specifies the maximum number of seconds that SQL operations that use the
given execution context object can execute. If an SQL operation exceeds the
limit, an SQLException is thrown.
Parameters:
timeout-value
The maximum number of seconds that SQL operations that use the given
execution context object can execute. 0 means that execution time is
unlimited. 0 is the default. For IBM Data Server Driver for JDBC and SQLJ
type 2 connectivity on DB2 for z/OS database servers, 0 is the only valid
value.
Related tasks
“Controlling the execution of SQL statements in SQLJ” on page 155
sqlj.runtime.SQLNullException class
The sqlj.runtime.SQLNullException class is derived from the
java.sql.SQLException class.
An sqlj.runtime.SQLNullException is thrown when an SQL NULL value is fetched
into a host identifier with a Java primitive type. The SQLSTATE value for an
instance of SQLNullException is '22002'.
sqlj.runtime.StreamWrapper class
The sqlj.runtime.StreamWrapper class wraps a java.io.InputStream instance and
extends the java.io.InputStream class.
The sqlj.runtime.AsciiStream, sqlj.runtime.BinaryStream, and
sqlj.runtime.UnicodeStream classes extend sqlj.runtime.StreamWrapper.
sqlj.runtime.StreamWrapper supports methods for specifying the length of
sqlj.runtime.AsciiStream, sqlj.runtime.BinaryStream, and
sqlj.runtime.UnicodeStream objects.
Constructors
StreamWrapper(InputStream)
Format:
protected StreamWrapper(InputStream input-stream)
Chapter 7. JDBC and SQLJ reference information
345
Creates an sqlj.runtime.StreamWrapper object with an unspecified length.
Parameters:
input-stream
The InputStream object that the sqlj.runtime.StreamWrapper object wraps.
StreamWrapper(InputStream, int)
Format:
protected StreamWrapper(java.io.InputStream input-stream, int length)
Creates an sqlj.runtime.StreamWrapper object with a specified length.
Parameters:
input-stream
The InputStream object that the sqlj.runtime.StreamWrapper object wraps.
length
The length of the InputStream object in bytes.
Methods
getInputStream
Format:
public InputStream getInputStream()
Returns the underlying InputStream object that is wrapped by the
StreamWrapper object.
getLength
Format:
public void getLength()
Returns the length in bytes of the wrapped InputStream object, as specified by
the constructor or in the last call to setLength.
setLength
Format:
public void setLength (int length)
Sets the number of bytes that are read from the wrapped InputStream object
when the object is passed as an input argument to an SQL operation.
Parameters:
length
The number of bytes that are read from the wrapped InputStream object.
Related reference
“sqlj.runtime.AsciiStream class” on page 335
“sqlj.runtime.BinaryStream class” on page 335
“sqlj.runtime.CharacterStream class” on page 336
“sqlj.runtime.UnicodeStream class”
sqlj.runtime.UnicodeStream class
The sqlj.runtime.UnicodeStream class is for an input stream of Unicode data with
a specified length.
346
Application Programming Guide and Reference for Java
The sqlj.runtime.UnicodeStream class is derived from the java.io.InputStream
class, and extends the sqlj.runtime.StreamWrapper class. SQLJ interprets the bytes
in an sqlj.runtime.UnicodeStream object as Unicode characters. An InputStream
object with Unicode characters needs to be passed as a
sqlj.runtime.UnicodeStream object.
Constructors
UnicodeStream(InputStream)
Format:
public UnicodeStream(java.io.InputStream input-stream)
Creates a Unicode java.io.InputStream object with an unspecified length.
Parameters:
input-stream
The InputStream object that SQLJ interprets as an UnicodeStream object.
UnicodeStream(InputStream, int)
Format:
public UnicodeStream(java.io.InputStream input-stream, int length)
Creates a Unicode java.io.InputStream object with a specified length.
Parameters:
input-stream
The InputStream object that SQLJ interprets as an UnicodeStream object.
length
The length of the InputStream object that SQLJ interprets as an
UnicodeStream object.
Related reference
“sqlj.runtime.AsciiStream class” on page 335
“sqlj.runtime.BinaryStream class” on page 335
“sqlj.runtime.CharacterStream class” on page 336
“sqlj.runtime.StreamWrapper class” on page 345
IBM Data Server Driver for JDBC and SQLJ extensions to JDBC
The IBM Data Server Driver for JDBC and SQLJ provides a set of extensions to the
support that is provided by the JDBC specification.
To use IBM Data Server Driver for JDBC and SQLJ-only methods in classes that
have corresponding, standard classes, cast an instance of the related, standard
JDBC class to an instance of the IBM Data Server Driver for JDBC and SQLJ-only
class. For example:
javax.sql.DataSource ds =
new com.ibm.db2.jcc.DB2SimpleDataSource();
((com.ibm.db2.jcc.DB2BaseDataSource) ds).setServerName("sysmvs1.stl.ibm.com");
Table 89 on page 348 summarizes the IBM Data Server Driver for JDBC and
SQLJ-only interfaces.
Chapter 7. JDBC and SQLJ reference information
347
Table 89. Summary of IBM Data Server Driver for JDBC and SQLJ-only interfaces provided by the IBM Data Server
Driver for JDBC and SQLJ
Interface name
Applicable data sources
Purpose
DB2CallableStatement
1, 2
Extends the java.sql.CallableStatement and the
com.ibm.db2.jcc.DB2PreparedStatement
interfaces.
DB2Connection
1, 2, 3
Extends the java.sql.Connection interface.
DB2DatabaseMetaData
1, 2, 3
Extends the java.sql.DatabaseMetaData interface.
DB2Diagnosable
1, 2, 3
Provides a mechanism for getting DB2
diagnostics from a DB2 SQLException.
DB2ParameterMetaData
2
Extends the java.sql.ParameterMetaData
interface.
DB2PreparedStatement
1, 2, 3
Extends the com.ibm.db2.jcc.DB2Statement and
java.sql.PreparedStatement interfaces.
DB2ResultSet
1, 2, 3
Extends the java.sql.ResultSet interface.
DB2RowID
1, 2
Used for declaring Java objects for use with the
ROWID data type.
DB2Statement
1, 2, 3
Extends the java.sql.Statement interface.
DB2SystemMonitor
1, 2, 3
Used for collecting system monitoring data for a
connection.
DB2TraceManagerMXBean
1, 2, 3
Provides the MBean interface for the remote trace
controller.
DB2Xml
1, 2
Used for updating data in XML columns and
retrieving data from XML columns.
DBBatchUpdateException
1, 2, 3
Used for retrieving error information about batch
execution of statements that return automatically
generated keys.
Note: The interface applies to connections to the following data sources:
1. DB2 for z/OS
2. DB2 Database for Linux, UNIX, and Windows
3. IBM Informix
Table 90 summarizes the IBM Data Server Driver for JDBC and SQLJ-only classes.
Table 90. Summary of IBM Data Server Driver for JDBC and SQLJ-only classes provided by the IBM Data Server
Driver for JDBC and SQLJ
Class name
Applicable data sources
Purpose
DB2Administrator (DB2 Database
for Linux, UNIX, and Windows
only)
2 on page 349
Instances of the DB2Administrator class are used
to retrieve DB2CataloguedDatabase objects.
DB2BaseDataSource
1 on page 349, 2 on page 349,
3 on page 349
The abstract data source parent class for all IBM
Data Server Driver for JDBC and SQLJ-specific
implementations of javax.sql.DataSource,
javax.sql.ConnectionPoolDataSource, and
javax.sql.XADataSource.
DB2BlobFileReference
1 on page 349
A subclass of DB2FileReference for creating
BLOB file reference variable objects.
DB2CataloguedDatabase
2 on page 349
Contains methods that retrieve information about
a local DB2 Database for Linux, UNIX, and
Windows database.
348
Application Programming Guide and Reference for Java
Table 90. Summary of IBM Data Server Driver for JDBC and SQLJ-only classes provided by the IBM Data Server
Driver for JDBC and SQLJ (continued)
Class name
Applicable data sources
Purpose
DB2ClientRerouteServerList
1, 2
Implements the java.io.Serializable and
javax.naming.Referenceable interfaces.
DB2ClobFileReference
1
A subclass of DB2FileReference for creating
CLOB file reference variable objects.
DB2ConnectionPoolDataSource
1, 2, 3
A factory for PooledConnection objects.
DB2ExceptionFormatter
1, 2, 3
Contains methods for printing diagnostic
information to a stream.
DB2FileReference
1
Provides methods for inserting data into tables
from file reference variables.
DB2JCCPlugin
2
The abstract class for implementation of JDBC
security plug-ins.
DB2PooledConnection
1, 2, 3
Provides methods that an application server can
use to switch users on a preexisting trusted
connection.
DB2PoolMonitor
1, 2
Provides methods for monitoring the global
transport objects pool for the connection
concentrator and Sysplex workload balancing.
DB2SimpleDataSource
1, 2, 3
Extends the DataBaseDataSource class. Does not
support connection pooling or distributed
transactions.
DB2Sqlca
1, 2, 3
An encapsulation of the DB2 SQLCA.
DB2TraceManager
1, 2, 3
Controls the global log writer.
DB2Types
1 on page 348
Defines data type constants.
DB2XADataSource
1, 2, 3
A factory for XADataSource objects. An object that
implements this interface is registered with a
naming service that is based on the Java Naming
and Directory Interface (JNDI).
DB2XmlAsBlobFileReference
1
A subclass of DB2FileReference for creating XML
AS BLOB file reference variable objects.
DB2XmlAsClobFileReference
1
A subclass of DB2FileReference for creating XML
AS CLOB file reference variable objects.
DBTimestamp
1, 2, 3
A subclass of Timestamp that handles timestamp
values with extra precision or time zone
information.
Note: The class applies to connections to the following data sources:
1. DB2 for z/OS
2. DB2 Database for Linux, UNIX, and Windows
3. IBM Informix
DBBatchUpdateException interface
The com.ibm.db2.jcc.DBBatchUpdateException interface is used for retrieving error
information about batch execution of statements that return automatically
generated keys.
Chapter 7. JDBC and SQLJ reference information
349
DBBatchUpdateException methods
The following methods are defined only for the IBM Data Server Driver for JDBC
and SQLJ.
getDBGeneratedKeys
Format:
public java.sql.ResultSet[] getDBGeneratedKeys()
throws java.sql.SQLException
Retrieves automatically generated keys that were created when INSERT
statements were executed in a batch. Each ResultSet object that is returned
contains the automatically generated keys for a single statement in the batch.
ResultSet objects that are null correspond to failed statements.
DB2BaseDataSource class
The com.ibm.db2.jcc.DB2BaseDataSource class is the abstract data source parent
class for all IBM Data Server Driver for JDBC and SQLJ-specific implementations
of javax.sql.DataSource, javax.sql.ConnectionPoolDataSource, and
javax.sql.XADataSource.
DB2BaseDataSource implements the java.sql.Wrapper interface.
DB2BaseDataSource properties
The following properties are defined only for the IBM Data Server Driver for JDBC
and SQLJ.
You can set all properties on a DataSource or in the url parameter in a
DriverManager.getConnection call.
All properties except the following properties have a setXXX method to set the
value of the property and a getXXX method to retrieve the value:
v minTransportObjects
v maxTransportObjectIdleTime
v maxTransportObjectWaitTime
v dumpPool
v dumpPoolStatisticsOnSchedule
v dumpPoolStatisticsOnScheduleFile
v xmlFormat
A setXXX method has this form:
void setProperty-name(data-type property-value)
A getXXX method has this form:
data-type getProperty-name()
Property-name is the unqualified property name. For properties that are not specific
to IBM Informix, the first character of the property name is capitalized. For
properties that are used only by IBM Informix, all characters of the property name
are capitalized.
The following table lists the IBM Data Server Driver for JDBC and SQLJ properties
and their data types.
350
Application Programming Guide and Reference for Java
Table 91. DB2BaseDataSource properties and their data types
Property name
Applicable data
sources
Data type
com.ibm.db2.jcc.DB2BaseDataSource.accountingInterval
1 on page 356
com.ibm.db2.jcc.DB2BaseDataSource.affinityFailbackInterval
1 on page 356, 2 int
on page 356, 3
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.allowNextOnExhaustedResultSet
1 on page 356, 2 int
on page 356, 3
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.allowNullResultSetForExecuteQuery
1 on page 356, 2 int
on page 356, 3
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.atomicMultiRowInsert
1 on page 356, 2 int
on page 356, 3
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.blockingReadConnectionTimeout
1 on page 356, 2 int
on page 356, 3
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.charOutputSize
1 on page 356
com.ibm.db2.jcc.DB2BaseDataSource.clientAccountingInformation
1 on page 356, 2 String
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.clientApplicationInformation
1 on page 356, 2 String
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.clientDebugInfo (IBM Data Server Driver for JDBC
and SQLJ type 4 connectivity)
1 on page 356, 2 String
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.clientProgramId
1 on page 356, 2 String
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.clientProgramName (IBM Data Server Driver for
JDBC and SQLJ type 4 connectivity)
1 on page 356, 2 String
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.clientRerouteAlternateServerName
1 on page 356, 2 String
on page 356, 3
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.clientRerouteAlternatePortNumber
1 on page 356, 2 String
on page 356, 3
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.clientRerouteServerListJNDIContext
1 on page 356, 2 javax.naming.Context
on page 356, 3
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.clientRerouteServerListJNDIName
1 on page 356, 2 String
on page 356, 3
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.clientUser (IBM Data Server Driver for JDBC and
SQLJ type 2 connectivity on DB2 for z/OS only)
1 on page 356
String
com.ibm.db2.jcc.DB2BaseDataSource.clientWorkstation (IBM Data Server Driver for JDBC 1 on page 356
and SQLJ type 2 connectivity on DB2 for z/OS only)
String
String
short
com.ibm.db2.jcc.DB2BaseDataSource.connectionCloseWithInFlightTransaction
1 on page 356, 2 String
on page 356, 3
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.concurrentAccessResolution
1 on page 356, 2 int
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.connectNode
2 on page 356
com.ibm.db2.jcc.DB2BaseDataSource.currentDegree
1 on page 356, 2 String
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.currentExplainMode
1 on page 356, 2 String
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.currentExplainSnapshot
2 on page 356
int
String
Chapter 7. JDBC and SQLJ reference information
351
Table 91. DB2BaseDataSource properties and their data types (continued)
Property name
Applicable data
sources
Data type
com.ibm.db2.jcc.DB2BaseDataSource.currentFunctionPath
1 on page 356, 2 String
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.currentLockTimeout
2 on page 356, 3 int
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.currentMaintainedTableTypesForOptimization
1 on page 356, 2 String
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.currentPackagePath
1 on page 356, 2 String
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.currentPackageSet
1 on page 356, 2 String
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.currentQueryOptimization
2 on page 356
com.ibm.db2.jcc.DB2BaseDataSource.currentRefreshAge
1 on page 356, 2 long
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.currentSchema
1 on page 356, 2 String
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.cursorSensitivity
1 on page 356, 2 int
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.currentSQLID
1 on page 356
com.ibm.db2.jcc.DB2BaseDataSource.databaseName
1 on page 356, 2 String
on page 356, 3
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.dateFormat
1 on page 356, 2 int
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.decimalRoundingMode
1 on page 356, 2 int
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.decimalSeparator
1 on page 356, 2 int
on page 356, 3
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.decimalStringFormat
1 on page 356, 2 int
on page 356, 3
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.defaultIsolationLevel
1 on page 356, 2 int
on page 356, 3
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.deferPrepares
1 on page 356, 2 boolean
on page 356, 3
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.description
1 on page 356, 2 String
on page 356, 3
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.downgradeHoldCursorsUnderXa
1 on page 356, 2 boolean
on page 356,3
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.driverType
1 on page 356, 2 int
on page 356, 3
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.dumpPool
3 on page 356
int
com.ibm.db2.jcc.DB2BaseDataSource.dumpPoolStatisticsOnSchedule
3 on page 356
int
com.ibm.db2.jcc.DB2BaseDataSource.dumpPoolStatisticsOnScheduleFile
3 on page 356
String
com.ibm.db2.jcc.DB2BaseDataSource.enableClientAffinitiesList
1 on page 356, 2 int
on page 356, 3
on page 356
352
Application Programming Guide and Reference for Java
int
String
Table 91. DB2BaseDataSource properties and their data types (continued)
Applicable data
sources
Data type
Property name
com.ibm.db2.jcc.DB2BaseDataSource.enableExtendedIndicators
1 on page 356, 2 int
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.enableNamedParameterMarkers
1 on page 356, 2 int
on page 356, 3
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.enableConnectionConcentrator (IBM Data Server
Driver for JDBC and SQLJ type 4 connectivity)
1 on page 356, 3 boolean
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.enableMultiRowInsertSupport
1 on page 356
com.ibm.db2.jcc.DB2BaseDataSource.enableRowsetSupport
1 on page 356, 2 int
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.enableSeamlessFailover
1 on page 356, 2 int
on page 356, 3
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.enableSysplexWLB (IBM Data Server Driver for
JDBC and SQLJ type 4 connectivity)
1 on page 356, 2 boolean
on page 356, 3
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.encryptionAlgorithm
1 on page 356, 2 int
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.fetchSize
1 on page 356, 2 int
on page 356, 3
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.floatingPointStringFormat
1 on page 356, 2 int
on page 356, 3
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.fullyMaterializeInputStreams
1 on page 356, 2 boolean
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.fullyMaterializeLobData
1 on page 356, 2 boolean
on page 356, 3
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.gssCredential
1 on page 356, 2 Object
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.interruptProcessingMode (IBM Data Server Driver
for JDBC and SQLJ type 4 connectivity)
1 on page 356, 2 int
on page 356, 3
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.jdbcCollection
1 on page 356
com.ibm.db2.jcc.DB2BaseDataSource.keepDynamic
1 on page 356, 3 int
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.kerberosServerPrincipal
1 on page 356, 2 String
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.loginTimeout (not supported for IBM Data Server
Driver for JDBC and SQLJ type 2 connectivity on DB2 for z/OS)
1 on page 356, 2 int
on page 356, 3
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.logWriter
1 on page 356, 2 PrintWriter
on page 356, 3
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.maxRetriesForClientReroute
1 on page 356, 2 int
on page 356, 3
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.maxRowsetSize (IBM Data Server Driver for JDBC
and SQLJ type 2 connectivity on DB2 for z/OS only)
1 on page 356
int
com.ibm.db2.jcc.DB2BaseDataSource.maxTransportObjectIdleTime
3 on page 356
int
com.ibm.db2.jcc.DB2BaseDataSource.maxTransportObjectWaitTime
3 on page 356
int
com.ibm.db2.jcc.DB2BaseDataSource.maxTransportObjects
1 on page 356, 3 int
on page 356
boolean
String
Chapter 7. JDBC and SQLJ reference information
353
Table 91. DB2BaseDataSource properties and their data types (continued)
Property name
Applicable data
sources
Data type
com.ibm.db2.jcc.DB2BaseDataSource.minTransportObjects
3 on page 356
int
com.ibm.db2.jcc.DB2BaseDataSource.optimizationProfile
2 on page 356
String
com.ibm.db2.jcc.DB2BaseDataSource.optimizationProfileToFlush
2 on page 356
String
com.ibm.db2.jcc.DB2BaseDataSource.password
1 on page 356, 2 String
on page 356, 3
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.pdqProperties
1 on page 356, 2 String
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.pkList (IBM Data Server Driver for JDBC and SQLJ
type 2 connectivity)
1 on page 356
String
com.ibm.db2.jcc.DB2BaseDataSource.planName (IBM Data Server Driver for JDBC and
SQLJ type 2 connectivity only)
1 on page 356
String
com.ibm.db2.jcc.DB2BaseDataSource.plugin
2 on page 356
Object
com.ibm.db2.jcc.DB2BaseDataSource.pluginName
2 on page 356
String
com.ibm.db2.jcc.DB2BaseDataSource.portNumber
1 on page 356, 2 int
on page 356, 3
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.progressiveStreaming
1 on page 356, 2 int
on page 356, 3
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.queryCloseImplicit
1 on page 356, 2 int
on page 356, 3
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.queryDataSize
1 on page 356, 2 int
on page 356, 3
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.readOnly
1 on page 356, 2 boolean
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.reportLongTypes
1 on page 356
com.ibm.db2.jcc.DB2BaseDataSource.resultSetHoldability
1 on page 356, 2 int
on page 356,3
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.resultSetHoldabilityForCatalogQueries
1 on page 356, 2 int
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.retrieveMessagesFromServerOnGetMessage
1 on page 356, 2 boolean
on page 356, 3
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.retryIntervalForClientReroute
1 on page 356, 2 int
on page 356, 3
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.retryWithAlternativeSecurityMechanism (IBM Data
Server Driver for JDBC and SQLJ type 4 connectivity)
2 on page 356
com.ibm.db2.jcc.DB2BaseDataSource.returnAlias
1 on page 356, 2 short
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.securityMechanism
1 on page 356, 2 int
on page 356, 3
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.sendCharInputsUTF8
1 on page 356
com.ibm.db2.jcc.DB2BaseDataSource.sendDataAsIs
1 on page 356, 2 boolean
on page 356, 3
on page 356
354
Application Programming Guide and Reference for Java
short
int
int
Table 91. DB2BaseDataSource properties and their data types (continued)
Applicable data
sources
Data type
Property name
com.ibm.db2.jcc.DB2BaseDataSource.serverName
1 on page 356, 2 String
on page 356, 3
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.sessionTimeZone
1 on page 356
String
com.ibm.db2.jcc.DB2BaseDataSource.sqljEnableClassLoaderSpecificProfiles
1 on page 356
boolean
com.ibm.db2.jcc.DB2BaseDataSource.ssid (IBM Data Server Driver for JDBC and SQLJ
type 2 connectivity on DB2 for z/OS only)
1 on page 356
String
com.ibm.db2.jcc.DB2BaseDataSource.sslConnection (IBM Data Server Driver for JDBC
and SQLJ type 4 connectivity)
1 on page 356, 2 boolean
on page 356, 3
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.sslTrustStoreLocation (IBM Data Server Driver for
JDBC and SQLJ type 4 connectivity)
1 on page 356, 2 String
on page 356, 3
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.sslTrustStorePassword (IBM Data Server Driver for
JDBC and SQLJ type 4 connectivity)
1 on page 356, 2 String
on page 356, 3
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.statementConcentrator
1 on page 356, 2 int
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.streamBufferSize
1 on page 356, 2 int
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.stripTrailingZerosForDecimalNumbers
1 on page 356, 2 int
on page 356, 3
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.supportsAsynchronousXARollback
1 on page 356, 2 int
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.sysSchema
1 on page 356, 2 String
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.timeFormat
1 on page 356, 2 int
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.timestampFormat
1 on page 356, 2 int
on page 356, 3
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.timestampOutputType
1 on page 356
com.ibm.db2.jcc.DB2BaseDataSource.timestampPrecisionReporting
1 on page 356, 2 int
on page 356, 3
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.traceDirectory
1 on page 356, 2 String
on page 356, 3
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.traceFile
1 on page 356, 2 String
on page 356, 3
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.traceFileAppend
1 on page 356, 2 boolean
on page 356, 3
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.traceLevel
1 on page 356, 2 int
on page 356, 3
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.useCachedCursor
1 on page 356, 2 boolean
on page 356
com.ibm.db2.jcc.DB2BaseDataSource.useJDBC4ColumnNameAndLabelSemantics
1 on page 356, 2 int
on page 356
int
Chapter 7. JDBC and SQLJ reference information
355
Table 91. DB2BaseDataSource properties and their data types (continued)
Applicable data
sources
Data type
Property name
com.ibm.db2.jcc.DB2BaseDataSource.user
1, 2, 3
String
com.ibm.db2.jcc.DB2BaseDataSource.useIdentityValLocalForAutoGeneratedKeys
1
boolean
com.ibm.db2.jcc.DB2BaseDataSource.useRowsetCursor
1
boolean
com.ibm.db2.jcc.DB2BaseDataSource.useTransactionRedirect
2
boolean
com.ibm.db2.jcc.DB2BaseDataSource.xaNetworkOptimization
1, 2, 3
boolean
com.ibm.db2.jcc.DB2BaseDataSource.xmlFormat
1
int
com.ibm.db2.jcc.DB2BaseDataSource.DBANSIWARN
3
boolean
com.ibm.db2.jcc.DB2BaseDataSource.DBDATE
3
String
com.ibm.db2.jcc.DB2BaseDataSource.DBPATH
3
String
com.ibm.db2.jcc.DB2BaseDataSource.DBSPACETEMP
3
String
com.ibm.db2.jcc.DB2BaseDataSource.DBTEMP
3
String
com.ibm.db2.jcc.DB2BaseDataSource.DBUPSPACE
3
String
com.ibm.db2.jcc.DB2BaseDataSource.DELIMIDENT
3
boolean
com.ibm.db2.jcc.DB2BaseDataSource.IFX_DIRECTIVES
3
String
com.ibm.db2.jcc.DB2BaseDataSource.IFX_EXTDIRECTIVES
3
String
com.ibm.db2.jcc.DB2BaseDataSource.IFX_UPDDESC
3
String
com.ibm.db2.jcc.DB2BaseDataSource.IFX_XASTDCOMPLIANCE_XAEND
3
String
com.ibm.db2.jcc.DB2BaseDataSource.INFORMIXOPCACHE
3
String
com.ibm.db2.jcc.DB2BaseDataSource.INFORMIXSTACKSIZE
3
String
com.ibm.db2.jcc.DB2BaseDataSource.NODEFDAC
3
String
com.ibm.db2.jcc.DB2BaseDataSource.OPTCOMPIND
3
String
com.ibm.db2.jcc.DB2BaseDataSource.OPTOFC
3
String
com.ibm.db2.jcc.DB2BaseDataSource.PDQPRIORITY
3
String
com.ibm.db2.jcc.DB2BaseDataSource.PSORT_DBTEMP
3
String
com.ibm.db2.jcc.DB2BaseDataSource.PSORT_NPROCS
3
String
com.ibm.db2.jcc.DB2BaseDataSource.STMT_CACHE
3
String
Note: The property applies to connections to the following data sources:
1. DB2 for z/OS
2. DB2 Database for Linux, UNIX, and Windows
3. IBM Informix
DB2BaseDataSource fields
The following constants are defined only for the IBM Data Server Driver for JDBC
and SQLJ.
public final static int INTERRUPT_PROCESSING_MODE_DISABLED = 0
A constant for the interruptProcessingMode property. This value indicates that
interrupt processing is disabled.
public final static int
INTERRUPT_PROCESSING_MODE_STATEMENT_CANCEL = 1
A constant for the interruptProcessingMode property. This value indicates that
the IBM Data Server Driver for JDBC and SQLJ cancels the currently executing
statement when an application executes Statement.cancel, if the data server
supports interrupt processing.
356
Application Programming Guide and Reference for Java
public final static int INTERRUPT_PROCESSING_MODE_CLOSE_SOCKET = 2
A constant for the interruptProcessingMode property. This value indicates that
the IBM Data Server Driver for JDBC and SQLJ drops the underlying socket
and closes the connection when an application executes Statement.cancel.
public final static int NO = 2
The NO value for properties.
public final static int NOT_SET = 0
The default value for properties.
public final static int YES = 1
The YES value for properties.
DB2BaseDataSource methods
In addition to the getXXX and setXXX methods for the DB2BaseDataSource
properties, the following methods are defined only for the IBM Data Server Driver
for JDBC and SQLJ.
getReference
Format:
public javax.naming.Reference getReference()
throws javax.naming.NamingException
Retrieves the Reference of a DataSource object. For an explanation of a
Reference, see the description of javax.naming.Referenceable in the JNDI
documentation at:
http://java.sun.com/products/jndi/docs.html
Related reference
“Properties for the IBM Data Server Driver for JDBC and SQLJ” on page 221
DB2BlobFileReference class
The com.ibm.db2.jcc.DB2BlobFileReference class is subclass of DB2FileReference
that is used for creating BLOB file reference variable objects. This class applies only
to IBM Data Server Driver for JDBC and SQLJ type 2 connectivity to DB2 for z/OS
Version 9 or later.
DB2BlobFileReference constructor
The following constructor is defined only for the IBM Data Server Driver for JDBC
and SQLJ.
DB2BlobFileReference
Format:
public DB2BlobFileReference(String fileName)
throws java.sql.SQLException
Constructs a DB2BlobFileReference object for a BLOB file reference variable.
Parameter descriptions:
fileName
The name of the file for the file reference variable. The name must specify
the absolute path name for an existing HFS file.
Chapter 7. JDBC and SQLJ reference information
357
DB2CallableStatement interface
The com.ibm.db2.jcc.DB2CallableStatement interface extends the
java.sql.CallableStatement and the com.ibm.db2.jcc.DB2PreparedStatement
interfaces.
DB2CallableStatement methods
The following methods are defined only for the IBM Data Server Driver for JDBC
and SQLJ.
getDBTimestamp
Formats:
public DBTimestamp getDBTimestamp(int parameterIndex)
throws SQLException
public DBTimestamp getDBTimestamp(String parameterName)
throws SQLException
Returns the value of a TIMESTAMP OUT or INOUT parameter as a
DBTimestamp object. If the value of the parameter is NULL, the returned value
is null.
Parameters:
parameterIndex
The number of the parameter whose value is being retrieved.
parameterName
The name of the parameter whose value is being retrieved.
This method is not supported for connections to IBM Informix.
getJccArrayAtName
Format:
public java.sql.Array getJccArrayAtName(String parameterMarkerName)
throws java.sql.SQLException
Retrieves an ARRAY value that is designated by a named parameter marker as
a java.sql.Array value.
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
Parameters:
parameterMarkerName
The name of the parameter marker for which a value is retrieved.
getJccBigDecimalAtName
Format:
public java.math.BigDecimal getJccBigDecimalAtName(String parameterMarkerName)
throws java.sql.SQLException
public java.math.BigDecimal getJccBigDecimalAtName(String parameterMarkerName,
int scale)
throws java.sql.SQLException
Retrieves a DECIMAL value that is designated by a named parameter marker
as a java.math.BigDecimal value.
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
Parameters:
358
Application Programming Guide and Reference for Java
parameterMarkerName
The name of the parameter marker for which a value is retrieved.
scale
The scale of the value that is retrieved.
getJccBlobAtName
Formats:
public java.sql.Blob getJccBlobAtName(String parameterMarkerName)
throws java.sql.SQLException
Retrieves a BLOB value that is designated by a named parameter marker as a
java.sql.Blob value.
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
Parameters:
parameterMarkerName
The name of the parameter marker for which a value is retrieved.
getJccBooleanAtName
Format:
public boolean getJccBooleanAtName(String parameterMarkerName)
throws java.sql.SQLException
Retrieves a BIT or BOOLEAN value that is designated by a named parameter
marker as a boolean value.
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
Parameters:
parameterMarkerName
The name of the parameter marker for which a value is retrieved.
getJccByteAtName
Format:
public byte getJccByteAtName(String parameterMarkerName)
throws java.sql.SQLException
Retrieves a TINYINT value that is designated by a named parameter marker as
a byte value.
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
Parameters:
parameterMarkerName
The name of the parameter marker for which a value is retrieved.
getJccBytesAtName
Format:
public byte[] getJccBytesAtName(String parameterMarkerName)
throws java.sql.SQLException
Retrieves a BINARY or VARBINARY value that is designated by a named
parameter marker as an array of byte values.
Chapter 7. JDBC and SQLJ reference information
359
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
Parameters:
parameterMarkerName
The name of the parameter marker for which a value is retrieved.
getJccClobAtName
Format:
public java.sql.Blob getJccClobAtName(String parameterMarkerName)
throws java.sql.SQLException
Retrieves a CLOB value that is designated by a named parameter marker as a
java.sql.Clob value.
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
Parameters:
parameterMarkerName
The name of the parameter marker for which a value is retrieved.
getJccDateAtName
Formats:
public java.sql.Date getJccDateAtName(String parameterMarkerName)
throws java.sql.SQLException
public java.sql.Date getJccDateAtName(String parameterMarkerName,
java.util.Calendar cal)
throws java.sql.SQLException
Retrieves a DATE value that is designated by a named parameter marker as a
java.sql.Date value.
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
Parameters:
parameterMarkerName
The name of the parameter marker for which a value is retrieved.
cal The java.util.Calendar object that the IBM Data Server Driver for JDBC
and SQLJ uses to construct the date.
getJccDoubleAtName
Format:
public double getJccDoubleAtName(String parameterMarkerName)
throws java.sql.SQLException
Retrieves a DOUBLE value that is designated by a named parameter marker as
a double value.
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
Parameters:
parameterMarkerName
The name of the parameter marker for which a value is retrieved.
getJccFloatAtName
Format:
360
Application Programming Guide and Reference for Java
public double getJccFloatAtName(String parameterMarkerName)
throws java.sql.SQLException
Retrieves a FLOAT value that is designated by a named parameter marker as a
double value.
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
Parameters:
parameterMarkerName
The name of the parameter marker for which a value is retrieved.
getJccIntAtName
Format:
public int getJccIntAtName(String parameterMarkerName)
throws java.sql.SQLException
Retrieves a INTEGER value that is designated by a named parameter marker
as a int value.
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
Parameters:
parameterMarkerName
The name of the parameter marker for which a value is retrieved.
getJccLongAtName
Format:
public long getJccLongAtName(String parameterMarkerName)
throws java.sql.SQLException
Retrieves a BIGINT value that is designated by a named parameter marker as
a long value.
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
Parameters:
parameterMarkerName
The name of the parameter marker for which a value is retrieved.
getJccObjectAtName
Formats:
public java.sql.Object getJccObjectAtName(String parameterMarkerName)
throws java.sql.SQLException
public java.sql.Object getJccObjectAtName(String parameterMarkerName,
Map map)
throws java.sql.SQLException
Retrieves a value that is designated by a named parameter marker as a
java.sql.Object value.
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
Parameters:
parameterMarkerName
The name of the parameter marker for which a value is retrieved.
Chapter 7. JDBC and SQLJ reference information
361
map
The mapping from SQL type names to Java classes.
getJccRowIdAtName
Format:
public java.sql.RowId getJccRowIdAtName(String parameterMarkerName)
throws java.sql.SQLException
Retrieves a ROWID value that is designated by a named parameter marker as
a java.sql.RowId value.
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
This method requires the IBM Data Server Driver for JDBC and SQLJ Version
4.8 or later.
Parameters:
parameterMarkerName
The name of the parameter marker for which a value is retrieved.
getJccShortAtName
Format:
public short getJccShortAtName(String parameterMarkerName)
throws java.sql.SQLException
Retrieves a SMALLINT value that is designated by a named parameter marker
as a short value.
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
Parameters:
parameterMarkerName
The name of the parameter marker for which a value is retrieved.
getJccSQLXMLAtName
Format:
public java.sql.SQLXML getJccSQLXMLAtName(String parameterMarkerName)
throws java.sql.SQLException
Retrieves a SQLXML value that is designated by a named parameter marker as
a java.sql.SQLXML value.
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
This method requires the IBM Data Server Driver for JDBC and SQLJ Version
4.8 or later.
Parameters:
parameterMarkerName
The name of the parameter marker for which a value is retrieved.
getJccStringAtName
Format:
public java.lang.String getJccStringAtName(String parameterMarkerName)
throws java.sql.SQLException
362
Application Programming Guide and Reference for Java
Retrieves a CHAR, VARcHAR, or LONGVARCHAR value that is designated
by a named parameter marker as a java.lang.String value.
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
Parameters:
parameterMarkerName
The name of the parameter marker for which a value is retrieved.
getJccTimeAtName
Formats:
public java.sql.Time getJccTimeAtName(String parameterMarkerName)
throws java.sql.SQLException
public java.sql.Time getJccTimeAtName(String parameterMarkerName,
java.util.Calendar cal)
throws java.sql.SQLException
Retrieves a TIME value that is designated by a named parameter marker as a
java.sql.Time value.
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
Parameters:
parameterMarkerName
The name of the parameter marker for which a value is retrieved.
cal The java.util.Calendar object that the IBM Data Server Driver for JDBC
and SQLJ uses to construct the time.
getJccTimestampAtName
Formats:
public java.sql.Timestamp getJccTimestampAtName(String parameterMarkerName)
throws java.sql.SQLException
public java.sql.Timestamp getJccTimestampAtName(String parameterMarkerName,
java.util.Calendar cal)
throws java.sql.SQLException
Retrieves a TIMESTAMP value that is designated by a named parameter
marker as a java.sql.Timestamp value.
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
Parameters:
parameterMarkerName
The name of the parameter marker for which a value is retrieved.
cal The java.util.Calendar object that the IBM Data Server Driver for JDBC
and SQLJ uses to construct the timestamp.
registerJccOutParameterAtName
Formats:
public void registerJccOutParameterAtName(String parameterMarkerName,
int sqlType)
throws java.sql.SQLException
public void registerJccOutParameterAtName(String parameterMarkerName,
int sqlType,
int scale)
throws java.sql.SQLException
Chapter 7. JDBC and SQLJ reference information
363
public void registerJccOutParameterAtName(String parameterMarkerName,
int sqlType,
String typeName)
throws java.sql.SQLException
Registers an OUT parameter that is identified by parameterMarkerName as the
JDBC type sqlType.
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
Parameters:
parameterMarkerName
The name of the parameter marker for the parameter that is to be
registered.
sqlType
The JDBC type code, as defined in java.sql.Types, of the parameter that is
to be registered.
scale
The scale of the parameter that is to be registered. This parameter applies
only to this case:
v If sqlType is java.sql.Types.DECIMAL or java.sql.Types.NUMERIC, scale is
the number of digits to the right of the decimal point.
typeName
If jdbcType is java.sql.Types.DISTINCT or java.sql.Types.REF, the
fully-qualified name of the SQL user-defined type of the parameter that is
to be registered.
setDBTimestamp
Format:
public void setDBTimestamp(String parameterName,
DBTimestamp timestamp)
throws java.sql.SQLException
Assigns a DBTimestamp value to an IN or INOUT parameter.
Parameters:
parameterName
The name of the parameter to which a DBTimestamp variable value is
assigned.
timestamp
The DBTimestamp value that is assigned to the parameter.
This method is not supported for connections to IBM Informix.
setJccXXXAtName methods
These methods are inherited from DB2PreparedStatement.
DB2ClientRerouteServerList class
The com.ibm.db2.jcc.DB2ClientRerouteServerList class implements the
java.io.Serializable and javax.naming.Referenceable interfaces.
DB2ClientRerouteServerList methods
getAlternatePortNumber
Format:
364
Application Programming Guide and Reference for Java
public int[] getAlternatePortNumber()
Retrieves the port numbers that are associated with the alternate servers.
getAlternateServerName
Format:
public String[] getAlternateServerName()
Retrieves an array that contains the names of the alternate servers. These
values are IP addresses or DNS server names.
getPrimaryPortNumber
Format:
public int getPrimaryPortNumber()
Retrieves the port number that is associated with the primary server.
getPrimaryServerName
Format:
public String[] getPrimaryServerName()
Retrieves the name of the primary server. This value is an IP address or a DNS
server name.
setAlternatePortNumber
Format:
public void setAlternatePortNumber(int[] alternatePortNumberList)
Sets the port numbers that are associated with the alternate servers.
setAlternateServerName
Format:
public void setAlternateServerName(String[] alternateServer)
Sets the alternate server names for servers. These values are IP addresses or
DNS server names.
setPrimaryPortNumber
Format:
public void setPrimaryPortNumber(int primaryPortNumber)
Sets the port number that is associated with the primary server.
setPrimaryServerName
Format:
public void setPrimaryServerName(String primaryServer)
Sets the primary server name for a server. This value is an IP address or a
DNS server name.
Chapter 7. JDBC and SQLJ reference information
365
Related concepts
Chapter 10, “Java client support for high availability on IBM data servers,” on page
513
DB2ClobFileReference class
The com.ibm.db2.jcc.DB2ClobFileReference class is subclass of DB2FileReference
that is used for creating CLOB file reference variable objects. This class applies
only to IBM Data Server Driver for JDBC and SQLJ type 2 connectivity to DB2 for
z/OS Version 9 or later.
DB2ClobFileReference constructor
The following constructor is defined only for the IBM Data Server Driver for JDBC
and SQLJ.
DB2ClobFileReference
Format:
public DB2ClobFileReference(String fileName,
int fileCcsid)
throws java.sql.SQLException
public DB2ClobFileReference(String fileName,
String fileEncoding)
throws java.sql.SQLException
Constructs a DB2ClobFileReference object for a CLOB file reference variable.
Parameter descriptions:
fileName
The name of the file for the file reference variable. The name must specify
the absolute path name for an existing HFS file.
fileCcsid
The CCSID of the data in the file for the file reference variable.
fileEncoding
The encoding scheme of the data in the file for the file reference variable.
DB2Connection interface
The com.ibm.db2.jcc.DB2Connection interface extends the java.sql.Connection
interface.
DB2Connection implements the java.sql.Wrapper interface.
DB2Connection methods
The following methods are defined only for the IBM Data Server Driver for JDBC
and SQLJ.
alternateWasUsedOnConnect
Format:
public boolean alternateWasUsedOnConnect()
throws java.sql.SQLException
Returns true if the driver used alternate server information to obtain the
connection. The alternate server information is available in the transient
clientRerouteServerList information on the DB2BaseDataSource, which the
database server updates as primary and alternate servers change.
366
Application Programming Guide and Reference for Java
changeDB2Password
Format:
public abstract void changeDB2Password(String oldPassword,
String newPassword)
throws java.sql.SQLException
Changes the password for accessing the data source, for the user of the
Connection object.
Parameter descriptions:
oldPassword
The original password for the Connection.
newPassword
The new password for the Connection.
createArrayOf
Format:
Array createArrayOf(String typeName,
Object[] elements)
throws SQLException;
Creates a java.sql.Array object.
Parameter descriptions:
typeName
The SQL data type of the elements of the array map to. typeName can be a
built-in data type or a distinct type.
elements
The elements that populate the Array object.
deregisterDB2XmlObject
Formats:
public void deregisterDB2XmlObject(String sqlIdSchema,
String sqlIdName)
throws SQLException
Removes a previously registered XML schema from the data source.
Parameter descriptions:
sqlIdSchema
The SQL schema name for the XML schema. sqlIdSchema is a String value
with a maximum length of 128 bytes. The value of sqlIdSchema must be the
string 'SYSXSR' or null. If the value of sqlIdSchema is null, the database
system uses the string 'SYSXSR'.
sqlIdName
The SQL name for the XML schema. sqlIdName is a String value with a
maximum length of 128 bytes. The value of sqlIdName must conform to the
rules for an SQL identifier and cannot be null.
getDB2ClientAccountingInformation
Format:
public String getDB2ClientAccountingInformation()
throws SQLException
Returns accounting information for the current client.
Chapter 7. JDBC and SQLJ reference information
367
Important: getDB2ClientAccountingInformation is deprecated in the JDBC 4.0
implementation of the IBM Data Server Driver for JDBC and SQLJ. Use
java.sql.Connection.getClientInfo instead.
getDB2ClientApplicationInformation
Format:
public String getDB2ClientApplicationInformation()
throws java.sql.SQLException
Returns application information for the current client.
Important: getDB2ClientApplicationInformation is deprecated in the JDBC 4.0
implementation of the IBM Data Server Driver for JDBC and SQLJ. Use
java.sql.Connection.getClientInfo instead.
getDB2ClientProgramId
Format:
public String getDB2ClientProgramId()
throws java.sql.SQLException
Returns the user-defined program identifier for the client. The program
identifier can be used to identify the application at the data source.
getDB2ClientProgramId does not apply to DB2 Database for Linux, UNIX, and
Windows data servers.
getDB2ClientUser
Format:
public String getDB2ClientUser()
throws java.sql.SQLException
Returns the current client user name for the connection. This name is not the
user value for the JDBC connection.
Important: getDB2ClientUser is deprecated in the JDBC 4.0 implementation of
the IBM Data Server Driver for JDBC and SQLJ. Use
java.sql.Connection.getClientInfo instead.
getDB2ClientWorkstation
Format:
public String getDB2ClientWorkstation()
throws java.sql.SQLException
Returns current client workstation name for the current client.
Important: getDB2ClientWorkstation is deprecated in the JDBC 4.0
implementation of the IBM Data Server Driver for JDBC and SQLJ. Use
java.sql.Connection.getClientInfo instead.
getDB2Correlator
Format:
String getDB2Correlator()
throws java.sql.SQLException
Returns the value of the crrtkn (correlation token) instance variable that DRDA
sends with the ACCRDB command. The correlation token uniquely identifies a
logical connection to a server.
getDB2CurrentPackagePath
Format:
368
Application Programming Guide and Reference for Java
public String getDB2CurrentPackagePath()
throws java.sql.SQLException
Returns the list of DB2 package collections that are searched for JDBC and
SQLJ packages.
The getDB2CurrentPackagePath method applies only to connections to DB2
database systems.
getDB2CurrentPackageSet
Format:
public String getDB2CurrentPackageSet()
throws java.sql.SQLException
Returns the collection ID for the connection.
The getDB2CurrentPackageSet method applies only to connections to DB2
database systems.
getDB2ProgressiveStreaming
Format:
public int getDB2ProgressiveStreaming()
throws java.sql.SQLException
Returns the current progressive streaming setting for the connection.
The returned value depends on whether the data source supports progressive
streaming, how the progressiveStreaming property is set, and whether
DB2Connection.setProgressiveStreaming was called:
v If the data source does not support progressive streaming, 2 (NO) is always
returned, regardless of the progressiveStreaming property setting.
v If the data source supports progressive streaming, and
DB2Connection.setProgressiveStreaming was called, the returned value is
the value that DB2Connection.setProgressiveStreaming set.
v If the data source supports progressive streaming, and
DB2Connection.setProgressiveStreaming was not called, the returned value
is 2 (NO) if progressiveStreaming was set to DB2BaseDataSource.NO. If
progressiveStreaming was set to DB2BaseDataSource.YES or was not set, the
returned value is 1 (YES).
getDB2SecurityMechanism
Format:
public int getDB2SecurityMechanism()
throws java.sql.SQLException
Returns the security mechanism that is in effect for the connection:
3
Clear text password security
4
User ID-only security
7
Encrypted password security
9
Encrypted user ID and password security
11
Kerberos security
12
Encrypted user ID and data security
13
Encrypted user ID, password, and data security
15
Plugin security
Chapter 7. JDBC and SQLJ reference information
369
16
Encrypted user ID-only security
getDB2SystemMonitor
Format:
public abstract DB2SystemMonitor getDB2SystemMonitor()
throws java.sql.SQLException
Returns the system monitor object for the connection. Each IBM Data Server
Driver for JDBC and SQLJ connection can have a single system monitor.
getDBConcurrentAccessResolution
Format:
public int getDBConcurrentAccessResolution()
throws java.sql.SQLException
Returns the concurrent access setting for the connection. The concurrent access
setting is set by the setDBConcurrentAccessResolution method or by the
concurrentAccessResolution property.
getDBConcurrentAccessResolution applies only to connections to DB2 for z/OS
and DB2 Database for Linux, UNIX, and Windows.
getDBProgressiveStreaming
Format:
public int getDB2ProgressiveStreaming()
throws java.sql.SQLException
Returns the current progressive streaming setting for the connection.
The returned value depends on whether the data source supports progressive
streaming, how the progressiveStreaming property is set, and whether
DB2Connection.setProgressiveStreaming was called:
v If the data source does not support progressive streaming, 2 (NO) is always
returned, regardless of the progressiveStreaming property setting.
v If the data source supports progressive streaming, and
DB2Connection.setProgressiveStreaming was called, the returned value is
the value that DB2Connection.setProgressiveStreaming set.
v If the data source supports progressive streaming, and
DB2Connection.setProgressiveStreaming was not called, the returned value
is 2 (NO) if progressiveStreaming was set to DB2BaseDataSource.NO. If
progressiveStreaming was set to DB2BaseDataSource.YES or was not set, the
returned value is 1 (YES).
getDBStatementConcentrator
Format:
public int getDBStatementConcentrator()
throws java.sql.SQLException
Returns the statement concentrator use setting for the connection. The
statement concentrator use setting is set by the setDBStatementConcentrator
method or by the statementConcentrator property.
getJccLogWriter
Format:
public PrintWriter getJccLogWriter()
throws java.sql.SQLException
Returns the current trace destination for the IBM Data Server Driver for JDBC
and SQLJ trace.
370
Application Programming Guide and Reference for Java
getJccSpecialRegisterProperties
Format:
public java.util.Properties getJccSpecialRegisterProperties()
throws java.sql.SQLException
Returns a java.util.Properties object, in which the keys are the special
registers that are supported at the target data source, and the key values are
the current values of those special registers.
This method does not apply to connections to IBM Informix data sources.
getSavePointUniqueOption
Format:
public boolean getSavePointUniqueOption()
throws java.sql.SQLException
Returns true if setSavePointUniqueOption was most recently called with a
value of true. Returns false otherwise.
installDB2JavaStoredProcedure
Format:
public void DB2Connection.installDB2JavaStoredProcedure(
java.io.InputStream jarFile,
int jarFileLength,
String jarId)
throws java.sql.SQLException
Invokes the SQLJ.DB2_INSTALL_JAR stored procedure on a DB2 for z/OS
server to create a new definition of a JAR file in the catalog for that server.
Parameter descriptions:
jarFile
The contents of the JAR file that is to be defined to the server.
jarFileLength
The length of the JAR file that is to be defined to the server.
jarId
The name of the JAR in the database, in the form schema.JAR-id or JAR-id.
This is the name that you use when you refer to the JAR in SQL
statements. If you omit schema, the database system uses the SQL
authorization ID that is in the CURRENT SCHEMA special register. The
owner of the JAR is the authorization ID in the CURRENT SQLID special
register.
This method does not apply to connections to IBM Informix data sources.
isDB2Alive
Format:
public boolean DB2Connection.isDB2Alive()
throws java.sql.SQLException
Returns true if the socket for a connection to the data source is still active.
Important: isDB2Alive is deprecated in the JDBC 4.0 implementation of the
IBM Data Server Driver for JDBC and SQLJ. Use Connection.isDBValid
instead.
isDBValid
Format:
Chapter 7. JDBC and SQLJ reference information
371
public boolean DB2Connection.isDBValid(boolean throwException, int timeout)
throws java.sql.SQLException
Returns true if the connection has not been closed and is still valid. Returns
false otherwise.
Parameter descriptions:
throwException
Specifies whether isDBValid throws an SQLException if the connection is
not valid. Possible values are:
true
isDBValid throws an SQLException if the connection is not valid.
false
isDBValid throws an SQLException only if the value of timeout is
less than 0.
timeout
The time in seconds to wait for a database operation that the driver
submits to complete. The driver submits that database operation to the
data source to validate the connection. If the timeout period expires before
the database operation completes, isDBValid returns false. A value of 0
indicates that there is no timeout period for the database operation.
This method does not apply to connections to IBM Informix data sources.
reconfigureDB2Connection
Format:
public void reconfigureDB2Connection(java.util.Properties properties)
throws SQLException
Reconfigures a connection with new settings. The connection does not need to
be returned to a connection pool before it is reconfigured. This method can be
called while a transaction is in progress, and can be used for trusted or
untrusted connections.
Trusted connections are supported for:
v IBM Data Server Driver for JDBC and SQLJ type 4 connectivity to:
– DB2 Database for Linux, UNIX, and Windows Version 9.5 or later
– DB2 for z/OS Version 9.1 or later
– IBM Informix Version 11.70 or later
v IBM Data Server Driver for JDBC and SQLJ type 2 connectivity on DB2 for
z/OS Version 9.1 or later
Parameter descriptions:
properties
New properties for the connection. These properties override any
properties that are already defined on the DB2Connection instance.
registerDB2XmlSchema
Formats:
public void registerDB2XmlSchema(String[] sqlIdSchema,
String[] sqlIdName,
String[] xmlSchemaLocations,
InputStream[] xmlSchemaDocuments,
int[] xmlSchemaDocumentsLengths,
InputStream[] xmlSchemaDocumentsProperties,
int[] xmlSchemaDocumentsPropertiesLengths,
InputStream xmlSchemaProperties,
int xmlSchemaPropertiesLength,
boolean isUsedForShredding)
372
Application Programming Guide and Reference for Java
throws SQLException
public void registerDB2XmlSchema(String[] sqlIdSchema,
String[] sqlIdName,
String[] xmlSchemaLocations,
String[] xmlSchemaDocuments,
String[] xmlSchemaDocumentsProperties,
String xmlSchemaProperties,
boolean isUsedForShredding)
throws SQLException
Registers an XML schema with one or more XML schema documents. If
multiple XML schema documents are processed with one call to
registerDB2XmlSchema, those documents are processed as part of a single
transaction.
The first form of registerDB2XmlSchema is for XML schema documents that are
read from an input stream. The second form of registerDB2XmlSchema is for
XML schema documents that are read from strings.
Parameter descriptions:
sqlIdSchema
The SQL schema name for the XML schema. Only the first element of the
sqlIdSchema array is used. sqlIdSchema is a String value with a maximum
length of 128 bytes. The value of sqlIdSchema must be the string 'SYSXSR'
or null. If the value of sqlIdSchema is null, the database system uses the
string 'SYSXSR'.
sqlIdName
The SQL name for the XML schema. Only the first element of the
sqlIdName array is used. sqlIdName is a String value with a maximum
length of 128 bytes. The value of sqlIdName must conform to the rules for
an SQL identifier and cannot be null.
xmlSchemaLocations
XML schema locations for the primary XML schema documents of the
schemas that are being registered. XML schema location values are
normally in URI format. Each xmlSchemaLocations value is a String value
with a maximum length of 1000 bytes. The value is used only to match the
information that is specified in the XML schema document that references
this document. The database system does no validation of the format, and
no attempt is made to resolve the URI.
xmlSchemaDocuments
The content of the primary XML schema documents. Each
xmlSchemaDocuments value is a String or InputStream value with a
maximum length of 30 MB. The values must not be null.
xmlSchemaDocumentsLengths
The lengths of the XML schema documents in the xmlSchemaDocuments
parameter, if the first form of registerDB2XmlSchema is used. Each
xmlSchemaDocumentsLengths value is an int value.
xmlSchemaDocumentsProperties
Contains properties of the primary XML schema documents, such as
properties that are used by an external XML schema versioning system.
The database system does no validation of the contents of these values.
They are stored in the XSR table for retrieval and used in other tools and
XML schema repository implementations. Each
Chapter 7. JDBC and SQLJ reference information
373
xmlSchemaDocumentsProperties value is a String or InputStream value with a
maximum length of 5 MB. A value is null if there are no properties to be
passed.
xmlSchemaDocumentsPropertiesLengths
The lengths of the XML schema properties in the
xmlSchemaDocumentsProperties parameter, if the first form of
registerDB2XmlSchema is used. Each xmlSchemaDocumentsPropertiesLengths
value is an int value.
xmlSchemaProperties
Contains properties of the entire XML schema, such as properties that are
used by an external XML schema versioning system. The database system
does no validation of the contents of this value. They are stored in the XSR
table for retrieval and used in other tools and XML schema repository
implementations. The xmlSchemaProperties value is a String or InputStream
value with a maximum length of 5 MB. The value is null if there are no
properties to be passed.
xmlSchemaPropertiesLengths
The length of the XML schema property in the xmlSchemaProperties
parameter, if the first form of registerDB2XmlSchema is used. The
xmlSchemaPropertiesLengths value is an int value.
isUsedForShredding
Indicates whether there are annotations in the schema that are to be used
for XML decomposition. isUsedForShredding is a boolean value.
The isUsedForShredding parameter value must be false for connections to
DB2 for z/OS data sources.
This method does not apply to connections to IBM Informix data sources.
setDBConcurrentAccessResolution
Format:
public void setDBConcurrentAccessResolution(int concurrentAccessResolution)
throws java.sql.SQLException
Specifies whether the IBM Data Server Driver for JDBC and SQLJ requests that
a read transaction can access a committed and consistent image of rows that
are incompatibly locked by write transactions, if the data source supports
accessing currently committed data, and the application isolation level is cursor
stability (CS) or read stability (RS). This option has the same effect as the DB2
CONCURRENTACCESSRESOLUTION bind option.
setDBConcurrentAccessResolution affects only statements that are created after
setDBConcurrentAccessResolution is executed.
setDBConcurrentAccessResolution applies only to connections to DB2 for z/OS
and DB2 Database for Linux, UNIX, and Windows.
Parameter descriptions:
concurrentAccessResolution
One of the following integer values:
DB2BaseDataSource.CONCURRENTACCESS_USE_CURRENTLY_COMMITTED (1)
The IBM Data Server Driver for JDBC and SQLJ requests that:
v Read transactions access the currently committed data when the
data is being updated or deleted.
374
Application Programming Guide and Reference for Java
v Read transactions skip rows that are being inserted.
DB2BaseDataSource.CONCURRENTACCESS_WAIT_FOR_OUTCOME
(2)
The IBM Data Server Driver for JDBC and SQLJ requests that:
v Read transactions wait for a commit or rollback operation when
they encounter data that is being updated or deleted.
v Read transactions do not skip rows that are being inserted.
DB2BaseDataSource.CONCURRENTACCESS_NOT_SET (0)
Enables the data server's default behavior for read transactions
when lock contention occurs. This is the default value.
setDBProgressiveStreaming
Format:
public void setDB2ProgressiveStreaming(int newSetting)
throws java.sql.SQLException
Sets the progressive streaming setting for all ResultSet objects that are created
on the connection.
Parameter descriptions:
newSetting
The new progresssive streaming setting. Possible values are:
DB2BaseDataSource.YES (1)
Enable progressive streaming. If the data source does not support
progressive streaming, this setting has no effect.
DB2BaseDataSource.NO (2)
Disable progressive streaming.
setDBStatementConcentrator
Format:
public void setDBStatementConcentrator(int statementConcentratorUse)
throws java.sql.SQLException
Specifies whether the IBM Data Server Driver for JDBC and SQLJ uses the data
source's statement concentrator functionality. The statement concentrator is the
ability to bypass preparation of a statement when it is the same as a statement
in the dynamic statement cache, except for literal values. Statement
concentrator functionality applies only to SQL statements that have literals but
no parameter markers. setDBStatementConcentrator overrides the setting of
the statementConcentrator Connection or DataSource property.
setDBStatementConcentrator affects only statements that are created after
setDBStatementConcentrator is executed.
Parameter descriptions:
statementConcentratorUse
One of the following integer values:
DB2BaseDataSource.STATEMENT_CONCENTRATOR_OFF (1)
The IBM Data Server Driver for JDBC and SQLJ does not use the
data source's statement concentrator functionality.
DB2BaseDataSource.STATEMENT_CONCENTRATOR_WITH_LITERALS
(2)
The IBM Data Server Driver for JDBC and SQLJ uses the data
source's statement concentrator functionality.
Chapter 7. JDBC and SQLJ reference information
375
DB2BaseDataSource.STATEMENT_CONCENTRATOR_NOT_SET (0)
Enables the data server's default behavior for statement
concentrator functionality. This is the default value.
For DB2 Database for Linux, UNIX, and Windows data sources
that support statement concentrator functionality, the functionality
is used if the STMT_CONC configuration parameter is set to ON at
the data source. Otherwise, statement concentrator functionality is
not used.
For DB2 for z/OS data sources that support statement concentrator
functionality, the functionality is not used if statementConcentrator
is not set.
removeDB2JavaStoredProcedure
Format:
public void DB2Connection.removeDB2JavaStoredProcedure(
String jarId)
throws java.sql.SQLException
Invokes the SQLJ.DB2_REMOVE_JAR stored procedure on a DB2 for z/OS
server to delete the definition of a JAR file from the catalog for that server.
Parameter descriptions:
jarId
The name of the JAR in the database, in the form schema.JAR-id or JAR-id.
This is the name that you use when you refer to the JAR in SQL
statements. If you omit schema, the database system uses the SQL
authorization ID that is in the CURRENT SCHEMA special register.
This method does not apply to connections to IBM Informix data sources.
replaceDB2JavaStoredProcedure
Format:
public void DB2Connection.replaceDB2JavaStoredProcedure(
java.io.InputStream jarFile,
int jarFileLength,
String jarId)
throws java.sql.SQLException
Invokes the SQLJ.DB2_REPLACE_JAR stored procedure on a DB2 for z/OS
server to replace the definition of a JAR file in the catalog for that server.
Parameter descriptions:
jarFile
The contents of the JAR file that is to be replaced on the server.
jarFileLength
The length of the JAR file that is to be replace on the server.
jarId
The name of the JAR in the database, in the form schema.JAR-id or JAR-id.
This is the name that you use when you refer to the JAR in SQL
statements. If you omit schema, the database system uses the SQL
authorization ID that is in the CURRENT SCHEMA special register. The
owner of the JAR is the authorization ID in the CURRENT SQLID special
register.
This method does not apply to connections to IBM Informix data sources.
376
Application Programming Guide and Reference for Java
reuseDB2Connection (trusted connection reuse)
Formats:
public void reuseDB2Connection(byte[] cookie,
String user,
String password,
String usernameRegistry,
byte[] userSecToken,
String originalUser,
java.util.Properties properties)
throws java.sql.SQLException
public void reuseDB2Connection(byte[] cookie,
org.ietf.GSSCredential gssCredential,
String usernameRegistry,
byte[] userSecToken,
String originalUser,
java.util.Properties properties)
throws java.sql.SQLException
Trusted connections are supported for:
v IBM Data Server Driver for JDBC and SQLJ type 4 connectivity to:
– DB2 Database for Linux, UNIX, and Windows Version 9.5 or later
– DB2 for z/OS Version 9.1 or later
– IBM Informix Version 11.70 or later
v IBM Data Server Driver for JDBC and SQLJ type 2 connectivity on DB2 for
z/OS Version 9.1 or later
The second of these forms of reuseDB2Connection does not apply to IBM Data
Server Driver for JDBC and SQLJ type 2 connectivity on DB2 for z/OS.
These forms of reuseDB2Connection are used by a trusted application server to
reuse a preexisting trusted connection on behalf of a new user. Properties that
can be reset are passed, including the new user ID. The database server resets
the associated physical connection. If reuseDB2Connection executes successfully,
the connection becomes available for immediate use, with different properties,
by the new user.
Parameter descriptions:
cookie
A unique cookie that the JDBC driver generates for the Connection
instance. The cookie is known only to the application server and the
underlying JDBC driver that established the initial trusted connection. The
application server passes the cookie that was created by the driver when
the pooled connection instance was created. The JDBC driver checks that
the supplied cookie matches the cookie of the underlying trusted physical
connection to ensure that the request originated from the application server
that established the trusted physical connection. If the cookies match, the
connection becomes available for immediate use, with different properties,
by the new user .
user
The client ID that the database system uses to establish the database
authorization ID. If the user was not authenticated by the application
server, the application server needs to pass a client ID that represents an
unauthenticated user.
password
The password for user.
Chapter 7. JDBC and SQLJ reference information
377
gssCredential
If the data source uses Kerberos security, specifies a delegated credential
that is passed from another principal.
userNameRegistry
A name that identifies a mapping service that maps a workstation user ID
to a z/OS RACF ID. An example of a mapping service is the Integrated
Security Services Enterprise Identity Mapping (EIM). The mapping service
is defined by a plugin. Valid values for userNameRegistry are defined by the
plugin providers. If userNameRegistry is null, no mapping of user is done.
userSecToken
The client's security tokens. This value is traced as part of DB2 for z/OS
accounting data. The content of userSecToken is described by the application
server and is referred to by the database system as an application server
security token.
originalUser
The original user ID that was used by the application server.
properties
Properties for the reused connection.
reuseDB2Connection (untrusted reuse with reauthentication)
Formats:
public void reuseDB2Connection(String user,
String password,
java.util.Properties properties)
throws java.sql.SQLException
public void reuseDB2Connection(
org.ietf.jgss.GSSCredential gssCredential,
java.util.Properties properties)
throws java.sql.SQLException
The first of these forms of reuseDB2Connection is not supported for IBM Data
Server Driver for JDBC and SQLJ type 2 connectivity on DB2 for z/OS.
The second of these forms of reuseDB2Connection does not apply to IBM Data
Server Driver for JDBC and SQLJ type 2 connectivity on DB2 for z/OS.
In a heterogeneous pooling environment, these forms of reuseDB2Connection
reuse an existing Connection instance after reauthentication.
Parameter description:
user
The authorization ID that is used to establish the connection.
password
The password for the authorization ID that is used to establish the
connection.
gssCredential
If the data source uses Kerberos security, specifies a delegated credential
that is passed from another principal.
properties
Properties for the reused connection. These properties override any
properties that are already defined on the DB2Connection instance.
reuseDB2Connection (untrusted or trusted reuse without reauthentication)
Formats:
378
Application Programming Guide and Reference for Java
public void reuseDB2Connection(java.util.Properties properties)
throws java.sql.SQLException
Reuses an existing Connection instance without reauthentication. This method
is intended for reuse of a Connection instance when the properties do not
change.
Trusted connections are supported for:
v IBM Data Server Driver for JDBC and SQLJ type 4 connectivity to:
– DB2 Database for Linux, UNIX, and Windows Version 9.5 or later
– DB2 for z/OS Version 9.1 or later
– IBM Informix Version 11.70 or later
v IBM Data Server Driver for JDBC and SQLJ type 2 connectivity on DB2 for
z/OS Version 9.1 or later
This method is for dirty reuse of a connection. This means that the connection
state is not reset when the object is reused from the pool. Special register
settings and property settings remain in effect unless they are overridden by
passed properties. Global temporary tables are not deleted. Properties that are
not specified are not re-initialized. All JDBC standard transient properties, such
as the isolation level, autocommit mode, and read-only mode are reset to their
JDBC defaults. Certain properties, such as user, password, databaseName,
serverName, portNumber, planName, and pkList remain unchanged.
Parameter description:
properties
Properties for the reused connection. These properties override any
properties that are already defined on the DB2Connection instance.
setDB2ClientAccountingInformation
Format:
public void setDB2ClientAccountingInformation(String info)
throws java.sql.SQLException
Specifies accounting information for the connection. This information is for
client accounting purposes. This value can change during a connection.
setDB2ClientAccountingInformation sets the value in the CLIENT ACCTNG
special register.
Parameter description:
info
User-specified accounting information. The maximum length depends on
the server. For a DB2 Database for Linux, UNIX, and Windows server, the
maximum length is 255 bytes. For a DB2 for z/OS server, the maximum
length is 22 bytes. A Java empty string ("") is valid for this parameter
value, but a Java null value is not valid.
Important: setDB2ClientAccountingInformation is deprecated in the JDBC 4.0
implementation of the IBM Data Server Driver for JDBC and SQLJ. Use
java.sql.Connection.setClientInfo instead.
setDB2ClientApplicationInformation
Format:
public String setDB2ClientApplicationInformation(String info)
throws java.sql.SQLException
Specifies application information for the current client.
Chapter 7. JDBC and SQLJ reference information
379
Important: setDB2ClientApplicationInformation is deprecated in the JDBC 4.0
implementation of the IBM Data Server Driver for JDBC and SQLJ. Use
java.sql.Connection.setClientInfo instead.
Parameter description:
info
User-specified application information. The maximum length depends on
the server. For a DB2 Database for Linux, UNIX, and Windows server, the
maximum length is 255 bytes. For a DB2 for z/OS server, the maximum
length is 32 bytes. A Java empty string ("") is valid for this parameter
value, but a Java null value is not valid.
setDB2ClientDebugInfo
Formats:
public void setDB2ClientDebugInfo(String debugInfo)
throws java.sql.SQLException
public void setDB2ClientDebugInfo(String mgrInfo,
String traceInfo)
throws java.sql.SQLException
Sets a value for the CLIENT DEBUGINFO connection attribute, to notify the
database system that stored procedures and user-defined functions that are
using the connection are running in debug mode. CLIENT DEBUGINFO is
used by the DB2 Unified Debugger. Use the first form to set the entire CLIENT
DEBUGINFO string. Use the second form to modify only the session manager
and trace information in the CLIENT DEBUGINFO string.
Setting the CLIENT DEBUGINFO attribute to a string of length greater than
zero requires one of the following privileges:
v The DEBUGSESSION privilege
v SYSADM authority
Parameter description:
debugInfo
A string of up to 254 bytes, in the following form:
Mip:port,Iip,Ppid,Ttid,Cid,Llvl
The parts of the string are:
Mip:port
Session manager IP address and port number
Iip
Client IP address
Ppid
Client process ID
Ttid
Client thread ID (optional)
Cid
Data connection generated ID
Llvl
Debug library diagnostic trace level
For example:
M9.72.133.89:8355,I9.72.133.89,P4552,T123,C1,L0
See the description of SET CLIENT DEBUGINFO for a detailed description
of this string.
mgrInfo
A string of the following form, which specifies the IP address and port
number for the Unified Debugger session manager.
380
Application Programming Guide and Reference for Java
Mip:port
For example:
M9.72.133.89:8355
See the description of SET CLIENT DEBUGINFO for a detailed description
of this string.
trcInfo
A string of the following form, which specifies the debug library
diagnostics trace level.
Llvl
For example:
L0
See the description of SET CLIENT DEBUGINFO for a detailed description
of this string.
setDB2ClientProgramId
Format:
public abstract void setDB2ClientProgramId(String program-ID)
throws java.sql.SQLException
Sets a user-defined program identifier for the connection, on DB2 for z/OS
servers. That program identifier is an 80-byte string that is used to identify the
caller.
setDB2ClientProgramId does not apply to DB2 Database for Linux, UNIX, and
Windows or IBM Informix data servers.
The DB2 for z/OS server places the string in IFCID 316 trace records along
with other statistics, so that you can identify which program is associated with
a particular SQL statement.
setDB2ClientUser
Format:
public void setDB2ClientUser(String user)
throws java.sql.SQLException
Specifies the current client user name for the connection. This name is for
client accounting purposes, and is not the user value for the JDBC connection.
Unlike the user for the JDBC connection, the current client user name can
change during a connection.
setDB2ClientUser sets the value in the CLIENT USERID special register.
Parameter description:
user
The user ID for the current client. The maximum length depends on the
server. For a DB2 Database for Linux, UNIX, and Windows server, the
maximum length is 255 bytes. For a DB2 for z/OS server, the maximum
length is 16 bytes. A Java empty string ("") is valid for this parameter
value, but a Java null value is not valid.
Important: setDB2ClientUser is deprecated in the JDBC 4.0 implementation of
the IBM Data Server Driver for JDBC and SQLJ. Use
java.sql.Connection.setClientInfo instead.
Chapter 7. JDBC and SQLJ reference information
381
setDB2ClientWorkstation
Format:
public void setDB2ClientWorkstation(String name)
throws java.sql.SQLException
Specifies the current client workstation name for the connection. This name is
for client accounting purposes. The current client workstation name can change
during a connection.
setDB2ClientWorkstation sets the value in the CLIENT WRKSTNNAME
special register.
Parameter description:
name
The workstation name for the current client. The maximum length depends
on the server. For a DB2 Database for Linux, UNIX, and Windows server,
the maximum length is 255 bytes. For a DB2 for z/OS server, the
maximum length is 18 bytes. A Java empty string ("") is valid for this
parameter value, but a Java null value is not valid.
Important: getDB2ClientWorkstation is deprecated in the JDBC 4.0
implementation of the IBM Data Server Driver for JDBC and SQLJ. Use
java.sql.Connection.getClientInfo instead.
setDB2CurrentPackagePath
Format:
public void setDB2CurrentPackagePath(String packagePath)
throws java.sql.SQLException
Specifies a list of collection IDs that the database system searches for JDBC and
SQLJ packages.
The setDB2CurrentPackagePath method applies only to connections to DB2
database systems.
Parameter description:
packagePath
A comma-separated list of collection IDs.
setDB2CurrentPackageSet
Format:
public void setDB2CurrentPackageSet(String packageSet)
throws java.sql.SQLException
Specifies the collection ID for the connection. When you set this value, you
also set the collection ID of the IBM Data Server Driver for JDBC and SQLJ
instance that is used for the connection.
The setDB2CurrentPackageSet method applies only to connections to DB2
database systems.
Parameter description:
packageSet
The collection ID for the connection. The maximum length for the
packageSet value is 18 bytes. You can invoke this method as an alternative
to executing the SQL SET CURRENT PACKAGESET statement in your
program.
382
Application Programming Guide and Reference for Java
setDB2ProgressiveStreaming
Format:
public void setDB2ProgressiveStreaming(int newSetting)
throws java.sql.SQLException
Sets the progressive streaming setting for all ResultSet objects that are created
on the connection.
Parameter descriptions:
newSetting
The new progresssive streaming setting. Possible values are:
DB2BaseDataSource.YES (1)
Enable progressive streaming. If the data source does not support
progressive streaming, this setting has no effect.
DB2BaseDataSource.NO (2)
Disable progressive streaming.
setJccLogWriter
Formats:
public void setJccLogWriter(PrintWriter logWriter)
throws java.sql.SQLException
public void setJccLogWriter(PrintWriter logWriter, int traceLevel)
throws java.sql.SQLException
Enables or disables the IBM Data Server Driver for JDBC and SQLJ trace, or
changes the trace destination during an active connection.
Parameter descriptions:
logWriter
An object of type java.io.PrintWriter to which the IBM Data Server
Driver for JDBC and SQLJ writes trace output. To turn off the trace, set the
value of logWriter to null.
traceLevel
Specifies the types of traces to collect. See the description of the traceLevel
property in "Properties for the IBM Data Server Driver for JDBC and SQLJ"
for valid values.
setSavePointUniqueOption
Format:
public void setSavePointUniqueOption(boolean flag)
throws java.sql.SQLException
Specifies whether an application can reuse a savepoint name within a unit of
recovery. Possible values are:
true
A Connection.setSavepoint(savepoint-name) method cannot specify
the same value for savepoint-name more than once within the same unit
of recovery.
false
A Connection.setSavepoint(savepoint-name) method can specify the
same value for savepoint-name more than once within the same unit of
recovery.
When false is specified, if the Connection.setSavepoint(savepointname) method is executed, and a savepoint with the name
Chapter 7. JDBC and SQLJ reference information
383
savepoint-name already exists within the unit of recovery, the database
manager destroys the existing savepoint, and creates a new savepoint
with the name savepoint-name.
Reuse of a savepoint is not the same as executing
Connection.releaseSavepoint(savepoint-name).
Connection.releaseSavepoint(savepoint-name) releases savepoint-name,
and any savepoints that were subsequently set.
updateDB2XmlSchema
Format:
public void updateDB2XmlSchema(String[] targetSqlIdSchema,
String[] targetSqlIdName,
String[] sourceSqlIdSchema,
String[] sourceSqlIdName,
String[] xmlSchemaLocations,
boolean dropSourceSchema)
throws SQLException
Updates the contents of an XML schema with the contents of another XML
schema in the XML schema repository, and optionally drops the source
schema. The schema documents in the target XML schema are replaced with
the schema documents from the source XML schema. Before
updateDB2XmlSchema can be called, registration of the source and target XML
schemas must be completed.
The SQL ALTERIN privilege is required for updating the target XML schema.
The SQL DROPIN privilege is required for dropping the source XML schema.
Parameter descriptions:
targetSqlIdSchema
The SQL schema name for a registered XML schema that is to be updated.
targetSqlIdSchema is a String value with a maximum length of 128 bytes.
targetSqlIdName
The name of the registered XML schema that is to be updated.
targetSqlIdName is a String value with a maximum length of 128 bytes.
sourceSqlIdSchema
The SQL schema name for a registered XML schema that is used to update
the target XML schema. sourceSqlIdSchema is a String value with a
maximum length of 128 bytes.
sourceSqlIdName
The name of the registered XML schema that is used to update the target
XML schema. sourceSqlIdName is a String value with a maximum length of
128 bytes.
dropSourceSchema
Indicates whether the source XML schema is to be dropped after the target
XML schema is updated. dropSourceSchema is a boolean value. false is the
default.
This method does not apply to connections to IBM Informix data sources.
384
Application Programming Guide and Reference for Java
Related concepts
Chapter 14, “Problem diagnosis with the IBM Data Server Driver for JDBC and
SQLJ,” on page 567
Related tasks
“Providing extended client information to the data source with IBM Data Server
Driver for JDBC and SQLJ-only methods” on page 76
Related reference
“Common IBM Data Server Driver for JDBC and SQLJ properties for DB2 servers”
on page 242
“IBM Data Server Driver for JDBC and SQLJ properties for DB2 Database for
Linux, UNIX, and Windows” on page 254
DB2ConnectionPoolDataSource class
DB2ConnectionPoolDataSource is a factory for PooledConnection objects. An object
that implements this interface is registered with a naming service that is based on
the Java Naming and Directory Interface (JNDI).
The com.ibm.db2.jcc.DB2ConnectionPoolDataSource class extends the
com.ibm.db2.jcc.DB2BaseDataSource class, and implements the
javax.sql.ConnectionPoolDataSource, java.io.Serializable, and
javax.naming.Referenceable interfaces.
DB2ConnectionPoolDataSource properties
These properties are defined only for the IBM Data Server Driver for JDBC and
SQLJ. "Properties for the IBM Data Server Driver for JDBC and SQLJ" for
explanations of these properties.
These properties have a setXXX method to set the value of the property and a
getXXX method to retrieve the value. A setXXX method has this form:
void setProperty-name(data-type property-value)
A getXXX method has this form:
data-type getProperty-name()
Property-name is the unqualified property name, with the first character capitalized.
The following table lists the IBM Data Server Driver for JDBC and SQLJ properties
and their data types.
Table 92. DB2ConnectionPoolDataSource properties and their data types
Property name
Data type
com.ibm.db2.jcc.DB2ConnectionPoolDataSource.maxStatements
int
DB2ConnectionPoolDataSource methods
getDB2PooledConnection
Formats:
public DB2PooledConnection getDB2PooledConnection(String user,
String password,
java.util.Properties properties)
throws java.sql.SQLException
Chapter 7. JDBC and SQLJ reference information
385
public DB2PooledConnection getDB2PooledConnection(
org.ietf.jgss.GSSCredential gssCredential,
java.util.Properties properties)
throws java.sql.SQLException
Establishes the initial untrusted connection in a heterogeneous pooling
environment.
The first form getDB2PooledConnection provides a user ID and password. The
second form of getDB2PooledConnection is for connections that use Kerberos
security.
Parameter descriptions:
user
The authorization ID that is used to establish the connection.
password
The password for the authorization ID that is used to establish the
connection.
gssCredential
If the data source uses Kerberos security, specifies a delegated credential
that is passed from another principal.
properties
Properties for the connection.
getDB2TrustedPooledConnection
Formats:
public Object[] getDB2TrustedPooledConnection(String user,
String password,
java.util.Properties properties)
throws java.sql.SQLException
public Object[] getDB2TrustedPooledConnection(
java.util.Properties properties)
throws java.sql.SQLException
public Object[] getDB2TrustedPooledConnection(
org.ietf.jgss.GSSCredential gssCredential,
java.util.Properties properties)
throws java.sql.SQLException
An application server using a system authorization ID uses this method to
establish a trusted connection.
Trusted connections are supported for:
v IBM Data Server Driver for JDBC and SQLJ type 4 connectivity to:
– DB2 Database for Linux, UNIX, and Windows Version 9.5 or later
– DB2 for z/OS Version 9.1 or later
– IBM Informix Version 11.70 or later
v IBM Data Server Driver for JDBC and SQLJ type 2 connectivity on DB2 for
z/OS Version 9.1 or later
The following elements are returned in Object[]:
v The first element is a trusted DB2PooledConnection instance.
v The second element is a unique cookie for the generated pooled connection
instance.
The first form getDB2TrustedPooledConnection provides a user ID and
password, while the second form of getDB2TrustedPooledConnection uses the
386
Application Programming Guide and Reference for Java
user ID and password of the DB2ConnectionPoolDataSource object. The third
form of getDB2TrustedPooledConnection is for connections that use Kerberos
security.
Parameter descriptions:
user
The DB2 authorization ID that is used to establish the trusted connection to
the database server.
password
The password for the authorization ID that is used to establish the trusted
connection.
gssCredential
If the data source uses Kerberos security, specifies a delegated credential
that is passed from another principal.
properties
Properties for the connection.
Related concepts
Chapter 11, “JDBC and SQLJ connection pooling support,” on page 557
Related reference
“Properties for the IBM Data Server Driver for JDBC and SQLJ” on page 221
DB2DatabaseMetaData interface
The com.ibm.db2.jcc.DB2DatabaseMetaData interface extends the
java.sql.DatabaseMetaData interface.
DB2DatabaseMetaData methods
The following methods are defined only for the IBM Data Server Driver for JDBC
and SQLJ.
isIDSDatabaseAnsiCompliant
Format:
public boolean isIDSDatabaseAnsiCompliant();
Returns true if the current active IBM Informix database is ANSI-compliant.
Returns false otherwise.
An ANSI-compliant database is a database that was created with the WITH
LOG MODE ANSI option.
This method applies to connections to IBM Informix data sources only. An
SQLException is thrown if the data source is not an IBM Informix data source.
isIDSDatabaseLogging
Format:
public boolean isIDSDatabaseLogging();
Returns true if the current active IBM Informix database supports logging.
Returns false otherwise.
An IBM Informix database that supports logging is a database that was created
with the WITH LOG MODE ANSI option, the WITH BUFFERED LOG, or the
WITH LOG option.
This method applies to connections to IBM Informix data sources only. An
SQLException is thrown if the data source is not an IBM Informix data source.
Chapter 7. JDBC and SQLJ reference information
387
isResetRequiredForDB2eWLM
Format:
public boolean isResetRequiredForDB2eWLM();
Returns true if the target database server requires clean reuse to support
eWLM. Returns false otherwise.
supportsDB2ProgressiveStreaming
Format:
public boolean supportsDB2ProgressiveStreaming();
Returns true if the target data source supports progressive streaming. Returns
false otherwise.
DB2Diagnosable interface
The com.ibm.db2.jcc.DB2Diagnosable interface provides a mechanism for getting
DB2 diagnostics from an SQLException.
DB2Diagnosable methods
The following methods are defined only for the IBM Data Server Driver for JDBC
and SQLJ.
getSqlca
Format:
public DB2Sqlca getSqlca();
Returns a DB2Sqlca object from a java.sql.Exception that is produced under a
IBM Data Server Driver for JDBC and SQLJ.
getThrowable
Format:
public Throwable getThrowable();
Returns a java.lang.Throwable object from a java.sql.Exception that is
produced under a IBM Data Server Driver for JDBC and SQLJ.
printTrace
Format:
static public void printTrace(java.io.PrintWriter printWriter,
String header);
Prints diagnostic information after a java.sql.Exception is thrown under a
IBM Data Server Driver for JDBC and SQLJ.
Parameter descriptions:
printWriter
The destination for the diagnostic information.
header
User-defined information that is printed at the beginning of the output.
388
Application Programming Guide and Reference for Java
Related tasks
“Handling an SQLException under the IBM Data Server Driver for JDBC and
SQLJ” on page 102
“Handling SQL warnings in an SQLJ application” on page 170
DB2ExceptionFormatter class
The com.ibm.db2.jcc.DB2ExceptionFormatter class contains methods for printing
diagnostic information to a stream.
DB2ExceptionFormatter methods
The following methods are defined only for the IBM Data Server Driver for JDBC
and SQLJ.
printTrace
Formats:
static public void printTrace(java.sql.SQLException sqlException,
java.io.PrintWriter printWriter, String header)
static public void printTrace(DB2Sqlca sqlca,
java.io.PrintWriter printWriter, String header)
static public void printTrace(java.lang.Throwable throwable,
java.io.PrintWriter printWriter, String header)
Prints diagnostic information after an exception is thrown.
Parameter descriptions:
sqlException|sqlca|throwable
The exception that was thrown during a previous JDBC or Java operation.
printWriter
The destination for the diagnostic information.
header
User-defined information that is printed at the beginning of the output.
Related concepts
“Example of a trace program under the IBM Data Server Driver for JDBC and
SQLJ” on page 569
DB2FileReference class
The com.ibm.db2.jcc.DB2FileReference class is an abstract class that defines
methods that support insertion of data into tables from file reference variables.
This class applies only to IBM Data Server Driver for JDBC and SQLJ type 2
connectivity to DB2 for z/OS Version 9 or later.
DB2FileReference fields
The following constants define types codes only for the IBM Data Server Driver for
JDBC and SQLJ.
public static final short MAX_FILE_NAME_LENGTH = 255
The maximum length of the file name for a file reference variable.
Chapter 7. JDBC and SQLJ reference information
389
DB2FileReference methods
The following methods are defined only for the IBM Data Server Driver for JDBC
and SQLJ.
getDriverType
Format:
public int getDriverType()
Returns the server data type of the file reference variable. This type is one of
the values in com.ibm.db2.jcc.DB2Types.
getFileEncoding
Format:
public String getFileEncoding()
Returns the encoding of the data in the file for a DB2FileReference object.
getFileName
Format:
public String getFileName()
Returns the file name for a DB2FileReference object.
getFileCcsid
Format:
public int getFileCcsid()
Returns the CCSID of the data in the file for a DB2FileReference object.
setFileName
Format:
public String setFileName(String fileName)
throws java.sql.SQLException
Sets the file name in a DB2FileReference object.
Parameter descriptions:
fileName
The name of the input file for the file reference variable. The name must
specify an existing HFS file.
DB2JCCPlugin class
The com.ibm.db2.jcc.DB2JCCPlugin class is an abstract class that defines methods
that can be implemented to provide DB2 Database for Linux, UNIX, and Windows
plug-in support. This class applies only to DB2 Database for Linux, UNIX, and
Windows.
DB2JCCPlugin methods
The following methods are defined only for the IBM Data Server Driver for JDBC
and SQLJ.
getTicket
Format:
390
Application Programming Guide and Reference for Java
public abstract byte[] getTicket(String user,
String password,
byte[] returnedToken)
throws org.ietf.jgss.GSSException
Retrieves a Kerberos ticket for a user.
Parameter descriptions:
user
The user ID for which the Kerberos ticket is to be retrieved.
password
The password for user.
returnedToken
DB2ParameterMetaData interface
The com.ibm.db2.jcc.DB2ParameterMetaData interface extends the
java.sql.ParameterMetaData interface.
DB2ParameterMetaData methods
The following methods are defined only for the IBM Data Server Driver for JDBC
and SQLJ.
getParameterMarkerNames
Format:
public String[] getParameterMarkerNames()
throws java.sql.SQLException
Returns a list of the parameter marker names that are used in an SQL
statement.
This method returns null if the enableNamedParameterMarkers property is set
DB2BaseDataSource.NOT_SET or DB2BaseDataSource.NO, or if there are no named
parameter markers in the SQL statement.
getProcedureParameterName
Format:
public String getProcedureParameterName(int param)
throws java.sql.SQLException
Returns the name in the CREATE PROCEDURE statement of a parameter in an
SQL CALL statement. If the parameter has no name in the CREATE
PROCEDURE statement, the ordinal position of the parameter in the CREATE
PROCEDURE statement is returned.
Parameter descriptions:
param
The ordinal position of the parameter in the CALL statement.
This method applies to connections to DB2 Database for Linux, UNIX, and
Windows 9.7 or later data servers only.
DB2PooledConnection class
The com.ibm.db2.jcc.DB2PooledConnection class provides methods that an
application server can use to switch users on a preexisting trusted connection.
Trusted connections are supported for:
Chapter 7. JDBC and SQLJ reference information
391
v IBM Data Server Driver for JDBC and SQLJ type 4 connectivity to:
– DB2 Database for Linux, UNIX, and Windows Version 9.5 or later
– DB2 for z/OS Version 9.1 or later
– IBM Informix Version 11.70 or later
v IBM Data Server Driver for JDBC and SQLJ type 2 connectivity on DB2 for z/OS
Version 9.1 or later
DB2PooledConnection methods
The following methods are defined only for the IBM Data Server Driver for JDBC
and SQLJ.
getConnection (untrusted or trusted reuse without reauthentication)
Format:
public DB2Connection getConnection()
throws java.sql.SQLException
This method is for dirty reuse of a connection. This means that the connection
state is not reset when the object is reused from the pool. Special register
settings and property settings remain in effect unless they are overridden by
passed properties. Global temporary tables are not deleted. Properties that are
not specified are not re-initialized. All JDBC standard transient properties, such
as the isolation level, autocommit mode, and read-only mode are reset to their
JDBC defaults. Certain properties, such as user, password, databaseName,
serverName, portNumber, planName, and pkList remain unchanged.
getDB2Connection (trusted reuse)
Formats:
public DB2Connection getDB2Connection(byte[] cookie,
String user,
String password,
String userRegistry,
byte[] userSecToken,
String originalUser,
java.util.Properties properties)
throws java.sql.SQLException
public Connection getDB2Connection(byte[] cookie,
org.ietf.GSSCredential gssCredential,
String usernameRegistry,
byte[] userSecToken,
String originalUser,
java.util.Properties properties)
throws java.sql.SQLException
Switches the user that is associated with a trusted connection without
authentication.
The second form of getDB2Connection is supported only for IBM Data Server
Driver for JDBC and SQLJ type 4 connectivity.
Parameter descriptions:
cookie
A unique cookie that the JDBC driver generates for the Connection
instance. The cookie is known only to the application server and the
underlying JDBC driver that established the initial trusted connection. The
application server passes the cookie that was created by the driver when
the pooled connection instance was created. The JDBC driver checks that
the supplied cookie matches the cookie of the underlying trusted physical
connection to ensure that the request originated from the application server
392
Application Programming Guide and Reference for Java
that established the trusted physical connection. If the cookies match, the
connection can become available, with different properties, for immediate
use by a new user .
user
The client identity that is used by the data source to establish the
authorization ID for the database server. If the user was not authenticated
by the application server, the application server must pass a user identity
that represents an unauthenticated user.
password
The password for user.
gssCredential
If the data source uses Kerberos security, specifies a delegated credential
that is passed from another principal.
userNameRegistry
A name that identifies a mapping service that maps a workstation user ID
to a z/OS RACF ID. An example of a mapping service is the Integrated
Security Services Enterprise Identity Mapping (EIM). The mapping service
is defined by a plugin. Valid values for userNameRegistry are defined by the
plugin providers. If userNameRegistry is null, the connection does not use a
mapping service.
userSecToken
The client's security tokens. This value is traced as part of DB2 for z/OS
accounting data. The content of userSecToken is described by the application
server and is referred to by the data source as an application server
security token.
originalUser
The client identity that sends the original request to the application server.
originalUser is included in DB2 for z/OS accounting data as the original
user ID that was used by the application server.
properties
Properties for the reused connection. These properties override any
properties that are already defined on the DB2PooledConnection instance.
getDB2Connection (untrusted reuse with reauthentication)
Formats:
public DB2Connection getDB2Connection(
String user,
String password,
java.util.Properties properties)
throws java.sql.SQLException
public DB2Connection getDB2Connection(org.ietf.jgss.GSSCredential gssCredential,
java.util.Properties properties)
throws java.sql.SQLException
Switches the user that is associated with a untrusted connection, with
authentication.
The first form getDB2Connection provides a user ID and password. The second
form of getDB2Connection is for connections that use Kerberos security.
Parameter descriptions:
user
The user ID that is used by the data source to establish the authorization
ID for the database server.
Chapter 7. JDBC and SQLJ reference information
393
password
The password for user.
properties
Properties for the reused connection. These properties override any
properties that are already defined on the DB2PooledConnection instance.
getDB2Connection (untrusted or trusted reuse without reauthentication)
Formats:
public java.sql.Connection getDB2Connection(
java.util.Properties properties)
throws java.sql.SQLException
Reuses an untrusted connection, without reauthentication.
This method is for dirty reuse of a connection. This means that the connection
state is not reset when the object is reused from the pool. Special register
settings and property settings remain in effect unless they are overridden by
passed properties. Global temporary tables are not deleted. Properties that are
not specified are not re-initialized. All JDBC standard transient properties, such
as the isolation level, autocommit mode, and read-only mode are reset to their
JDBC defaults. Certain properties, such as user, password, databaseName,
serverName, portNumber, planName, and pkList remain unchanged.
Parameter descriptions:
properties
Properties for the reused connection. These properties override any
properties that are already defined on the DB2PooledConnection instance.
Related concepts
Chapter 11, “JDBC and SQLJ connection pooling support,” on page 557
Related reference
“DB2ConnectionPoolDataSource class” on page 385
DB2PoolMonitor class
The com.ibm.db2.jcc.DB2PoolMonitor class provides methods for monitoring the
global transport objects pool that is used for the connection concentrator and
Sysplex workload balancing.
DB2PoolMonitor fields
The following fields are defined only for the IBM Data Server Driver for JDBC and
SQLJ.
public static final int TRANSPORT_OBJECT = 1
This value is a parameter for the DB2PoolMonitor.getPoolMonitor method.
DB2PoolMonitor methods
The following methods are defined only for the IBM Data Server Driver for JDBC
and SQLJ.
agedOutObjectCount
Format:
public abstract int agedOutObjectCount()
Retrieves the number of objects that exceeded the idle time that was specified
by db2.jcc.maxTransportObjectIdleTime and were deleted from the pool.
394
Application Programming Guide and Reference for Java
createdObjectCount
Format:
public abstract int createdObjectCount()
Retrieves the number of objects that the IBM Data Server Driver for JDBC and
SQLJ created since the pool was created.
getMonitorVersion
Format:
public int getMonitorVersion()
Retrieves the version of the DB2PoolMonitor class that is shipped with the IBM
Data Server Driver for JDBC and SQLJ.
getPoolMonitor
Format:
public static DB2PoolMonitor getPoolMonitor(int monitorType)
Retrieves an instance of the DB2PoolMonitor class.
Parameter descriptions:
monitorType
The monitor type. This value must be
DB2PoolMonitor.TRANSPORT_OBJECT.
heavyWeightReusedObjectCount
Format:
public abstract int heavyWeightReusedObjectCount()
Retrieves the number of objects that were reused from the pool.
lightWeightReusedObjectCount
Format:
public abstract int lightWeightReusedObjectCount()
Retrieves the number of objects that were reused but were not in the pool. This
can happen if a Connection object releases a transport object at a transaction
boundary. If the Connection object needs a transport object later, and the
original transport object has not been used by any other Connection object, the
Connection object can use that transport object.
longestBlockedRequestTime
Format:
public abstract long longestBlockedRequestTime()
Retrieves the longest amount of time that a request was blocked, in
milliseconds.
numberOfConnectionReleaseRefused
Format:
public abstract int numberOfConnectionReleaseRefused()
Retrieves the number of times that the release of a connection was refused.
numberOfRequestsBlocked
Format:
public abstract int numberOfRequestsBlocked()
Chapter 7. JDBC and SQLJ reference information
395
Retrieves the number of requests that the IBM Data Server Driver for JDBC
and SQLJ made to the pool that the pool blocked because the pool reached its
maximum capacity. A blocked request might be successful if an object is
returned to the pool before the db2.jcc.maxTransportObjectWaitTime is
exceeded and an exception is thrown.
numberOfRequestsBlockedDataSourceMax
Format:
public abstract int numberOfRequestsBlockedDataSourceMax()
Retrieves the number of requests that the IBM Data Server Driver for JDBC
and SQLJ made to the pool that the pool blocked because the pool reached the
maximum for the DataSource object.
numberOfRequestsBlockedPoolMax
Format:
public abstract int numberOfRequestsBlockedPoolMax()
Retrieves the number of requests that the IBM Data Server Driver for JDBC
and SQLJ made to the pool that the pool blocked because the maximum
number for the pool was reached.
removedObjectCount
Format:
public abstract int removedObjectCount()
Retrieves the number of objects that have been deleted from the pool since the
pool was created.
shortestBlockedRequestTime
Format:
public abstract long shortestBlockedRequestTime()
Retrieves the shortest amount of time that a request was blocked, in
milliseconds.
successfullRequestsFromPool
Format:
public abstract int successfullRequestsFromPool()
Retrieves the number of successful requests that the IBM Data Server Driver
for JDBC and SQLJ has made to the pool since the pool was created. A
successful request means that the pool returned an object.
totalPoolObjects
Format:
public abstract int totalPoolObjects()
Retrieves the number of objects that are currently in the pool.
totalRequestsToPool
Format:
public abstract int totalRequestsToPool()
Retrieves the total number of requests that the IBM Data Server Driver for
JDBC and SQLJ has made to the pool since the pool was created.
totalTimeBlocked
Format:
396
Application Programming Guide and Reference for Java
public abstract long totalTimeBlocked()
Retrieves the total time in milliseconds for requests that were blocked by the
pool. This time can be much larger than the elapsed execution time of the
application if the application uses multiple threads.
DB2PreparedStatement interface
The com.ibm.db2.jcc.DB2PreparedStatement interface extends the
com.ibm.db2.jcc.DB2Statement and java.sql.PreparedStatement interfaces.
DB2PreparedStatement fields
The following constants are defined only for the IBM Data Server Driver for JDBC
and SQLJ.
public static DBIndicatorDefault DB_PARAMETER_DEFAULT
This constant can be used with standard interfaces, such as
PreparedStatement.setObject or ResultSet.updateObject to indicate that the
default value is assigned to the associated parameter.
public static DBIndicatorUnassigned DB_PARAMETER_UNASSIGNED
This constant can be used with standard interfaces, such as
PreparedStatement.setObject or ResultSet.updateObject to indicate that the
associated parameter is unaassigned.
DB2PreparedStatement methods
The following methods are defined only for the IBM Data Server Driver for JDBC
and SQLJ.
executeDB2QueryBatch
Format:
public void executeDB2QueryBatch()
throws java.sql.SQLException
Executes a statement batch that contains queries with parameters.
This method is not supported for connections to IBM Informix data sources.
getDBGeneratedKeys
Format:
public java.sql.ResultSet[] getDBGeneratedKeys()
throws java.sql.SQLException
Retrieves automatically generated keys that were created when INSERT
statements were executed in a batch. Each ResultSet object that is returned
contains the automatically generated keys for a single statement in the batch.
getDBGeneratedKeys returns an array of length 0 under the following
conditions:
v getDBGeneratedKeys is called out of sequence. For example, if
getDBGeneratedKeys is called before executeBatch, an array of length 0 is
returned.
v The PreparedStatement that is executed in a batch was not created using one
of the following methods:
Connection.prepareStatement(String sql, int[] autoGeneratedKeys)
Connection.prepareStatement(String sql, String[] autoGeneratedColumnNames)
Connection.prepareStatement(String sql, Statement.RETURN_GENERATED_KEYS)
Chapter 7. JDBC and SQLJ reference information
397
If getDBGeneratedKeys is called against a PreparedStatement that was created
using one of the previously listed methods, and the PreparedStatement is not
in a batch, a single ResultSet is returned.
getEstimateCost
Format:
public int getEstimateCost()
throws java.sql.SQLException
Returns the estimated cost of an SQL statement from the data server after the
data server dynamically prepares the statement successfully. This value is the
same as the fourth element in the sqlerrd array of the SQLCA.
If the deferPrepares property is set to true, calling getEstimateCost causes the
data server to execute a dynamic prepare operation.
If the SQL statement cannot be prepared, or the data server does not return
estimated cost information at prepare time, getEstimateCost returns -1.
getEstimateRowCount
Format:
public int getEstimateRowCount()
throws java.sql.SQLException
Returns the estimated row count for an SQL statement from the data server
after the data server dynamically prepares the statement successfully. This
value is the same as the third element in the sqlerrd array of the SQLCA.
If the deferPrepares property is set to true, calling getEstimateRowCount causes
the data server to execute a dynamic prepare operation.
If the SQL statement cannot be prepared, or the data server does not return
estimated row count information at prepare time, getEstimateRowCount returns
-1.
setDB2BlobFileReference
Format:
public void setDB2BlobFileReference(int parameterIndex,
com.ibm.db2.jcc.DB2BlobFileReference fileRef)
throws java.sql.SQLException
Assigns a BLOB file reference variable value to a parameter.
This method applies only to IBM Data Server Driver for JDBC and SQLJ type 2
connectivity to DB2 for z/OS.
Parameters:
parameterIndex
The index of the parameter marker to which a file reference variable value
is assigned.
fileRef
The com.ibm.db2.jcc.DB2BlobFileReference value that is assigned to the
parameter marker.
setDB2ClobFileReference
Format:
public void setDB2ClobFileReference(int parameterIndex,
com.ibm.db2.jcc.DB2ClobFileReference fileRef)
throws java.sql.SQLException
398
Application Programming Guide and Reference for Java
Assigns a CLOB file reference variable value to a parameter.
This method applies only to IBM Data Server Driver for JDBC and SQLJ type 2
connectivity to DB2 for z/OS.
Parameters:
parameterIndex
The index of the parameter marker to which a file reference variable value
is assigned.
fileRef
The com.ibm.db2.jcc.DB2ClobFileReference value that is assigned to the
parameter marker.
setDB2XmlAsBlobFileReference
Format:
public void setDB2XmlAsBlobFileReference(int parameterIndex,
com.ibm.db2.jcc.DB2XmlAsBlobFileReference fileRef)
throws java.sql.SQLException
Assigns a XML AS BLOB file reference variable value to a parameter.
This method applies only to IBM Data Server Driver for JDBC and SQLJ type 2
connectivity to DB2 for z/OS.
Parameters:
parameterIndex
The index of the parameter marker to which a file reference variable value
is assigned.
fileRef
The com.ibm.db2.jcc.DB2XmlAsBlobFileReference value that is assigned to
the parameter marker.
setDB2XmlAsClobFileReference
Format:
public void setDB2XmlAsClobFileReference(int parameterIndex,
com.ibm.db2.jcc.DB2XmlAsClobFileReference fileRef)
throws java.sql.SQLException
Assigns a XML AS CLOB file reference variable value to a parameter.
This method applies only to IBM Data Server Driver for JDBC and SQLJ type 2
connectivity to DB2 for z/OS.
Parameters:
parameterIndex
The index of the parameter marker to which a file reference variable value
is assigned.
fileRef
The com.ibm.db2.jcc.DB2XmlAsClobFileReference value that is assigned to
the parameter marker.
setDBTimestamp
Format:
public void setDBTimestamp(int parameterIndex,
DBTimestamp timestamp)
throws java.sql.SQLException
Assigns a DBTimestamp value to a parameter.
Chapter 7. JDBC and SQLJ reference information
399
Parameters:
parameterIndex
The index of the parameter marker to which a DBTimestamp variable value
is assigned.
timestamp
The DBTimestamp value that is assigned to the parameter marker.
This method is not supported for connections to IBM Informix data sources.
setJccArrayAtName
Format:
public void setJccArrayAtName(String parameterMarkerName,
java.sql.Array x)
throws java.sql.SQLException
Assigns a java.sql.Array value to a named parameter marker.
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
Parameters:
parameterMarkerName
The name of the parameter marker to which a value is assigned.
x
The java.sql.Array value that is assigned to the named parameter marker.
setJccAsciiStreamAtName
Formats:
Supported by the IBM Data Server Driver for JDBC and SQLJ version 3.57 and
later:
public void setJccAsciiStreamAtName(String parameterMarkerName,
java.io.InputStream x, int length)
throws java.sql.SQLException
Supported by the IBM Data Server Driver for JDBC and SQLJ version 4.7 and
later:
public void setJccAsciiStreamAtName(String parameterMarkerName,
java.io.InputStream x)
throws java.sql.SQLException
public void setJccAsciiStreamAtName(String parameterMarkerName,
java.io.InputStream x, long length)
throws java.sql.SQLException
Assigns an ASCII value in a java.io.InputStream to a named parameter
marker.
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
Parameters:
parameterMarkerName
The name of the parameter marker to which a value is assigned.
x
The ASCII java.io.InputStream value that is assigned to the parameter
marker.
length
The length in bytes of the java.io.InputStream value that is assigned to
the named parameter marker.
400
Application Programming Guide and Reference for Java
setJccBigDecimalAtName
Format:
public void setJccBigDecimalAtName(String parameterMarkerName,
java.math.BigDecimal x)
throws java.sql.SQLException
Assigns a java.math.BigDecimal value to a named parameter marker.
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
Parameters:
parameterMarkerName
The name of the parameter marker to which a value is assigned.
x
The java.math.BigDecimal value that is assigned to the named parameter
marker.
setJccBinaryStreamAtName
Formats:
Supported by the IBM Data Server Driver for JDBC and SQLJ version 3.57 and
later:
public void setJccBinaryStreamAtName(String parameterMarkerName,
java.io.InputStream x, int length)
throws java.sql.SQLException
Supported by the IBM Data Server Driver for JDBC and SQLJ version 4.7 and
later:
public void setJccBinaryStreamAtName(String parameterMarkerName,
java.io.InputStream x)
throws java.sql.SQLException
public void setJccBinaryStreamAtName(String parameterMarkerName,
java.io.InputStream x, long length)
throws java.sql.SQLException
Assigns a binary value in a java.io.InputStream to a named parameter
marker.
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
Parameters:
parameterMarkerName
The name of the parameter marker to which a value is assigned.
x
The binary java.io.InputStream value that is assigned to the parameter
marker.
length
The number of bytes of the java.io.InputStream value that are assigned to
the named parameter marker.
setJccBlobAtName
Formats:
Supported by the IBM Data Server Driver for JDBC and SQLJ version 3.57 and
later:
public void setJccBlobAtName(String parameterMarkerName,
java.sql.Blob x)
throws java.sql.SQLException
Chapter 7. JDBC and SQLJ reference information
401
Supported by the IBM Data Server Driver for JDBC and SQLJ version 4.7 and
later:
public void setJccBlobAtName(String parameterMarkerName,
java.io.InputStream x)
throws java.sql.SQLException
public void setJccBlobAtName(String parameterMarkerName,
java.io.InputStream x, long length)
throws java.sql.SQLException
Assigns a BLOB value to a named parameter marker.
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
Parameters:
parameterMarkerName
The name of the parameter marker to which a value is assigned.
x
The java.sql.Blob value or java.io.InputStream value that is assigned to
the parameter marker.
length
The number of bytes of the java.io.InputStream value that are assigned to
the named parameter marker.
setJccBooleanAtName
Format:
public void setJccBooleanAtName(String parameterMarkerName,
boolean x)
throws java.sql.SQLException
Assigns a boolean value to a named parameter marker.
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
Parameters:
parameterMarkerName
The name of the parameter marker to which a value is assigned.
x
The boolean value that is assigned to the named parameter marker.
setJccByteAtName
Format:
public void setJccByteAtName(String parameterMarkerName,
byte x)
throws java.sql.SQLException
Assigns a byte value to a named parameter marker.
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
Parameters:
parameterMarkerName
The name of the parameter marker to which a value is assigned.
x
The byte value that is assigned to the named parameter marker.
setJccBytesAtName
Format:
402
Application Programming Guide and Reference for Java
public void setJccBytesAtName(String parameterMarkerName,
byte[] x)
throws java.sql.SQLException
Assigns an array of byte values to a named parameter marker.
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
Parameters:
parameterMarkerName
The name of the parameter marker to which a value is assigned.
x
The byte array that is assigned to the named parameter marker.
setJccCharacterStreamAtName
Formats:
Supported by the IBM Data Server Driver for JDBC and SQLJ version 3.57 and
later:
public void setJccCharacterStreamAtName(String parameterMarkerName,
java.io.Reader x, int length)
throws java.sql.SQLException
Supported by the IBM Data Server Driver for JDBC and SQLJ version 4.7 and
later:
public void setJccCharacterStreamAtName(String parameterMarkerName,
java.io.Reader x)
throws java.sql.SQLException
public void setJccCharacterStreamAtName(String parameterMarkerName,
java.io.Reader x, long length)
throws java.sql.SQLException
Assigns a Unicode value in a java.io.Reader to a named parameter marker.
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
Parameters:
parameterMarkerName
The name of the parameter marker to which a value is assigned.
x
The Unicode java.io.Reader value that is assigned to the named
parameter marker.
length
The number of characters of the java.io.InputStream value that are
assigned to the named parameter marker.
setJccClobAtName
Formats:
Supported by the IBM Data Server Driver for JDBC and SQLJ version 3.57 and
later:
public void setJccClobAtName(String parameterMarkerName,
java.sql.Clob x)
throws java.sql.SQLException
Supported by the IBM Data Server Driver for JDBC and SQLJ version 4.7 and
later:
Chapter 7. JDBC and SQLJ reference information
403
public void setJccClobAtName(String parameterMarkerName,
java.io.Reader x)
throws java.sql.SQLException
public void setJccClobAtName(String parameterMarkerName,
java.io.Reader x, long length)
throws java.sql.SQLException
Assigns a CLOB value to a named parameter marker.
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
Parameters:
parameterMarkerName
The name of the parameter marker to which a value is assigned.
x
The java.sql.Clob value or java.io.Reader value that is assigned to the
named parameter marker.
length
The number of bytes of the java.io.InputStream value that are assigned to
the named parameter marker.
setJccDateAtName
Formats:
public void setJccDateAtName(String parameterMarkerName,
java.sql.Date x)
throws java.sql.SQLException
public void setJccDateAtName(String parameterMarkerName,
java.sql.Date x,
java.util.Calendar cal)
throws java.sql.SQLException
Assigns a java.sql.Date value to a named parameter marker.
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
Parameters:
parameterMarkerName
The name of the parameter marker to which a value is assigned.
x
The java.sql.Date value that is assigned to the named parameter marker.
cal The java.util.Calendar object that the IBM Data Server Driver for JDBC
and SQLJ uses to construct the date.
setJccDB2BlobFileReferenceAtName
Format:
public void setJccDB2BlobFileReferenceAtName(int parameterMarkerName,
com.ibm.db2.jcc.DB2BlobFileReference fileRef)
throws java.sql.SQLException
Assigns a BLOB file reference variable value to a named parameter marker.
This method applies only to IBM Data Server Driver for JDBC and SQLJ type 2
connectivity to DB2 for z/OS.
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
Parameters:
404
Application Programming Guide and Reference for Java
parameterMarkerName
The name of the parameter marker to which a file reference variable value
is assigned.
fileRef
The com.ibm.db2.jcc.DB2BlobFileReference value that is assigned to the
named parameter marker.
setJccDB2ClobFileReferenceAtName
Format:
public void setJccDB2ClobFileReferenceAtName(int parameterMarkerName,
com.ibm.db2.jcc.DB2ClobFileReference fileRef)
throws java.sql.SQLException
Assigns a CLOB file reference variable value to a named parameter marker.
This method applies only to IBM Data Server Driver for JDBC and SQLJ type 2
connectivity to DB2 for z/OS.
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
Parameters:
parameterMarkerName
The name of the parameter marker to which a file reference variable value
is assigned.
fileRef
The com.ibm.db2.jcc.DB2ClobFileReference value that is assigned to the
named parameter marker.
setJccDB2XmlAsBlobFileReferenceAtName
Format:
public void setJccDB2XmlAsBlobFileReferenceAtName(String parameterMarkerName,
com.ibm.db2.jcc.DB2XmlAsBlobFileReference fileRef)
throws java.sql.SQLException
Assigns a XML AS BLOB file reference variable value to a named parameter
marker.
This method applies only to IBM Data Server Driver for JDBC and SQLJ type 2
connectivity to DB2 for z/OS Version 9 or later.
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
Parameters:
parameterMarkerName
The name of the parameter marker to which a file reference variable value
is assigned.
fileRef
The com.ibm.db2.jcc.DB2XmlAsBlobFileReference value that is assigned to
the named parameter marker.
setJccDB2XmlAsClobFileReferenceAtName
Format:
public void setJccDB2XmlAsClobFileReferenceAtName(int parameterMarkerName,
com.ibm.db2.jcc.DB2XmlAsClobFileReference fileRef)
throws java.sql.SQLException
Chapter 7. JDBC and SQLJ reference information
405
Assigns a XML AS CLOB file reference variable value to a named parameter
marker.
This method applies only to IBM Data Server Driver for JDBC and SQLJ type 2
connectivity to DB2 for z/OS Version 9 or later.
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
Parameters:
parameterMarkerName
The name of the parameter marker to which a file reference variable value
is assigned.
fileRef
The com.ibm.db2.jcc.DB2XmlAsClobFileReference value that is assigned to
the named parameter marker.
setJccDBTimestampAtName
Format:
public void setJccDBTimestampAtName(String parameterMarkerName,
DBTimestamp timestamp)
throws java.sql.SQLException
Assigns a DBTimestamp value to a named parameter marker.
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
Parameters:
parameterMarkerName
The name of the parameter marker to which a DBTimestamp variable value
is assigned.
timestamp
The DBTimestamp value that is assigned to the named parameter marker.
This method is not supported for connections to IBM Informix data sources.
setJccDBDefaultAtName
Formats:
public void setJccDBDefaultAtName(String parameterMarkerName)
throws SQLException
Assigns the default value to a named parameter marker. Execution of
setJccDBDefaultAtName produces the same results as using the literal
DEFAULT in the SQL string, instead of the parameter marker name.
Parameters:
parameterMarkerName
The name of the parameter marker to which a value is assigned.
This method is not supported for connections to IBM Informix data sources.
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
setJccDBUnassignedAtName
Formats:
public void setJccDBUnassignedAtName(String parameterMarkerName)
throws SQLException
406
Application Programming Guide and Reference for Java
Does not assign a value to the specified named parameter. Execution of
setJccDBUnassignedAtName produces the same result as if the specified
parameter marker name had not appeared in the SQL string.
Parameters:
parameterMarkerName
The name of the parameter marker whose value is to be unassigned.
This method is not supported for connections to IBM Informix data sources.
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
setJccDoubleAtName
Format:
public void setJccDoubleAtName(String parameterMarkerName,
double x)
throws java.sql.SQLException
Assigns a value of type double to a named parameter marker.
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
Parameters:
parameterMarkerName
The name of the parameter marker to which a value is assigned.
x
The value of type double that is assigned to the parameter marker.
setJccFloatAtName
Format:
public void setJccFloatAtName(String parameterMarkerName,
float x)
throws java.sql.SQLException
Assigns a value of type float to a named parameter marker.
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
Parameters:
parameterMarkerName
The name of the parameter marker to which a value is assigned.
x
The value of type float that is assigned to the parameter marker.
setJccIntAtName
Format:
public void setJccIntAtName(String parameterMarkerName,
int x)
throws java.sql.SQLException
Assigns a value of type int to a named parameter marker.
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
Parameters:
parameterMarkerName
The name of the parameter marker to which a value is assigned.
Chapter 7. JDBC and SQLJ reference information
407
x
The value of type int that is assigned to the parameter marker.
setJccLongAtName
Format:
public void setJccLongAtName(String parameterMarkerName,
long x)
throws java.sql.SQLException
Assigns a value of type long to a named parameter marker.
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
Parameters:
parameterMarkerName
The name of the parameter marker to which a value is assigned.
x
The value of type long that is assigned to the parameter marker.
setJccNullAtName
Format:
public void setJccNullAtName(String parameterMarkerName,
int jdbcType)
throws java.sql.SQLException
public void setJccNullAtName(String parameterMarkerName,
int jdbcType,
String typeName)
throws java.sql.SQLException
Assigns the SQL NULL value to a named parameter marker.
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
Parameters:
parameterMarkerName
The name of the parameter marker to which a value is assigned.
jdbcType
The JDBC type code of the NULL value that is assigned to the parameter
marker, as defined in java.sql.Types.
typeName
If jdbcType is java.sql.Types.DISTINCT or java.sql.Types.REF, the
fully-qualified name of the SQL user-defined type of the NULL value that
is assigned to the parameter marker.
setJccObjectAtName
Formats:
public void setJccObjectAtName(String parameterMarkerName,
java.sql.Object x)
throws java.sql.SQLException
public void setJccObjectAtName(String parameterMarkerName,
java.sql.Object x,
int targetJdbcType)
throws java.sql.SQLException
public void setJccObjectAtName(String parameterMarkerName,
java.sql.Object x,
int targetJdbcType,
int scale)
throws java.sql.SQLException
Assigns a value with type java.lang.Object to a named parameter marker.
408
Application Programming Guide and Reference for Java
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
Parameters:
parameterMarkerName
The name of the parameter marker to which a value is assigned.
x
The value with type Object that is assigned to the parameter marker.
targetJdbcType
The data type, as defined in java.sql.Types, that is assigned to the input
value when it is sent to the data source.
scale
The scale of the value that is assigned to the parameter marker. This
parameter applies only to these cases:
v If targetJdbcType is java.sql.Types.DECIMAL or java.sql.Types.NUMERIC,
scale is the number of digits to the right of the decimal point.
v If x has type java.io.InputStream or java.io.Reader, scale is the this is
the length of the data in the Stream or Reader object.
setJccShortAtName
Format:
public void setJccShortAtName(String parameterMarkerName,
short x)
throws java.sql.SQLException
Assigns a value of type short to a named parameter marker.
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
Parameters:
parameterMarkerName
The name of the parameter marker to which a value is assigned.
x
The value of type short that is assigned to the parameter marker.
setJccSQLXMLAtName
Format:
public void setJccSQLXMLAtName(String parameterMarkerName,
java.sql.SQLXML x)
throws java.sql.SQLException
Assigns a value of type java.sql.SQLXML to a named parameter marker.
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
This method is supported only for connections to DB2 Database for Linux,
UNIX, and Windows Version 9.1 or later or DB2 for z/OS Version 9 or later.
Parameters:
parameterMarkerName
The name of the parameter marker to which a value is assigned.
x
The value of type java.sql.SQLXML that is assigned to the parameter
marker.
setJccStringAtName
Format:
Chapter 7. JDBC and SQLJ reference information
409
public void setJccStringAtName(String parameterMarkerName,
String x)
throws java.sql.SQLException
Assigns a value of type String to a named parameter marker.
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
Parameters:
parameterMarkerName
The name of the parameter marker to which a value is assigned.
x
The value of type String that is assigned to the parameter marker.
setJccTimeAtName
Formats:
public void setJccTimeAtName(String parameterMarkerName,
java.sql.Time x)
throws java.sql.SQLException
public void setJccTimeAtName(String parameterMarkerName,
java.sql.Time x,
java.util.Calendar cal)
throws java.sql.SQLException
Assigns a java.sql.Time value to a named parameter marker.
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
Parameters:
parameterMarkerName
The name of the parameter marker to which a value is assigned.
x
The java.sql.Time value that is assigned to the parameter marker.
cal The java.util.Calendar object that the IBM Data Server Driver for JDBC
and SQLJ uses to construct the time.
setJccTimestampAtName
Formats:
public void setJccTimestampAtName(String parameterMarkerName,
java.sql.Timestamp x)
throws java.sql.SQLException
public void setJccTimestampAtName(String parameterMarkerName,
java.sql.Timestamp x,
java.util.Calendar cal)
throws java.sql.SQLException
Assigns a java.sql.Timestamp value to a named parameter marker.
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
Parameters:
parameterMarkerName
The name of the parameter marker to which a value is assigned.
x
The java.sql.Timestamp value that is assigned to the parameter marker.
cal The java.util.Calendar object that the IBM Data Server Driver for JDBC
and SQLJ uses to construct the timestamp.
410
Application Programming Guide and Reference for Java
setJccUnicodeStreamAtName
Format:
public void setJccUnicodeStreamAtName(String parameterMarkerName,
java.io.InputStream x, int length)
throws java.sql.SQLException
Assigns a Unicode value in a java.io.InputStream to a named parameter
marker.
This method can be called only if the enableNamedParameterMarkers property
is set to DB2BaseDataSource.YES (1).
Parameters:
parameterMarkerName
The name of the parameter marker to which a value is assigned.
x
The Unicode java.io.InputStream value that is assigned to the parameter
marker.
length
The number of bytes of the java.io.InputStream value that are assigned to
the parameter marker.
setDBDefault
Formats:
public void setDBDefault(int parameterIndex)
throws SQLException
Assigns the default value to the specified parameter. Execution of setDBDefault
produces the same results as using the literal DEFAULT in the SQL string,
instead of the parameter.
Parameters:
parameterIndex
The number of the parameter whose value is being updated.
This method is not supported for connections to IBM Informix data sources.
setDBUnassigned
Formats:
public void setDBUnassigned(int parameterIndex)
throws SQLException
Does not assign a value to the specified parameter. Execution of
setDBUnassigned produces the same result as if the specified parameter had
not appeared in the SQL string.
Parameters:
parameterIndex
The number of the parameter whose value is to be unassigned.
This method is not supported for connections to IBM Informix data sources.
Related tasks
“Making batch queries in JDBC applications” on page 35
DB2ResultSet interface
The com.ibm.db2.jcc.DB2ResultSet interface is used to create objects from which
IBM Data Server Driver for JDBC and SQLJ-only query information can be
obtained.
Chapter 7. JDBC and SQLJ reference information
411
DB2ResultSet implements the java.sql.Wrapper interface.
DB2ResultSet methods
The following methods are defined only for the IBM Data Server Driver for JDBC
and SQLJ.
getDB2RowChangeToken
Format:
public long DB2ResultSet.getDB2RowChangeToken()
throws java.sql.SQLException
Returns the row change token for the current row, if it is available. Returns 0 if
optimistic locking columns were not requested or are not available.
This method applies only to connections to DB2 Database for Linux, UNIX,
and Windows.
getDB2RID
Format:
public Object DB2ResultSet.getDB2RID()
throws java.sql.SQLException
Returns the RID for the current row, if it is available. The RID is available if
optimistic locking columns were requested and are available. Returns null if
optimistic locking columns were not requested or are not available.
This method applies only to connections to DB2 Database for Linux, UNIX,
and Windows.
getDB2RIDType
Format:
public int DB2ResultSet.getDB2RIDType()
throws java.sql.SQLException
Returns the data type of the RID column in a DB2ResultSet. The returned
value maps to a java.sql.Types constant. If the DB2ResultSet does not contain
a RID column, java.sql.Types.NULL is returned.
This method applies only to connections to DB2 Database for Linux, UNIX,
and Windows.
getDBTimestamp
Formats:
public DBTimestamp getDBTimestamp(int parameterIndex)
throws SQLException
public DBTimestamp getDBTimestamp(String parameterName)
throws SQLException
Returns the value in the current row of a TIMESTAMP or TIMESTAMP WITH
TIME ZONE column that is in a DB2ResultSet object as a DBTimestamp object.
For a TIMESTAMP column, the returned value has the local time zone. If the
value of the DB2ResultSet column is NULL, the returned value is null.
Parameters:
parameterIndex
The number of the column in the DB2ResultSet whose value is being
retrieved.
412
Application Programming Guide and Reference for Java
parameterName
The name of the column in the DB2ResultSet whose value is being
retrieved.
updateDBDefault
Formats:
public void updateDBDefault(int parameterIndex)
throws SQLException
public void updateDBDefault(String columnName)
throws SQLException
Assigns the default value to the specified column in a DB2ResultSet object.
This method does not update the underlying table.
Parameters:
parameterIndex
The number of the column in the DB2ResultSet whose value is being
updated.
columnName
The name of the column in the DB2ResultSet whose value is being
updated.
This method is not supported for connections to IBM Informix data sources.
DB2ResultSetMetaData interface
The com.ibm.db2.jcc.DB2ResultSetMetaData interface provides methods that
provide information about a ResultSet object.
Before a com.ibm.db2.jcc.DB2ResultSetMetaData method can be used, a
java.sql.ResultSetMetaData object that is returned from a
java.sql.ResultSet.getMetaData call needs to be cast to
com.ibm.db2.jcc.DB2ResultSetMetaData.
DB2ResultSetMetaData methods:
The following methods are defined only for the IBM Data Server Driver for JDBC
and SQLJ.
isDB2ColumnNameDerived
Format:
public boolean isDB2ColumnNameDerived (int column)
throws java.sql.SQLException
Returns true if the name of a ResultSet column is in the SQL SELECT list that
generated the ResultSet.
For example, suppose that a ResultSet is generated from the SQL statement
SELECT EMPNAME, SUM(SALARY) FROM EMP. Column name EMPNAME
is derived from the SQL SELECT list, but the name of the column in the
ResultSet that corresponds to SUM(SALARY) is not derived from the SELECT
list.
Parameter descriptions:
column
The ordinal position of a column in the ResultSet.
Chapter 7. JDBC and SQLJ reference information
413
DB2RowID interface
The com.ibm.db2.jcc.DB2RowID interface is used for declaring Java objects for use
with the SQL ROWID data type.
The com.ibm.db2.jcc.DB2RowID interface does not apply to connection to IBM
Informix.
DB2RowID methods
The following method is defined only for the IBM Data Server Driver for JDBC
and SQLJ.
getBytes
Format:
public byte[] getBytes()
Converts a com.ibm.jcc.DB2RowID object to bytes.
Related concepts
“ROWIDs in JDBC with the IBM Data Server Driver for JDBC and SQLJ” on page
57
“ROWIDs in SQLJ with the IBM Data Server Driver for JDBC and SQLJ” on page
155
DB2SimpleDataSource class
The com.ibm.db2.jcc.DB2SimpleDataSource class extends the DB2BaseDataSource
class.
A DB2BaseDataSource object does not support connection pooling or distributed
transactions. It contains all of the properties and methods that the
DB2BaseDataSource class contains. In addition, DB2SimpleDataSource contains the
following IBM Data Server Driver for JDBC and SQLJ-only properties.
DB2SimpleDataSource implements the java.sql.Wrapper interface.
DB2SimpleDataSource properties
The following property is defined only for the IBM Data Server Driver for JDBC
and SQLJ. See "Properties for the IBM Data Server Driver for JDBC and SQLJ" for
an explanation of this property.
String com.ibm.db2.jcc.DB2SimpleDataSource.password
DB2SimpleDataSource methods
The following method is defined only for the IBM Data Server Driver for JDBC
and SQLJ.
setPassword
Format:
public void setPassword(String password)
Sets the password for the DB2SimpleDataSource object. There is no
corresponding getPassword method. Therefore, the password cannot be
encrypted because there is no way to retrieve the password so that you can
decrypt it.
414
Application Programming Guide and Reference for Java
Related tasks
“Connecting to a data source using the DataSource interface” on page 17
“Creating and deploying DataSource objects” on page 20
DB2Sqlca class
The com.ibm.db2.jcc.DB2Sqlca class is an encapsulation of the SQLCA.
DB2Sqlca methods
The following methods are defined only for the IBM Data Server Driver for JDBC
and SQLJ.
getMessage
Format:
public abstract String getMessage()
Returns error message text.
getSqlCode
Format:
public abstract int getSqlCode()
Returns an SQL error code value.
getSqlErrd
Format:
public abstract int[] getSqlErrd()
Returns an array, each element of which contains an SQLCA SQLERRD.
getSqlErrmc
Format:
public abstract String getSqlErrmc()
Returns a string that contains the SQLCA SQLERRMC values, delimited with
spaces.
getSqlErrmcTokens
Format:
public abstract String[] getSqlErrmcTokens()
Returns an array, each element of which contains an SQLCA SQLERRMC
token.
getSqlErrp
Format:
public abstract String getSqlErrp()
Returns the SQLCA SQLERRP value.
getSqlState
Format:
public abstract String getSqlState()
Returns the SQLCA SQLSTATE value.
getSqlWarn
Format:
Chapter 7. JDBC and SQLJ reference information
415
public abstract char[] getSqlWarn()
Returns an array, each element of which contains an SQLCA SQLWARN value.
Related tasks
“Handling an SQLException under the IBM Data Server Driver for JDBC and
SQLJ” on page 102
“Handling SQL warnings in an SQLJ application” on page 170
Related reference
Description of SQLCA fields (DB2 SQL)
DB2Statement interface
The com.ibm.db2.jcc.DB2Statement interface extends the java.sql.Statement
interface.
DB2Statement implements the java.sql.Wrapper interface.
DB2Statement methods
The following methods are defined only for the IBM Data Server Driver for JDBC
and SQLJ.
getDB2ClientProgramId
Format:
public String getDB2ClientProgramId()
throws java.sql.SQLException
Returns the user-defined client program identifier for the connection, which is
stored on the data source.
getDB2ClientProgramId does not apply to DB2 Database for Linux, UNIX, and
Windows data servers.
setDB2ClientProgramId
Format:
public abstract void setDB2ClientProgramId(String program-ID)
throws java.sql.SQLException
Sets a user-defined program identifier for the connection on a data server. That
program identifier is an 80-byte string that is used to identify the caller.
setDB2ClientProgramId does not apply to DB2 Database for Linux, UNIX, and
Windows data servers.
The DB2 for z/OS server places the string in IFCID 316 trace records along
with other statistics, so that you can identify which program is associated with
a particular SQL statement.
getIDSBigSerial
Format:
public int getIDSBigSerial()
throws java.sql.SQLException
Retrieves an automatically generated key from a BIGSERIAL column after the
automatically generated key was inserted by a previously executed INSERT
statement.
416
Application Programming Guide and Reference for Java
The following conditions must be true for getIDSBigSerial to execute
successfully:
v The INSERT statement is the last SQL statement that is executed before this
method is called.
v The table into which the row is inserted contains a BIGSERIAL column.
v The form of the JDBC Connection.prepareStatement method or
Statement.executeUpdate method that prepares or executes the INSERT
statement does not have parameters that request automatically generated
keys.
This method applies only to connections to IBM Informix databases.
getIDSSerial
Format:
public int getIDSSerial()
throws java.sql.SQLException
Retrieves an automatically generated key from a SERIAL column after the
automatically generated key was inserted by a previously executed INSERT
statement.
The following conditions must be true for getIDSSerial to execute
successfully:
v The INSERT statement is the last SQL statement that is executed before this
method is called.
v The table into which the row is inserted contains a SERIAL column.
v The form of the JDBC Connection.prepareStatement method or
Statement.executeUpdate method that prepares or executes the INSERT
statement does not have parameters that request automatically generated
keys.
This method applies only to connections to IBM Informix databases.
getIDSSerial8
Format:
public long getIDSSerial8()
throws java.sql.SQLException
Retrieves an automatically generated key from a SERIAL8 column after the
automatically generated key was inserted by a previously executed INSERT
statement.
The following conditions must be true for getIDSSerial8 to execute
successfully:
v The INSERT statement is the last SQL statement that is executed before this
method is called.
v The table into which the row is inserted contains a SERIAL8 column.
v The form of the JDBC Connection.prepareStatement method or
Statement.executeUpdate method that prepares or executes the INSERT
statement does not have parameters that request automatically generated
keys.
This method applies only to connections to IBM Informix data sources.
getIDSSQLStatementOffSet
Format:
public int getIDSSQLStatementOffSet()
throws java.sql.SQLException
Chapter 7. JDBC and SQLJ reference information
417
After an SQL statement executes on an IBM Informix data source, if the
statement has a syntax error, getIDSSQLStatementOffSet returns the offset into
the statement text of the syntax error.
getIDSSQLStatementOffSet returns:
v 0, if the statement does not have a syntax error.
v -1, if the data source is not IBM Informix.
This method applies only to connections to IBM Informix data sources.
Related reference
“DB2PreparedStatement interface” on page 397
DB2SystemMonitor interface
The com.ibm.db2.jcc.DB2SystemMonitor interface is used for collecting system
monitoring data for a connection. Each connection can have one DB2SystemMonitor
instance.
DB2SystemMonitor fields
The following fields are defined only for the IBM Data Server Driver for JDBC and
SQLJ.
public final static int RESET_TIMES
public final static int ACCUMULATE_TIMES
These values are arguments for the DB2SystemMonitor.start method.
RESET_TIMES sets time counters to zero before monitoring starts.
ACCUMULATE_TIMES does not set time counters to zero.
DB2SystemMonitor methods
The following methods are defined only for the IBM Data Server Driver for JDBC
and SQLJ.
enable
Format:
public void enable(boolean on)
throws java.sql.SQLException
Enables the system monitor that is associated with a connection. This method
cannot be called during monitoring. All times are reset when enable is
invoked.
getApplicationTimeMillis
Format:
public long getApplicationTimeMillis()
throws java.sql.SQLException
Returns the sum of the application, JDBC driver, network I/O, and database
server elapsed times. The time is in milliseconds.
A monitored elapsed time interval is the difference, in milliseconds, between
these points in the JDBC driver processing:
Interval beginning
When start is called.
Interval end
When stop is called.
418
Application Programming Guide and Reference for Java
getApplicationTimeMillis returns 0 if system monitoring is disabled. Calling
this method without first calling the stop method results in an SQLException.
getCoreDriverTimeMicros
Format:
public long getCoreDriverTimeMicros()
throws java.sql.SQLException
Returns the sum of elapsed monitored API times that were collected while
system monitoring was enabled. The time is in microseconds.
A monitored API is a JDBC driver method for which processing time is
collected. In general, elapsed times are monitored only for APIs that might
result in network I/O or database server interaction. For example,
PreparedStatement.setXXX methods and ResultSet.getXXX methods are not
monitored.
Monitored API elapsed time includes the total time that is spent in the driver
for a method call. This time includes any network I/O time and database
server elapsed time.
A monitored API elapsed time interval is the difference, in microseconds,
between these points in the JDBC driver processing:
Interval beginning
When a monitored API is called by the application.
Interval end
Immediately before the monitored API returns control to the application.
getCoreDriverTimeMicros returns 0 if system monitoring is disabled. Calling
this method without first calling the stop method, or calling this method when
the underlying JVM does not support reporting times in microseconds results
in an SQLException.
getNetworkIOTimeMicros
Format:
public long getNetworkIOTimeMicros()
throws java.sql.SQLException
Returns the sum of elapsed network I/O times that were collected while
system monitoring was enabled. The time is in microseconds.
Elapsed network I/O time includes the time to write and read DRDA data
from network I/O streams. A network I/O elapsed time interval is the time
interval to perform the following operations in the JDBC driver:
v Issue a TCP/IP command to send a DRDA message to the database server.
This time interval is the difference, in microseconds, between points
immediately before and after a write and flush to the network I/O stream is
performed.
v Issue a TCP/IP command to receive DRDA reply messages from the
database server. This time interval is the difference, in microseconds,
between points immediately before and after a read on the network I/O
stream is performed.
Network I/O time intervals are captured for all send and receive operations,
including the sending of messages for commits and rollbacks.
The time spent waiting for network I/O might be impacted by delays in CPU
dispatching at the database server for low-priority SQL requests.
Chapter 7. JDBC and SQLJ reference information
419
getNetworkIOTimeMicros returns 0 if system monitoring is disabled. Calling this
method without first calling the stop method, or calling this method when the
underlying JVM does not support reporting times in microseconds results in an
SQLException.
getServerTimeMicros
Format:
public long getServerTimeMicros()
throws java.sql.SQLException
Returns the sum of all reported database server elapsed times that were
collected while system monitoring was enabled. The time is in microseconds.
The database server reports elapsed times under these conditions:
v The database server supports returning elapsed time data to the client.
DB2 Database for Linux, UNIX, and Windows Version 9.5 and later and DB2
for z/OS support this function.
v The database server performs operations that can be monitored. For
example, database server elapsed time is not returned for commits or
rollbacks.
For IBM Data Server Driver for JDBC and SQLJ type 2 connectivity to DB2
Database for Linux, UNIX, and Windows, and IBM Data Server Driver for JDBC and
SQLJ type 4 connectivity: The database server elapsed time is defined as the
elapsed time to parse the request data stream, process the command, and
generate the reply data stream at the database server. Network time to receive
or send the data stream is not included. The database server elapsed time
interval is the difference, in microseconds, between these points in the database
server processing:
Interval beginning
When the operating system dispatches the database server to process a
TCP/IP message that is received from the JDBC driver.
Interval end
When the database server is ready to issue the TCP/IP command to return
the reply message to the client.
For IBM Data Server Driver for JDBC and SQLJ type 2 connectivity to DB2 for
z/OS: The database server elapsed time interval is the difference, in
microseconds, between these points in the JDBC driver native processing:
Interval beginning
The z/OS Store Clock (STCK) value when a JDBC driver native method
calls the RRS attachment facility to process an SQL request.
Interval end
The z/OS Store Clock (STCK) value when control returns to the JDBC
driver native method following an RRS attachment facility call to process
an SQL request.
getServerTimeMicros returns 0 if system monitoring is disabled. Calling this
method without first calling the stop method results in an SQLException.
start
Format:
public void start (int lapMode)
throws java.sql.SQLException
420
Application Programming Guide and Reference for Java
If the system monitor is enabled, start begins the collection of system
monitoring data for a connection. Valid values for lapMode are RESET_TIMES
or ACCUMULATE_TIMES.
Calling this method with system monitoring disabled does nothing. Calling
this method more than once without an intervening stop call results in an
SQLException.
stop
Format:
public void stop()
throws java.sql.SQLException
If the system monitor is enabled, stop ends the collection of system monitoring
data for a connection. After monitoring is stopped, monitored times can be
obtained with the getXXX methods of DB2SystemMonitor.
Calling this method with system monitoring disabled does nothing. Calling
this method without first calling start, or calling this method more than once
without an intervening start call results in an SQLException.
Related tasks
Chapter 16, “System monitoring for the IBM Data Server Driver for JDBC and
SQLJ,” on page 579
DB2TraceManager class
The com.ibm.db2.jcc.DB2TraceManager class controls the global log writer.
The global log writer is driver-wide, and applies to all connections. The global log
writer overrides any other JDBC log writers. In addition to starting the global log
writer, the DB2TraceManager class provides the ability to suspend and resume
tracing of any type of log writer. That is, the suspend and resume methods of the
DB2TraceManager class apply to all current and future DriverManager log writers,
DataSource log writers, or IBM Data Server Driver for JDBC and SQLJ-only
connection-level log writers.
DB2TraceManager methods
getTraceManager
Format:
static public DB2TraceManager getTraceManager()
throws java.sql.SQLException
Gets an instance of the global log writer.
setLogWriter
Formats:
public abstract void setLogWriter(String traceDirectory,
String baseTraceFileName, int traceLevel)
throws java.sql.SQLException
public abstract void setLogWriter(String traceFile,
boolean fileAppend, int traceLevel)
throws java.sql.SQLException
public abstract void setLogWriter(java.io.PrintWriter logWriter,
int traceLevel)
throws java.sql.SQLException
Enables a global trace. After setLogWriter is called, all calls for DataSource or
Connection traces are discarded until DB2TraceManager.unsetLogWriter is
called.
Chapter 7. JDBC and SQLJ reference information
421
When setLogWriter is called, all future Connection or DataSource traces are
redirected to a trace file or PrintWriter, depending on the form of
setLogWriter that you use. If the global trace is suspended when setLogWriter
is called, the specified settings take effect when the trace is resumed.
Parameter descriptions:
traceDirectory
Specifies a directory into which global trace information is written. This
setting overrides the settings of the traceDirectory and logWriter properties
for a DataSource or DriverManager connection.
When the form of setLogWriter with the traceDirectory parameter is used,
the JDBC driver sets the traceFileAppend property to false when
setLogWriter is called, which means that the existing log files are
overwritten. Each JDBC driver connection is traced to a different file in the
specified directory. The naming convention for the files in that directory
depends on whether a non-null value is specified for baseTraceFileName:
v If a null value is specified for baseTraceFileName, a connection is traced
to a file named traceFile_global_n.
n is the nth JDBC driver connection.
v If a non-null value is specified for baseTraceFileName, a connection is
traced to a file named baseTraceFileName_global_n.
baseTraceFileName is the value of the baseTraceFileName parameter.
n is the nth JDBC driver connection.
baseTraceFileName
Specifies the stem for the names of the files into which global trace
information is written. The combination of baseTraceFileName and
traceDirectory determines the full path name for the global trace log files.
traceFileName
Specifies the file into which global trace information is written. This setting
overrides the settings of the traceFile and logWriter properties for a
DataSource or DriverManager connection.
When the form of setLogWriter with the traceFileName parameter is used,
only one log file is written.
traceFileName can include a directory path.
logWriter
Specifies a character output stream to which all global log records are
written.
This value overrides the logWriter property on a DataSource or
DriverManager connection.
traceLevel
Specifies what to trace.
You can specify one or more of the following traces with the traceLevel
parameter:
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_NONE (X'00')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_CONNECTION_CALLS (X'01')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_STATEMENT_CALLS (X'02')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_RESULT_SET_CALLS (X'04')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_DRIVER_CONFIGURATION (X'10')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_CONNECTS (X'20')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_DRDA_FLOWS (X'40')
422
Application Programming Guide and Reference for Java
v
v
v
v
v
v
v
v
v
v
v
v
com.ibm.db2.jcc.DB2BaseDataSource.TRACE_RESULT_SET_META_DATA (X'80')
com.ibm.db2.jcc.DB2BaseDataSource.TRACE_PARAMETER_META_DATA (X'100')
com.ibm.db2.jcc.DB2BaseDataSource.TRACE_DIAGNOSTICS (X'200')
com.ibm.db2.jcc.DB2BaseDataSource.TRACE_SQLJ (X'400')
com.ibm.db2.jcc.DB2BaseDataSource.TRACE_XA_CALLS (IBM Data Server
Driver for JDBC and SQLJ type 2 connectivity for DB2 Database for
Linux, UNIX, and Windows only) (X'800')
com.ibm.db2.jcc.DB2BaseDataSource.TRACE_META_CALLS (X'2000')
com.ibm.db2.jcc.DB2BaseDataSource.TRACE_DATASOURCE_CALLS (X'4000')
com.ibm.db2.jcc.DB2BaseDataSource.TRACE_LARGE_OBJECT_CALLS (X'8000')
com.ibm.db2.jcc.DB2BaseDataSource.TRACE_T2ZOS (X'10000')
com.ibm.db2.jcc.DB2BaseDataSource.TRACE_SYSTEM_MONITOR (X'20000')
com.ibm.db2.jcc.DB2BaseDataSource.TRACE_TRACEPOINTS () (X'40000')
com.ibm.db2.jcc.DB2BaseDataSource.TRACE_ALL (X'FFFFFFFF')
To specify more than one trace, use one of these techniques:
v Use bitwise OR (|) operators with two or more trace values. For
example, to trace DRDA flows and connection calls, specify this value
for traceLevel:
TRACE_DRDA_FLOWS|TRACE_CONNECTION_CALLS
v Use a bitwise complement (tilde (~)) operator with a trace value to
specify all except a certain trace. For example, to trace everything except
DRDA flows, specify this value for traceLevel:
~TRACE_DRDA_FLOWS
fileAppend
Specifies whether to append to or overwrite the file that is specified by the
traceFile parameter. true means that the existing file is not overwritten.
unsetLogWriter
Format:
public abstract void unsetLogWriter()
throws java.sql.SQLException
Disables the global log writer override for future connections.
suspendTrace
Format:
public void suspendTrace()
throws java.sql.SQLException
Suspends all global, Connection-level, or DataSource-level traces for current
and future connections. suspendTrace can be called when the global log writer
is enabled or disabled.
resumeTrace
Format:
public void resumeTrace()
throws java.sql.SQLException
Resumes all global, Connection-level, or DataSource-level traces for current and
future connections. resumeTrace can be called when the global log writer is
enabled or disabled. If the global log writer is disabled, resumeTrace resumes
Connection-level or DataSource-level traces. If the global log writer is enabled,
resumeTrace resumes the global trace.
getLogWriter
Format:
Chapter 7. JDBC and SQLJ reference information
423
public abstract java.io.PrintWriter getLogWriter()
throws java.sql.SQLException
Returns the PrintWriter for the global log writer, if it is set. Otherwise,
getLogWriter returns null.
getTraceFile
Format:
public abstract String getTraceFile()
throws java.sql.SQLException
Returns the name of the destination file for the global log writer, if it is set.
Otherwise, getTraceFile returns null.
getTraceDirectory
Format:
public abstract String getTraceDirectory()
throws java.sql.SQLException
Returns the name of the destination directory for global log writer files, if it is
set. Otherwise, getTraceDirectory returns null.
getTraceLevel
Format:
public abstract int getTraceLevel()
throws java.sql.SQLException
Returns the trace level for the global trace, if it is set. Otherwise,
getTraceLevel returns -1 (TRACE_ALL).
getTraceFileAppend
Format:
public abstract boolean getTraceFileAppend()
throws java.sql.SQLException
Returns true if the global trace records are appended to the trace file.
Otherwise, getTraceFileAppend returns false.
Related reference
“Properties for the IBM Data Server Driver for JDBC and SQLJ” on page 221
DB2TraceManagerMXBean interface
The com.ibm.db2.jcc.mx.DB2TraceManagerMXBean interface is the means by which
an application makes DB2TraceManager available as an MXBean for the remote trace
controller.
DB2TraceManagerMXBean methods
setTraceFile
Format:
public void setTraceFile(String traceFile,
boolean fileAppend, int traceLevel)
throws java.sql.SQLException
Specifies the name of the file into which the remote trace manager writes trace
information, and the type of information that is to be traced.
Parameter descriptions:
424
Application Programming Guide and Reference for Java
traceFileName
Specifies the file into which global trace information is written. This setting
overrides the settings of the traceFile and logWriter properties for a
DataSource or DriverManager connection.
When the form of setLogWriter with the traceFileName parameter is used,
only one log file is written.
traceFileName can include a directory path.
fileAppend
Specifies whether to append to or overwrite the file that is specified by the
traceFile parameter. true means that the existing file is not overwritten.
traceLevel
Specifies what to trace.
You can specify one or more of the following traces with the traceLevel
parameter:
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_NONE (X'00')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_CONNECTION_CALLS (X'01')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_STATEMENT_CALLS (X'02')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_RESULT_SET_CALLS (X'04')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_DRIVER_CONFIGURATION (X'10')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_CONNECTS (X'20')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_DRDA_FLOWS (X'40')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_RESULT_SET_META_DATA (X'80')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_PARAMETER_META_DATA (X'100')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_DIAGNOSTICS (X'200')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_SQLJ (X'400')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_META_CALLS (X'2000')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_DATASOURCE_CALLS (X'4000')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_LARGE_OBJECT_CALLS (X'8000')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_T2ZOS (X'10000')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_SYSTEM_MONITOR (X'20000')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_TRACEPOINTS () (X'40000')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_ALL (X'FFFFFFFF')
To specify more than one trace, use one of these techniques:
v Use bitwise OR (|) operators with two or more trace values. For
example, to trace DRDA flows and connection calls, specify this value
for traceLevel:
TRACE_DRDA_FLOWS|TRACE_CONNECTION_CALLS
v Use a bitwise complement (tilde (~)) operator with a trace value to
specify all except a certain trace. For example, to trace everything except
DRDA flows, specify this value for traceLevel:
~TRACE_DRDA_FLOWS
getTraceFile
Format:
public void getTraceFile()
throws java.sql.SQLException
Returns the name of the destination file for the remote trace controller, if it is
set. Otherwise, getTraceFile returns null.
setTraceDirectory
Format:
Chapter 7. JDBC and SQLJ reference information
425
public void setTraceDirectory(String traceDirectory,
String baseTraceFileName,
int traceLevel) throws java.sql.SQLException
Specifies the name of the directory into which the remote trace controller
writes trace information, and the type of information that is to be traced.
Parameter descriptions:
traceDirectory
Specifies a directory into which trace information is written. This setting
overrides the settings of the traceDirectory and logWriter properties for a
DataSource or DriverManager connection.
Each JDBC driver connection is traced to a different file in the specified
directory. The naming convention for the files in that directory depends on
whether a non-null value is specified for baseTraceFileName:
v If a null value is specified for baseTraceFileName, a connection is traced
to a file named traceFile_global_n.
n is the nth JDBC driver connection.
v If a non-null value is specified for baseTraceFileName, a connection is
traced to a file named baseTraceFileName_global_n.
baseTraceFileName is the value of the baseTraceFileName parameter.
n is the nth JDBC driver connection.
baseTraceFileName
Specifies the stem for the names of the files into which global trace
information is written. The combination of baseTraceFileName and
traceDirectory determines the full path name for the global trace log files.
traceLevel
Specifies what to trace.
You can specify one or more of the following traces with the traceLevel
parameter:
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_NONE (X'00')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_CONNECTION_CALLS (X'01')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_STATEMENT_CALLS (X'02')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_RESULT_SET_CALLS (X'04')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_DRIVER_CONFIGURATION (X'10')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_CONNECTS (X'20')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_DRDA_FLOWS (X'40')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_RESULT_SET_META_DATA (X'80')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_PARAMETER_META_DATA (X'100')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_DIAGNOSTICS (X'200')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_SQLJ (X'400')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_META_CALLS (X'2000')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_DATASOURCE_CALLS (X'4000')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_LARGE_OBJECT_CALLS (X'8000')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_T2ZOS (X'10000')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_SYSTEM_MONITOR (X'20000')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_TRACEPOINTS () (X'40000')
v com.ibm.db2.jcc.DB2BaseDataSource.TRACE_ALL (X'FFFFFFFF')
To specify more than one trace, use one of these techniques:
v Use bitwise OR (|) operators with two or more trace values. For
example, to trace DRDA flows and connection calls, specify this value
for traceLevel:
426
Application Programming Guide and Reference for Java
TRACE_DRDA_FLOWS|TRACE_CONNECTION_CALLS
v Use a bitwise complement (tilde (~)) operator with a trace value to
specify all except a certain trace. For example, to trace everything except
DRDA flows, specify this value for traceLevel:
~TRACE_DRDA_FLOWS
getTraceFileAppend
Format:
public abstract boolean getTraceFileAppend()
throws java.sql.SQLException
Returns true if trace records that are generated by the trace controller are
appended to the trace file. Otherwise, getTraceFileAppend returns false.
getTraceDirectory
Format:
public void getTraceDirectory()
throws java.sql.SQLException
Returns the name of the destination directory for trace records that are
generated by the trace controller, if it is set. Otherwise, getTraceDirectory
returns null.
getTraceLevel
Format:
public void getTraceLevel()
throws java.sql.SQLException
Returns the trace level for the trace records that are generated by the trace
controller, if it is set. Otherwise, getTraceLevel returns -1 (TRACE_ALL).
unsetLogWriter
Format:
public abstract void unsetLogWriter()
throws java.sql.SQLException
Disables the global log writer override for future connections.
suspendTrace
Format:
public void suspendTrace()
throws java.sql.SQLException
Suspends all global, Connection-level, or DataSource-level traces for current
and future connections. suspendTrace can be called when the global log writer
is enabled or disabled.
resumeTrace
Format:
public void resumeTrace()
throws java.sql.SQLException
Resumes all global, Connection-level, or DataSource-level traces for current and
future connections. resumeTrace can be called when the global log writer is
enabled or disabled. If the global log writer is disabled, resumeTrace resumes
Connection-level or DataSource-level traces. If the global log writer is enabled,
resumeTrace resumes the global trace.
Chapter 7. JDBC and SQLJ reference information
427
DB2Types class
The com.ibm.db2.jcc.DB2Types class provides fields that define IBM Data Server
Driver for JDBC and SQLJ-only data types.
DB2Types fields
The following constants define types codes only for the IBM Data Server Driver for
JDBC and SQLJ.
v public final static int BLOB_FILE = -100002
v public final static int CLOB_FILE = -100003
v public final static int CURSOR = -100008
v public final static int DECFLOAT = -100001
v public final static int XML_AS_BLOB_FILE = -100004
v public final static int XML_AS_CLOB_FILE = -100005
v public final static int TIMESTAMPTZ =-100010
DB2XADataSource class
DB2XADataSource is a factory for XADataSource objects. An object that implements
this interface is registered with a naming service that is based on the Java Naming
and Directory Interface (JNDI).
The com.ibm.db2.jcc.DB2XADataSource class extends the
com.ibm.db2.jcc.DB2BaseDataSource class, and implements the
javax.sql.XADataSource, java.io.Serializable, and javax.naming.Referenceable
interfaces.
DB2XADataSource methods
getDB2TrustedXAConnection
Formats:
public Object[] getDB2TrustedXAConnection(String user,
String password,
java.util.Properties properties)
throws java.sql.SQLException
public Object[] getDB2TrustedXAConnection(
java.util.Properties properties)
throws java.sql.SQLException
public Object[] getDB2TrustedXAConnection(
org.ietf.jgss.GSSCredential gssCredential,
java.util.Properties properties)
throws java.sql.SQLException
An application server using a system authorization ID uses this method to
establish a trusted connection.
Trusted connections are supported for:
v IBM Data Server Driver for JDBC and SQLJ type 4 connectivity to:
– DB2 Database for Linux, UNIX, and Windows Version 9.5 or later
– DB2 for z/OS Version 9.1 or later
– IBM Informix Version 11.70 or later
v IBM Data Server Driver for JDBC and SQLJ type 2 connectivity on DB2 for
z/OS Version 9.1 or later
The following elements are returned in Object[]:
v The first element is a DB2TrustedXAConnection instance.
428
Application Programming Guide and Reference for Java
v The second element is a unique cookie for the generated XA connection
instance.
The first form getDB2TrustedXAConnection provides a user ID and password.
The second form of getDB2TrustedXAConnection uses the user ID and password
of the DB2XADataSource object. The third form of getDB2TrustedXAConnection is
for connections that use Kerberos security.
Parameter descriptions:
user
The authorization ID that is used to establish the trusted connection.
password
The password for the authorization ID that is used to establish the trusted
connection.
gssCredential
If the data source uses Kerberos security, specifies a delegated credential
that is passed from another principal.
properties
Properties for the connection.
getDB2TrustedPooledConnection
Format:
public Object[] getDB2TrustedPooledConnection(java.util.Properties properties)
throws java.sql.SQLException
An application server using a system authorization ID uses this method to
establish a trusted connection, using the user ID and password for the
DB2XADataSource object.
Trusted connections are supported for:
v IBM Data Server Driver for JDBC and SQLJ type 4 connectivity to:
– DB2 Database for Linux, UNIX, and Windows Version 9.5 or later
– DB2 for z/OS Version 9.1 or later
– IBM Informix Version 11.70 or later
v IBM Data Server Driver for JDBC and SQLJ type 2 connectivity on DB2 for
z/OS Version 9.1 or later
The following elements are returned in Object[]:
v The first element is a trusted DB2TrustedPooledConnection instance.
v The second element is a unique cookie for the generated pooled connection
instance.
Parameter descriptions:
properties
Properties for the connection.
getDB2XAConnection
Formats:
public DB2XAConnection getDB2XAConnection(String user,
String password,
java.util.Properties properties)
throws java.sql.SQLException
public DB2XAConnection getDB2XAConnection(
org.ietf.jgss.GSSCredential gssCredential,
java.util.Properties properties)
throws java.sql.SQLException
Chapter 7. JDBC and SQLJ reference information
429
Establishes the initial untrusted connection in a heterogeneous pooling
environment.
The first form getDB2PooledConnection provides a user ID and password. The
second form of getDB2XAConnection is for connections that use Kerberos
security.
Parameter descriptions:
user
The authorization ID that is used to establish the connection.
password
The password for the authorization ID that is used to establish the
connection.
gssCredential
If the data source uses Kerberos security, specifies a delegated credential
that is passed from another principal.
properties
Properties for the connection.
Related concepts
“Example of a distributed transaction that uses JTA methods” on page 560
Related tasks
“Creating and deploying DataSource objects” on page 20
DB2Xml interface
The com.ibm.db2.jcc.DB2Xml interface is used for declaring Java objects for use
with the DB2 XML data type.
DB2Xml methods
The following method is defined only for the IBM Data Server Driver for JDBC
and SQLJ.
closeDB2Xml
Format:
public void closeDB2Xml()
throws SQLException
Releases the resources that are associated with a com.ibm.jcc.DB2Xml object.
getDB2AsciiStream
Format:
public java.io.InputStream getDB2AsciiStream()
throws SQLExceptionn
Retrieves data from a DB2Xml object, and converts the data to US-ASCII
encoding.
getDB2BinaryStream
Format:
public java.io.InputStream getDB2BinaryStream()
throws SQLException
Retrieves data from a DB2Xml object as a binary stream. The character encoding
of the bytes in the binary stream is defined in the XML 1.0 specification.
430
Application Programming Guide and Reference for Java
getDB2Bytes
Format:
public byte[] getDB2Bytes()
throws SQLExceptionn
Retrieves data from a DB2Xml object as a byte array. The character encoding of
the bytes is defined in the XML 1.0 specification.
getDB2CharacterStream
Format:
public java.io.Reader getDB2CharacterStream()
throws SQLExceptionn
Retrieves data from a DB2Xml object as a java.io.Reader object.
getDB2String
Format:
public String getDB2String()
throws SQLExceptionn
Retrieves data from a DB2Xml object as a String value.
getDB2XmlAsciiStream
Format:
public InputStream getDB2XmlAsciiStream()
throws SQLExceptionn
Retrieves data from a DB2Xml object, converts the data to US-ASCII encoding,
and imbeds an XML declaration with an encoding specification for US-ASCII
in the returned data.
getDB2XmlBinaryStream
Format:
public java.io.InputStream getDB2XmlBinaryStream(String targetEncoding)
throws SQLExceptionn
Retrieves data from a DB2Xml object as a binary stream, converts the data to
targetEncoding, and imbeds an XML declaration with an encoding specification
for targetEncoding in the returned data.
Parameter:
targetEncoding
A valid encoding name that is listed in the IANA Charset Registry. The
encoding names that are supported by the DB2 server are listed in
"Mappings of CCSIDs to encoding names for serialized XML output data".
getDB2XmlBytes
Format:
public byte[] getDB2XmlBytes(String targetEncoding)
throws SQLExceptionn
Retrieves data from a DB2Xml object as a byte array, converts the data to
targetEncoding, and imbeds an XML declaration with an encoding specification
for targetEncoding in the returned data.
Parameter:
targetEncoding
A valid encoding name that is listed in the IANA Charset Registry. The
Chapter 7. JDBC and SQLJ reference information
431
encoding names that are supported by the DB2 server are listed in
"Mappings of CCSIDs to encoding names for serialized XML output data".
getDB2XmlCharacterStream
Format:
public java.io.Reader getDB2XmlCharacterStream()
throws SQLExceptionn
Retrieves data from a DB2Xml object as a java.io.Reader object, converts the
data to ISO-10646-UCS-2 encoding, and imbeds an XML declaration with an
encoding specification for ISO-10646-UCS-2 in the returned data.
getDB2XmlString
Format:
public String getDB2XmlString()
throws SQLExceptionn
Retrieves data from a DB2Xml object as a String object, converts the data to
ISO-10646-UCS-2 encoding, and imbeds an XML declaration with an encoding
specification for ISO-10646-UCS-2 in the returned data.
isDB2XmlClosed
Format:
public boolean isDB2XmlClosed()
throws SQLException
Indicates whether a com.ibm.jcc.DB2Xml object has been closed.
Related concepts
“XML column updates in SQLJ applications” on page 161
“XML column updates in JDBC applications” on page 85
“XML data retrieval in JDBC applications” on page 87
“XML data retrieval in SQLJ applications” on page 163
DB2XmlAsBlobFileReference class
The com.ibm.db2.jcc.DB2XmlAsBlobFileReference class is subclass of
DB2FileReference that is used for creating XML AS BLOB file reference variable
objects. This class applies only to IBM Data Server Driver for JDBC and SQLJ type
2 connectivity to DB2 for z/OS Version 9 or later.
DB2XmlAsBlobFileReference constructor
The following constructor is defined only for the IBM Data Server Driver for JDBC
and SQLJ.
DB2XmlAsBlobFileReference
Format:
public DB2XmlAsBlobFileReference(String fileName)
throws java.sql.SQLException
Constructs a DB2XmlAsBlobFileReference object for an XML AS BLOB file
reference variable.
Parameter descriptions:
fileName
The name of the file for the file reference variable. The name must specify
the absolute path name for an existing HFS file.
432
Application Programming Guide and Reference for Java
DB2XmlAsClobFileReference class
The com.ibm.db2.jcc.DB2XmlAsClobFileReference class is subclass of
DB2FileReference that is used for creating XML AS CLOB file reference variable
objects. This class applies only to IBM Data Server Driver for JDBC and SQLJ type
2 connectivity to DB2 for z/OS Version 9 or later.
DB2XmlAsClobFileReference constructor
The following constructor is defined only for the IBM Data Server Driver for JDBC
and SQLJ.
DB2XmlAsClobFileReference
Format:
public DB2XmlAsClobFileReference(String fileName,
int fileCcsid)
throws java.sql.SQLException
public DB2XmlAsClobFileReference(String fileName,
String fileEncoding)
throws java.sql.SQLException
Constructs a DB2XmlAsClobFileReference object for an XML AS CLOB file
reference variable.
Parameter descriptions:
fileName
The name of the file for the file reference variable. The name must specify
the absolute path name for an existing HFS file.
fileCcsid
The CCSID of the data in the file for the file reference variable.
fileEncoding
The encoding scheme of the data in the file for the file reference variable.
DBTimestamp class
The com.ibm.db2.jcc.DBTimestamp class can be used to create timestamp objects
with a precision of up to picoseconds and time zone information. This class is
primarily for support of the SQL TIMESTAMP WITH TIME ZONE data type,
which is supported only by DB2 for z/OS.
The com.ibm.db2.jcc.DBTimestamp class is a subclass of the java.sql.Timestamp
class. Therefore, a com.ibm.db2.jcc.DBTimestamp object can be used with any
methods that normally operate on a java.sql.Timestamp object, or take a
java.sql.Timestamp object as an argument.
The IBM Data Server Driver for JDBC and SQLJ returns a DBTimestamp object for
all JDBC methods that return timestamp information, such as
ResultSet.getTimestamp or CallableStatement.getTimestamp.
DBTimestamp constructor
The following constructor is defined only for the IBM Data Server Driver for JDBC
and SQLJ.
DBTimestamp
Formats:
Chapter 7. JDBC and SQLJ reference information
433
public DBTimestamp(long time,
java.util.Calendar calendar)
throws java.sql.SQLException
public DBTimestamp(long time, )
throws java.sql.SQLException
public DBTimestamp(java.sql.Timestamp timestamp)
throws java.sql.SQLException
public DBTimestamp(java.sql.Timestamp timestamp,
java.util.Calendar calendar)
throws java.sql.SQLException
Constructs a DBTimestamp object.
Parameter descriptions:
time
The number of milliseconds since January 1, 1970.
timestamp
A Timestamp value with a precision of up to picoseconds.
calendar
The Calendar value that provides the time zone.
DBTimestamp methods
getPicos
Formats:
public long getPicos()
Returns the fractional seconds component of a DBTimestamp value.
getTimeZone
Formats:
public java.util.TimeZone getTimeZone()
Returns the time zone component of a DBTimestamp value.
setPicos
Format:
public void setPicos(long p)
throws SQLException
Assigns the given value to the fractional seconds component of a DBTimestamp
value.
Parameter descriptions:
p
A value between 0 and 999999999999, inclusive, which is the fractional
sections component of a DBTimestamp value.
setTimeZone
Format:
public void setTimeZone(java.util.TimeZone timeZone)
throws SQLException
Assigns the given value to the time zone component of a DBTimestamp value.
Parameter descriptions:
timeZone
The time zone component of a DBTimestamp value.
434
Application Programming Guide and Reference for Java
valueOfDBString
Format:
public static DBTimestamp valueOfDBString(String s)
throws java.lang.IllegalArgumentException
Constructs a DBTimestamp value from the string representation of a timestamp
value.
Parameter descriptions:
s
The string representation of a timestamp value. The value must be in one
of the following formats:
yyyy-mm-dd.hh.mm.ss[.ffffffffffff]-th:tm
yyyy-mm-dd hh:mm:ss[.ffffffffffff]-th:tm
yyyy-mm-dd.hh.mm.ss[.ffffffffffff]
yyyy-mm-dd hh:mm:ss[.ffffffffffff]
v
v
v
v
v
v
v
v
v
yyyy is a year.
mm is a month.
dd is a day.
hh is hours.
mm is minutes.
ss is seconds.
[.ffffffffffff] is one to 12 optional fractions of seconds.
th is the hours component of a time zone.
tm is the minutes component of a time zone.
toDBString
Format:
public String toDBString(boolean includeTimeZone)
Returns the string representation of a DBTimestamp object.
The returned value has one of the following formats:
yyyy-mm-dd.hh.mm.ss[.ffffffffffff]-th:tm
yyyy-mm-dd.hh.mm.ss[.ffffffffffff]
Parameter description:
includeTimeZone
Specifies whether to include the time zone (-th:tm) in the returned string.
JDBC differences between versions of the IBM Data Server Driver for
JDBC and SQLJ
Before you can upgrade your JDBC applications from older to newer versions of
the IBM Data Server Driver for JDBC and SQLJ, you need to understand the
differences between those drivers.
Supported methods
For a list of methods that the IBM Data Server Driver for JDBC and SQLJ supports,
see "Driver support for JDBC APIs".
Chapter 7. JDBC and SQLJ reference information
435
Use of progressive streaming by the JDBC drivers
For IBM Data Server Driver for JDBC and SQLJ, Version 3.50 and later, progressive
streaming, which is also known as dynamic data format, behavior is the default for
LOB retrieval, for connections to DB2 Database for Linux, UNIX, and Windows
Version 9.5 and later.
Progressive streaming is supported in the IBM Data Server Driver for JDBC and
SQLJ Version 3.1 and later, but for IBM Data Server Driver for JDBC and SQLJ
version 3.2 and later, progressive streaming behavior is the default for LOB and
XML retrieval, for connections to DB2 for z/OS Version 9.1 and later.
Previous versions of the IBM Data Server Driver for JDBC and SQLJ did not
support progressive streaming.
Important: With progressive streaming, when you retrieve a LOB or XML value
from a ResultSet into an application variable, you can manipulate the contents of
that application variable until you move the cursor or close the cursor on the
ResultSet. After that, the contents of the application variable are no longer
available to you. If you perform any actions on the LOB in the application variable,
you receive an SQLException. For example, suppose that progressive streaming is
enabled, and you execute statements like this:
...
ResultSet rs = stmt.executeQuery("SELECT CLOBCOL FROM MY_TABLE");
rs.next();
// Retrieve the first row of the ResultSet
Clob clobFromRow1 = rs.getClob(1);
// Put the CLOB from the first column of
// the first row in an application variable
String substr1Clob = clobFromRow1.getSubString(1,50);
// Retrieve the first 50 bytes of the CLOB
rs.next();
// Move the cursor to the next row.
// clobFromRow1 is no longer available.
// String substr2Clob = clobFromRow1.getSubString(51,100);
// This statement would yield an SQLException
Clob clobFromRow2 = rs.getClob(1);
// Put the CLOB from the first column of
// the second row in an application variable
rs.close();
// Close the ResultSet.
// clobFromRow2 is also no longer available.
After you execute rs.next() to position the cursor at the second row of the
ResultSet, the CLOB value in clobFromRow1 is no longer available to you.
Similarly, after you execute rs.close() to close the ResultSet, the values in
clobFromRow1 and clobFromRow2 are no longer available.
To avoid errors that are due to this changed behavior, you need to take one of the
following actions:
v Modify your applications.
Applications that retrieve LOB data into application variables can manipulate
the data in those application variables only until the cursors that were used to
retrieve the data are moved or closed.
v Disable progressive streaming by setting the progressiveStreaming property to
DB2BaseDataSource.NO (2).
436
Application Programming Guide and Reference for Java
ResultSetMetaData values for IBM Data Server Driver for JDBC
and SQLJ version 4.0 and later
For the IBM Data Server Driver for JDBC and SQLJ version 4.0 and later, the
default behavior of ResultSetMetaData.getColumnName and
ResultSetMetaData.getColumnLabel differs from the default behavior for earlier
JDBC drivers.
If you need to use IBM Data Server Driver for JDBC and SQLJ version 4.0 or later,
but your applications need to return the ResultSetMetaData.getColumnName and
ResultSetMetaData.getColumnLabel values that were returned with older JDBC
drivers, you can set the useJDBC4ColumnNameAndLabelSemantics Connection
and DataSource property to DB2BaseDataSource.NO (2).
Batch updates with automatically generated keys have different
results in different driver versions
With the IBM Data Server Driver for JDBC and SQLJ version 3.52 or later,
preparing an SQL statement for retrieval of automatically generated keys is
supported.
With the IBM Data Server Driver for JDBC and SQLJ version 3.50 or version 3.51,
preparing an SQL statement for retrieval of automatically generated keys and
using the PreparedStatement object for batch updates causes an SQLException.
Versions of the IBM Data Server Driver for JDBC and SQLJ before Version 3.50 do
not throw an SQLException when an application calls the addBatch or executeBatch
method on a PreparedStatement object that is prepared to return automatically
generated keys. However, the PreparedStatement object does not return
automatically generated keys.
Batch updates of data on DB2 for z/OS servers have different
results in different driver versions
After you successfully invoke an executeBatch statement, the IBM Data Server
Driver for JDBC and SQLJ returns an array. The purpose of the array is to indicate
the number of rows that are affected by each SQL statement that is executed in the
batch.
If the following conditions are true, the IBM Data Server Driver for JDBC and SQLJ
returns Statement.SUCCESS_NO_INFO (-2) in the array elements:
v The application is connected to a subsystem that is in DB2 for z/OS Version 8
new-function mode, or later.
v The application is using Version 3.1 or later of the IBM Data Server Driver for
JDBC and SQLJ.
v The IBM Data Server Driver for JDBC and SQLJ uses multi-row INSERT
operations to execute batch updates.
This occurs because with multi-row INSERT, the database server executes the
entire batch as a single operation, so it does not return results for individual SQL
statements.
If you are using an earlier version of the IBM Data Server Driver for JDBC and
SQLJ, or you are connected to a data source other than DB2 for z/OS Version 8 or
Chapter 7. JDBC and SQLJ reference information
437
later, the array elements contain the number of rows that are affected by each SQL
statement.
Batch updates and deletes of data on DB2 for z/OS servers have
different size limitations in different driver versions
Before IBM Data Server Driver for JDBC and SQLJ version 3.59 or 4.9, a
DisconnectException with error code -4499 was thrown for IBM Data Server
Driver for JDBC and SQLJ type 4 connectivity to DB2 for z/OS if the size of an
update or delete batch was greater than 32KB. Starting with version 3.59 or 4.9,
this restriction no longer exists, and the exception is no longer thrown.
Initial value of the CURRENT CLIENT_ACCTNG special register
For a JDBC or SQLJ application that runs under the IBM Data Server Driver for
JDBC and SQLJ version 2.6 or later, using type 4 connectivity, the initial value for
the DB2 for z/OS CURRENT CLIENT_ACCTNG special register is the
concatenation of the DB2 for z/OS version and the value of the clientWorkStation
property. For any other JDBC driver, version, and connectivity, the initial value is
not set.
Properties that control the use of multi-row FETCH
Before version 3.7 and version 3.51 of the IBM Data Server Driver for JDBC and
SQLJ, multi-row FETCH support was enabled and disabled through the
useRowsetCursor property, and was available only for scrollable cursors, and for
IBM Data Server Driver for JDBC and SQLJ type 4 connectivity to DB2 for z/OS.
Starting with version 3.7 and 3.51:
v For IBM Data Server Driver for JDBC and SQLJ type 2 connectivity on DB2 for
z/OS, the IBM Data Server Driver for JDBC and SQLJ uses only the
enableRowsetSupport property to determine whether to use multi-row FETCH
for scrollable or forward-only cursors.
v For IBM Data Server Driver for JDBC and SQLJ type 4 connectivity to DB2 for
z/OS or DB2 Database for Linux, UNIX, and Windows, or IBM Data Server
Driver for JDBC and SQLJ type 2 connectivity on DB2 Database for Linux,
UNIX, and Windows, the IBM Data Server Driver for JDBC and SQLJ uses the
enableRowsetSupport property to determine whether to use multi-row FETCH
for scrollable cursors, if enableRowsetSupport is set. If enableRowsetSupport is
not set, the driver uses the useRowsetCursor property to determine whether to
use multi-row FETCH.
JDBC 1 positioned updates and deletes and multi-row FETCH
Before version 3.7 and version 3.51 of the IBM Data Server Driver for JDBC and
SQLJ, multi-row FETCH from DB2 for z/OS tables was controlled by the
useRowsetCursor property. If an application contained JDBC 1 positioned update
or delete operations, and multi-row FETCH support was enabled, the IBM Data
Server Driver for JDBC and SQLJ permitted the update or delete operations, but
unexpected updates or deletes might occur.
Starting with version 3.7 and 3.51 of the IBM Data Server Driver for JDBC and
SQLJ, the enableRowsetSupport property enables or disables multi-row FETCH
from DB2 for z/OS tables or DB2 Database for Linux, UNIX, and Windows tables.
The enableRowsetSupport property overrides the useRowsetCursor property. If
multi-row FETCH is enabled through the enableRowsetSupport property, and an
438
Application Programming Guide and Reference for Java
application contains a JDBC 1 positioned update or delete operation, the IBM Data
Server Driver for JDBC and SQLJ throws an SQLException.
Valid forms of prepareStatement for retrieval of automatically
generated keys from a DB2 for z/OS view
Starting with version 3.57 or version 4.7 of the IBM Data Server Driver for JDBC
and SQLJ, if you are inserting data into a view on a DB2 for z/OS data server, and
you want to retrieve automatically generated keys, you need to use one of the
following methods to prepare the SQL statement that inserts rows into the view:
Connection.prepareStatement(sql-statement, String [] columnNames);
Connection.prepareStatement(sql-statement, int [] columnIndexes);
Statement.executeUpdate(sql-statement, String [] columnNames);
Statement.executeUpdate(sql-statement, int [] columnIndexes);
Data loss for TIMESTAMP(p) column updates using setString
If you use a setString call to pass an input value to a TIMESTAMP(p) column, it
is possible to send a value with a precision of greater than nine to the column.
Before version 3.59 or version 4.9 of the IBM Data Server Driver for JDBC and
SQLJ, data loss could occur if the sendDataAsIs property was set to false, and the
precision of the input value was greater than nine.
Starting with version 3.59 and version 4.9 of the IBM Data Server Driver for JDBC
and SQLJ, data loss does not occur if the TIMESTAMP(p) column is large enough
to accommodate the input value.
Related concepts
“Examples of ResultSetMetaData.getColumnName and
ResultSetMetaData.getColumnLabel values”
Examples of ResultSetMetaData.getColumnName and
ResultSetMetaData.getColumnLabel values
For the IBM Data Server Driver for JDBC and SQLJ version 4.0 and later, the
default behavior of ResultSetMetaData.getColumnName and
ResultSetMetaData.getColumnLabel differs from the default behavior for earlier
JDBC drivers. You can use the useJDBC4ColumnNameAndLabelSemantics property
to change this behavior.
The following examples show the values that are returned for IBM Data Server
Driver for JDBC and SQLJ Version 4.0, and for previous JDBC drivers, when the
useJDBC4ColumnNameAndLabelSemantics property is not set.
All queries use a table that is defined like this:
CREATE TABLE MYTABLE(INTCOL INT)
Example: The following query contains an AS CLAUSE, which defines a label for a
column in the result set:
SELECT MYCOL AS MYLABEL FROM MYTABLE
The following table lists the ResultSetMetaData.getColumnName and
ResultSetMetaData.getColumnName values that are returned for the query:
Chapter 7. JDBC and SQLJ reference information
439
Table 93. ResultSetMetaData.getColumnName and ResultSetMetaData.getColumnName before and after IBM Data
Server Driver for JDBC and SQLJ Version 4.0 for a query with an AS CLAUSE
Behavior before IBM Data Server Driver for
JDBC and SQLJ Version 4.0
Behavior for IBM Data Server Driver for
JDBC and SQLJ Version 4.0 and later
getColumnName
value
getColumnLabel
value
getColumnName
value
getColumnLabel
value
DB2 Database for
Linux, UNIX, and
Windows
MYLABEL
MYLABEL
MYCOL
MYLABEL
IBM Informix
MYLABEL
MYLABEL
MYCOL
MYLABEL
DB2 for z/OS Version MYLABEL
8 or later, and DB2
UDB for iSeries V5R3
and later
MYLABEL
MYCOL
MYLABEL
DB2 for z/OS Version MYLABEL
7, and DB2 UDB for
iSeries V5R2
MYLABEL
MYLABEL
MYLABEL
Target data source
Example: The following query contains no AS clause:
SELECT MYCOL FROM MYTABLE
The ResultSetMetaData.getColumnName and ResultSetMetaData.getColumnLabel
methods on the query return MYCOL, regardless of the target data source.
Example: On a DB2 for z/OS or DB2 for i data source, a LABEL ON statement is
used to define a label for a column:
LABEL ON COLUMN MYTABLE.MYCOL IS ’LABELONCOL’
The following query contains an AS CLAUSE, which defines a label for a column
in the ResultSet:
SELECT MYCOL AS MYLABEL FROM MYTABLE
The following table lists the ResultSetMetaData.getColumnName and
ResultSetMetaData.getColumnName values that are returned for the query.
Table 94. ResultSetMetaData.getColumnName and ResultSetMetaData.getColumnName before and after IBM Data
Server Driver for JDBC and SQLJ Version 4.0 for a table column with a LABEL ON statement in a query with an AS
CLAUSE
Behavior before IBM Data Server Driver for
JDBC and SQLJ Version 4.0
Behavior for IBM Data Server Driver for
JDBC and SQLJ Version 4.0 and later
getColumnName
value
getColumnLabel
value
getColumnName
value
getColumnLabel
value
DB2 for z/OS Version MYLABEL
8 or later, and DB2
UDB for iSeries V5R3
and later
LABELONCOL
MYCOL
MYLABEL
DB2 for z/OS Version MYLABEL
7, and DB2 UDB for
iSeries V5R2
LABELONCOL
MYCOL
LABELONCOL
Target data source
Example: On a DB2 for z/OS or DB2 for i data source, a LABEL ON statement is
used to define a label for a column:
440
Application Programming Guide and Reference for Java
LABEL ON COLUMN MYTABLE.MYCOL IS ’LABELONCOL’
The following query contains no AS CLAUSE:
SELECT MYCOL FROM MYTABLE
The following table lists the ResultSetMetaData.getColumnName and
ResultSetMetaData.getColumnName values that are returned for the query.
Table 95. ResultSetMetaData.getColumnName and ResultSetMetaData.getColumnName before and after IBM Data
Server Driver for JDBC and SQLJ Version 4.0 for a table column with a LABEL ON statement in a query with no AS
CLAUSE
Behavior before IBM Data Server Driver for
JDBC and SQLJ Version 4.0
Behavior for IBM Data Server Driver for
JDBC and SQLJ Version 4.0
getColumnName
value
getColumnLabel
value
getColumnName
value
getColumnLabel
value
DB2 for z/OS Version MYCOL
8 or later, and DB2
UDB for i5/OS V5R3
and later
LABELONCOL
MYCOL
MYCOL
DB2 for z/OS Version MYCOL
7, and DB2 UDB for
i5/OS V5R2
LABELONCOL
MYLABEL
LABELONCOL
Target data source
Error codes issued by the IBM Data Server Driver for JDBC and SQLJ
Error codes in the ranges +4200 to +4299, +4450 to +4499, -4200 to -4299, and -4450
to -4499 are reserved for the IBM Data Server Driver for JDBC and SQLJ.
When you call the SQLException.getMessage method after a IBM Data Server
Driver for JDBC and SQLJ error occurs, a string is returned that includes:
v Whether the connection is a type 2 or type 4 connection
v Diagnostic information for IBM Software Support
v The level of the driver
v An explanatory message
v The error code
v The SQLSTATE
For example:
[jcc][t4][20128][12071][3.50.54] Invalid queryBlockSize specified: 1,048,576,012.
Using default query block size of 32,767. ERRORCODE=0, SQLSTATE=
Currently, the IBM Data Server Driver for JDBC and SQLJ issues the following
error codes:
Chapter 7. JDBC and SQLJ reference information
441
Table 96. Error codes issued by the IBM Data Server Driver for JDBC and SQLJ
Error
Code
+4204
Message text and explanation
SQLSTATE
Errors were encountered and tolerated as specified by the
RETURN DATA UNTIL clause.
02506
Explanation: Tolerated errors include federated connection,
authentication, and authorization errors. This warning applies
only to connections to DB2 Database for Linux, UNIX, and
Windows servers. It is issued only when a cursor operation,
such as a ResultSet.next or ResultSet.previous call, returns
false.
+4222
text-from-getMessage
Explanation: A warning condition occurred during
connection to the data source.
User response: Call SQLException.getMessage to retrieve
specific information about the problem.
+4223
text-from-getMessage
Explanation: A warning condition occurred during
initialization.
User response: Call SQLException.getMessage to retrieve
specific information about the problem.
+4225
text-from-getMessage
Explanation: A warning condition occurred when data was
sent to a server or received from a server.
User response: Call SQLException.getMessage to retrieve
specific information about the problem.
+4226
text-from-getMessage
Explanation: A warning condition occurred during
customization or bind.
User response: Call SQLException.getMessage to retrieve
specific information about the problem.
+4228
text-from-getMessage
Explanation: An warning condition occurred that does not fit
in another category.
User response: Call SQLException.getMessage to retrieve
specific information about the problem.
+4450
Feature not supported: feature-name
+4460
text-from-getMessage
Explanation: The specified value is not a valid option.
User response: Call SQLException.getMessage to retrieve
specific information about the problem.
442
Application Programming Guide and Reference for Java
Table 96. Error codes issued by the IBM Data Server Driver for JDBC and SQLJ (continued)
Error
Code
Message text and explanation
+4461
text-from-getMessage
SQLSTATE
Explanation: The specified value is invalid or out of range.
User response: Call SQLException.getMessage to retrieve
specific information about the problem.
+4462
text-from-getMessage
Explanation: A required value is missing.
User response: Call SQLException.getMessage to retrieve
specific information about the problem.
+4470
text-from-getMessage
Explanation: The requested operation cannot be performed
because the target resource is closed.
User response: Call SQLException.getMessage to retrieve
specific information about the problem.
+4471
text-from-getMessage
Explanation: The requested operation cannot be performed
because the target resource is in use.
User response: Call SQLException.getMessage to retrieve
specific information about the problem.
+4472
text-from-getMessage
Explanation: The requested operation cannot be performed
because the target resource is because the target resource is
unavailable.
User response: Call SQLException.getMessage to retrieve
specific information about the problem.
+4474
text-from-getMessage
Explanation: The requested operation cannot be performed
because the target resource cannot be changed.
User response: Call SQLException.getMessage to retrieve
specific information about the problem.
-4200
Invalid operation: An invalid COMMIT or ROLLBACK has
been called in an XA environment during a Global
Transaction.
2D521
Explanation: An application that was in a global transaction
in an XA environment issued a commit or rollback. A commit
or rollback operation in a global transaction is invalid.
-4201
Invalid operation: setAutoCommit(true) is not allowed during 2D521
Global Transaction.
Explanation: An application that was in a global transaction
in an XA environment executed the setAutoCommit(true)
statement. Issuing setAutoCommit(true) in a global
transaction is invalid.
Chapter 7. JDBC and SQLJ reference information
443
Table 96. Error codes issued by the IBM Data Server Driver for JDBC and SQLJ (continued)
Error
Code
Message text and explanation
-4203
Error executing function. Server returned rc.
SQLSTATE
: An error occurred on an XA connection during execution of
an SQL statement.
For network optimization, the IBM Data Server Driver for
JDBC and SQLJ delays some XA flows until the next SQL
statement is executed. If an error occurs in a delayed XA
flow, that error is reported as part of the SQLException that is
thrown by the current SQL statement.
-4210
Timeout getting a transport object from pool.
57033
-4211
Timeout getting an object from pool.
57033
-4212
Sysplex member unavailable.
-4213
Timeout.
57033
-4214
text-from-getMessage
28000
Explanation: Authorization failed.
User response: Call SQLException.getMessage to retrieve
specific information about the problem.
-4220
text-from-getMessage
Explanation: An error occurred during character conversion.
User response: Call SQLException.getMessage to retrieve
specific information about the problem.
-4221
text-from-getMessage
Explanation: An error occurred during encryption or
decryption.
User response: Call SQLException.getMessage to retrieve
specific information about the problem.
-4222
text-from-getMessage
Explanation: An error occurred during connection to the data
source.
User response: Call SQLException.getMessage to retrieve
specific information about the problem.
-4223
text-from-getMessage
Explanation: An error occurred during initialization.
User response: Call SQLException.getMessage to retrieve
specific information about the problem.
-4224
text-from-getMessage
Explanation: An error occurred during resource cleanup.
User response: Call SQLException.getMessage to retrieve
specific information about the problem.
444
Application Programming Guide and Reference for Java
Table 96. Error codes issued by the IBM Data Server Driver for JDBC and SQLJ (continued)
Error
Code
Message text and explanation
-4225
text-from-getMessage
SQLSTATE
Explanation: An error occurred when data was sent to a
server or received from a server.