DB2 - Problem description
Problem IC65694 | Status: Closed |
LOAD FROM CURSOR WITH DATABASE CLAUSE ('REMOTE-FETCH') FAILS OR TRAPS IF DB2_PARTITIONEDLOAD_DEFAULT=NO | |
product: | |
DB2 FOR LUW / DB2FORLUW / 970 - DB2 | |
Problem description: | |
Loading from a CURSOR that was defined with the DATABASE clause (also known as a 'remote-fetch' load) may fail with an SQL1024N if the DB2_PARTITIONEDLOAD_DEFAULT is set to no or false, and the instance is DPF (including single-node DPF). SQL3254N The utility is beginning to load data from the Table ""."" in database"". SQL1024N A database connection does not exist. SQLSTATE=08003 In some scenario's a trap has occurred, but is unlikely. | |
Problem Summary: | |
Loading from a CURSOR that was defined with the DATABASE clause (also known as a 'remote-fetch' load) may fail with an SQL1024N if the DB2_PARTITIONEDLOAD_DEFAULT is set to no or false, and the instance is DPF (including single-node DPF). SQL3254N The utility is beginning to load data from the Table ""."" in database"". SQL1024N A database connection does not exist. SQLSTATE=08003 In some scenario's a trap has occurred, but is unlikely. | |
Local Fix: | |
Unset DB2_PARTITIONEDLOAD_DEFAULT (or set to 'yes') if this makes sense from your application perspective. | |
available fix packs: | |
DB2 Version 9.7 Fix Pack 2 for Linux, UNIX, and Windows | |
Solution | |
First fixed in DB2 v970 fixpak 2 | |
Workaround | |
Unset DB2_PARTITIONEDLOAD_DEFAULT (or set to 'yes') if this makes sense from your application perspective. | |
Timestamps | |
Date - problem reported : Date - problem closed : Date - last modified : | 20.01.2010 13.05.2010 13.05.2010 |
Problem solved at the following versions (IBM BugInfos) | |
9.7.0 | |
Problem solved according to the fixlist(s) of the following version(s) | |
9.7.0.2 |