IBM DB2 Manual page 421

Table of Contents

Advertisement

Usage notes
Online checking is always recommended: It is highly recommended that you use
online checking when you customize your serialized profiles. Online checking
determines information about the data types and lengths of DB2 host variables,
and is especially important for the following items:
v Predicates with java.lang.String host variables and CHAR columns
Unlike character variables in other host languages, Java String host variables are
not declared with a length attribute. To optimize a query properly that contains
character host variables, DB2 needs the length of the host variables. For
example, suppose that a query has a predicate in which a String host variable is
compared to a CHAR column, and an index is defined on the CHAR column. If
DB2 cannot determine the length of the host variable, it might do a table space
scan instead of an index scan. Online checking avoids this problem by providing
the lengths of the corresponding character columns.
v Predicates with java.lang.String host variables and GRAPHIC columns
Without online checking, DB2 might issue a bind error (SQLCODE -134) when it
encounters a predicate in which a String host variable is compared to a
GRAPHIC column.
v Column names in the result table of an SQLJ SELECT statement at a remote
server:
Without online checking, the driver cannot determine the column names for the
result table of a remote SELECT.
Customizing multiple serialized profiles together: Multiple serialized profiles can
be customized together to create a single DB2 package. If you do this, and if you
specify -staticpostioned YES, any positioned UPDATE or DELETE statement that
references a cursor that is declared earlier in the package executes statically, even if
the UPDATE or DELETE statement is in a different source file from the cursor
declaration. If you want -staticpositioned YES behavior when your program
consists of multiple source files, you need to order the profiles in the
db2sqljcustomize command to cause cursor declarations to be ahead of positioned
UPDATE or DELETE statements in the package. To do that, list profiles that
contain SELECT statements that assign result tables to iterators before profiles that
contain the positioned UPDATE or DELETE statements that reference those
iterators.
Using a customized serialized profile at one data source that was customized at
another data source: You can run db2sqljcustomize to produce a customized
serialized profile for an SQLJ program at one data source, and then use that profile
at another data source. You do this by running db2sqljbind multiple times on
customized serialized profiles that you created by running db2sqljcustomize once.
When you run the programs at these data sources, the DB2 objects that the
programs access must be identical at every data source. For example, tables at all
data sources must have the same encoding schemes and the same columns with
the same data types.
Using the -collection parameter: db2sqljcustomize stores the DB2 collection name
in each customized serialized profile that it produces. When an SQLJ program is
executed, the driver uses the collection name that is stored in the customized
serialized profile to search for packages to execute. The name that is stored in the
customized serialized profile is determined by the value of the -collection
parameter. Only one collection ID can be stored in the serialized profile. However,
you can bind the same serialized profile into multiple package collections by
Chapter 7. JDBC and SQLJ reference information
405

Hide quick links:

Advertisement

Table of Contents
loading

Table of Contents