The distributed join installation feature and associated federated system functionality, as documented, are not currently supported with DB2 UDB Version 6.1.
All SQLJ stored procedures must be run in FENCED mode.
SQLJ and JDBC result set interoperability is not supported. The SQLJ option "-default-customizer" is not supported. To customize SQLJ profiles, use the "db2profc" command (see the Command Reference).
SQLJ applications that use iterators for positioned updates and deletes cannot use a FOR UPDATE OF clause in the SQLJ statement that assigns the iterator. The sample SQLJ program "Openftch.sqlj", as documented in the book, erroneously uses the FOR UPDATE OF clause. Please refer to the "Openftch.sqlj" program available in the Java samples directory of the DB2 Software Developer's Kit for a correct example of using positioned update iterators in an SQLJ application.
To explicitly identify the columns that are updatable for an iterator, use the updateColumns keyword in the iterator declaration clause. For example, to identify a column named JOB updatable for an iterator called OpF_Curs, use the following declaration clause:
#sql public iterator OpF_Curs implements ForUpdate with (updateColumns = "JOB") (String, short);
JDBC Version 2.0 support (limited to Windows NT) is currently available only to JDBC applications and applets, not to Java stored procedures or user-defined functions, or to SQLJ applications or applets.
The DB2 SDK provides developers with two Visual Studio Version 6.0 development extensions. These extensions plug into the Visual C++ IDE to enable the launching of various DB2 GUI tools, and facilitate the development of embedded SQL applications and embedded SQL stored procedures using Microsoft Visual Studio Version 6.0. These two extensions are available from:
www.software.ibm.com\data\db2\udb\ide
To enable the extensions, do the following:
db2vscmd register
It is assumed that the following standard Visual Studio Version 6.0 components are installed:
All of these components are installed as part of the Microsoft Visual Studio Version 6.0 product.
More information about the DB2 Visual Studio extensions can be found at:
www.software.ibm.com\data\db2
and
www.software.ibm.com\data\db2\udb\ide
In Chapter 5, "Stored Procedures", replace the text of the subsection entitled "SQL Statements in Stored Procedures" with the following:
Stored procedures can contain SQL statements. When you issue the CREATE PROCEDURE
statement, you should specify the type of SQL statements the stored procedure executes,
if any. If you do not specify a value when you register the stored procedure,
the database manager uses the restrictive default value MODIFIES SQL DATA. To indicate
the type of SQL used in the stored procedure, you can use one of the following four
options:
NO SQL
Indicates that the stored procedure cannot execute any SQL statements (SQLSTATE 38001).
CONTAINS SQL
Indicates that SQL statements that neither read nor modify SQL data can be executed
by the stored procedure (SQLSTATE 38004). Statements that are not supported
in any stored procedure return a different error (SQLSTATE 38003).
READS SQL DATA
Indicates that some SQL statements that do not modify SQL data can be included
in the stored procedure (SQLSTATE 38002). Statements that are not supported
in any stored procedure return a different error (SQLSTATE 38003).
MODIFIES SQL DATA
Indicates that the stored procedure can execute any SQL statement except statements
that are not supported in stored procedures (SQLSTATE 38003).
For more information about the CREATE PROCEDURE statement, refer to the SQL Reference.
The Java code for the sample stored procedure Outsrv.sqlj, found in "Chapter 6. Writing Stored Procedures", has changed since the book was published. Please refer to the sample Outsrv.sqlj in the Java samples directory for an updated version of the stored procedure.
The Distributed Debugger is part of IBM VisualAge for Java Professional Edition. The Debugger daemon on the client side is started with:
idebug -qdaemon -quiport=<port-number>
The environment variable for the location of source code on the client is DER_DBG_PATH. Please refer to the IBM Distributed Debugger online help for further information.
The sql_function_signature and sql_procedure_signature, described in the SQLJ Routines specification, are not supported for the CREATE PROCEDURE and CREATE FUNCTION statements. Java arrays are not supported as parameters to this type of Java routine, thus the SQL types of BINARY, VARBINARY, and LONGVARBINARY cannot be passed to PARAMETER STYLE JAVA routines.
The sqlj.install_jar and related procedures do not issue a COMMIT after they complete, because this would also commit any other outstanding changes. The calling application must issue a COMMIT when the unit of work is complete. If these procedures are issued as CLP commands, they respect the setting of the CLP autocommit flag. There is no online help available for the CALL command issued from the command line processor. For more information, refer to the Command Reference.
The sqlj.install_jar and sqlj.replace_jar procedures place jar files into the database system for use as Java routines. The Java run time environment on the DB2 server will open all the jar files at initialization time, and keep these files locked as long as it is operational. This is done for performance reasons. The impact is that a replace or remove jar action will fail if the physical jar file is locked. Issuing a "db2 force applications all" command, followed by db2stop, then db2start prior to a replace or remove jar request will ensure that no fenced or unfenced Java routines are executing.