DB2 FOR LUW / DB2FORLUW / B10 - DB2

An unexpected SQL1188N might occur when the LOAD is from a
remote cursor and uses the MODIFIED BY ROWCHANGETIMESTAMPIGNORE
clause.

If the row change timestamp column is not last in the table's
DDL, the issue will occur when LOAD uses the MODIFIED BY
ROWCHANGETIMESTAMPIGNORE clause, but will not if the timestamp
column is last in the source table's DDL.

LOAD checks that the source table data type is compatible with
the target table column type.  If the target table column is a
row change timestamp column and MODIFIED BY
ROWCHANGETIMESTAMPIGNORE is used, source data is present but we
are not loading it into target column, and we can skip the
compatibility check.  This defect causes LOAD to (incorrectly)
not skip the source data column but still skips the target table
column, thus checking compatibility of incorrect column types,
and incorrectly returns SQL1188N error.

Here is an example of what could produce this error. In this
example, database TSTDB2_R is a remote database and TSTDB2 is a
local database. Both databases have a table named DB2ADMIN.TAB1
with the same definition:

        db2 connect to TSTDB2_R
        db2 "create table db2admin.tab1(ID INTEGER,
                TS_UPDATE TIMESTAMP NOT NULL GENERATED ALWAYS
FOR EACH ROW ON UPDATE AS ROW CHANGE TIMESTAMP,
                ID2 INTEGER NOT NULL GENERATED BY DEFAULT AS
IDENTITY ( START WITH +1 ))"

        db2 connect to TSTDB2
        db2 "create table db2admin.tab1(ID INTEGER,
                TS_UPDATE TIMESTAMP NOT NULL GENERATED ALWAYS
FOR EACH ROW ON UPDATE AS ROW CHANGE TIMESTAMP,
                ID2 INTEGER NOT NULL GENERATED BY DEFAULT AS
IDENTITY ( START WITH +1 ))"

        db2 "DECLARE RDD CURSOR database TSTDB2_R user
my_user_id using my_user_password FOR SELECT ID, TS_UPDATE, ID2
FROM DB2ADMIN.TAB1"
        db2 "LOAD FROM RDD OF CURSOR modified by
rowchangetimestampignore REPLACE INTO DB2ADMIN.TAB1
NONRECOVERABLE"

In this example, LOAD should check for type compatibility for
column 1, skip column 2, and check column 3.  But because of the
defect, LOAD checks for compatibility for column 1, then
incorrectly checks for source column 2 (timestamp) against
target column 3 (integer), and incorrectly returns SQL1188N
because we cannot load a timestamp into an integer column.

****************************************************************
* USERS AFFECTED:                                              *
* ALL                                                          *
****************************************************************
* PROBLEM DESCRIPTION:                                         *
* See Error Description                                        *
****************************************************************
* RECOMMENDATION:                                              *
* Upgrade to Db2 11.1 Mod 4 Fixpack 5 or higher                *
****************************************************************

Explicitly specify the source columns (in the DECLARE CURSOR
statement) and the target columns (in the LOAD command),
omitting the row change timestamp column(s).

not known / see Local fix

Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :

18.10.2018
16.01.2020
16.01.2020