今日、この回答のおかげで、DGTTの実験を始めました。これは明らかな利点です。exists.エラーの意味は明らかですが、タイミングはわかりません。今日始めたとき、クエリを複数回実行できましたが、エラーは発生しませんでした。システムがクリーンアップして削除しているように見えましたが、まさにそれが私が探していたものです。その後エラーが始まり、今ではより頻繁に発生しています。これはテーブルが存在しない限りエラーを解決します。その場合、別のエラーが発生します。devクライアントからサーバーへの接続を切断/再接続することもできます。DGTTに関するIBMの記事は、多くのセッションについて語っています。多くの詳細はありません。この記事は、おそらく私が使った中で最も長いコマンド構文ですまだIBMのドキュメントに記載されています。私はそれを乗り越えましたが、DGTTがいつ削除されるかを決定したものの質問には答えませんでした。私は尋ねたい:セッションの境界は?。これはおそらく、SQLクライアントの環境によって定義されると考えています。必要に応じて..?共有できるヒント、トリック、またはポインターがありますか?。以下は、私が開発しているSQLです。Db2へのインターフェースが使用されている場合は、同等のもの)。これにより、セッションが開いたままであっても、DGTTが既に存在するかどうかにかかわらず、コードの次回の実行時にテーブルを置き換える必要がある場合、明示的にDGTTを削除する必要がなくなります。本当にドロップを発行する場合を除き、DGTTのステートメント。実行時エラーを簡単に回避するには不可欠です。(ただし、これはDb2-for-iおよびDb2-LUWについては文書化されていません。