I think the explanation of the message is clear:
Quote:
$ db2 "? sql910"
SQL0910N The SQL statement cannot access an object on which a
modification is pending.
Explanation:
The application program attempted to access an object within the same
unit of work in which either:
* The application program issued a DROP against the object or a related
object (for example, an index for a table)
* The application program issued a statement against the object that
added or dropped a constraint.
* The application program issued a DROP TRIGGER or CREATE TRIGGER
statement that affected the object, either directly or indirectly.
* The application program issued a ROLLBACK TO SAVEPOINT statement,
which placed the object in the modification pending state.
* The application program issued a statement that caused all rows of a
NOT LOGGED declared temporary table to be deleted.
* The application program issued an ALTER TABLE ... ADD PARTITION,
ALTER TABLE ... ATTACH PARTITION or ALTER TABLE ... DETACH PARTITION
statement against the object (in this case a table). If a unit of
work contains an ALTER TABLE ... ATTACH PARTITION, then subsequently
in the same unit of work, an ALTER TABLE ... DETACH PARTITION cannot
be done on the same table.
* The application program issued a DETACH to create this object from a
data partition in a partitioned MDC table.
* The application program issued an SQL statement that attempted to
access a trusted context object on which a modification is pending.
The SQL statement may be one of the following:
* ALTER TRUSTED CONTEXT
* CREATE TRUSTED CONTEXT
* DROP TRUSTED CONTEXT
|
In short: you (still) access a table and, therefore, cannot drop it from underneath. After all, the cursor may still need the table's data.
The question is why you want to drop the DGTT in the first place. Just leave it around and when the connection is terminated, it will be cleaned up automatically.
dBforums
>
Droping SESSION(GLOBAL TEMPORARY table) table
03-02-09, 02:06
Droping SESSION(GLOBAL TEMPORARY table) table
Linear Mode
