Fixes are available
APAR status
Closed as program error.
Error description
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.
Local fix
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).
Problem summary
**************************************************************** * USERS AFFECTED: * * ALL * **************************************************************** * PROBLEM DESCRIPTION: * * See Error Description * **************************************************************** * RECOMMENDATION: * * Upgrade to Db2 11.1 Mod 4 Fixpack 5 or higher * ****************************************************************
Problem conclusion
First fixed in Db2 11.1 Mod 4 Fixpack 5
Temporary fix
Comments
APAR Information
APAR number
IT26658
Reported component name
DB2 FOR LUW
Reported component ID
DB2FORLUW
Reported release
B10
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2018-10-18
Closed date
2020-01-16
Last modified date
2020-01-16
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fix information
Fixed component name
DB2 FOR LUW
Fixed component ID
DB2FORLUW
Applicable component levels
RB10 PSN
UP
[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSEPGG","label":"DB2 for Linux- UNIX and Windows"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"11.1","Line of Business":{"code":"LOB10","label":"Data and AI"}}]
Document Information
Modified date:
04 May 2022