質問
したがって、データベース インスタンスが 2 つあり、1 つは一般的な開発用で、もう 1 つは単体テスト用に開発からコピーされました。
開発データベースで何かが変更されましたが、私には理解できず、何が違うのかを確認する方法もわかりません。
特定のテーブルから削除しようとすると、たとえば次のようになります。
delete from myschema.mytable where id = 555
単体テスト DB から、行が削除されていないことを示す次の通常の応答を受け取ります。
SQL0100W FETCH、UPDATE、または DELETE の行が見つかりませんでした。または、クエリの結果が空のテーブルになります。SQLSTATE=02000
ただし、開発データベースは次のエラーが発生して削除にまったく失敗します。
DB21034E コマンドは有効なコマンド行プロセッサーのコマンドではなかったため、SQL ステートメントとして処理されました。SQL 処理中に、以下が返されました。SQL0440N 互換性のある引数を持つタイプ「FUNCTION」の「=」という名前の許可されたルーチンが見つかりませんでした。SQLSTATE=42884
私の推測では、問題の原因となっている追加または変更されたトリガーまたはビューがあると考えられますが、問題を見つける方法がわかりません...誰かこの問題に遭遇した人、または問題の根本が何であるかを特定する方法を知っている人はいますか?
(これは DB2 データベースであることに注意してください)
解決
うーん、この質問に偉大な神託を当てはめると、次のような結果になりました。
http://bytes.com/forum/thread830774.html
別のテーブルに問題のあるテーブルを指す外部キーがあることを示唆しているようです。他のテーブルの FK が削除されると、削除は再び機能するはずです。(外部キーも再作成できると思われます)
それは何か役に立ちますか?
他のヒント
開発データベースでトランザクションが開いている可能性があります...SQL Server で時々問題が発生します
IDの種類は555と互換性がありますか?それとも非整数型に変更されたのでしょうか?
あるいは、引数 555 が何らかの理由で欠落しているのでしょうか (例:JDBC を使用していて、クエリを実行する前に準備されたステートメントの引数が設定されていない場合)?
質問にさらに追加していただけますか?このエラーは、SQL ステートメント パーサーがステートメントに関して非常に混乱しているように思えます。そのテーブルで id = 555 の行を選択できますか?
そのテーブルで RUNSTATS と REORG TABLE を実行してみると、不安定なテーブルが整理されるはずです。
同じ「where」条件での選択は問題なく機能しますが、削除はできません。runstats も reorg table も問題には影響しません。
実際、私たちは問題を解決したばかりで、確かにあなたが言ったことどおりです(同僚もまったく同じページを見つけました)。
解決策は、外部キー制約を削除し、再度追加することでした。
この件に関する別の投稿:
http://www.ibm.com/developerworks/forums/thread.jspa?threadID=208277&tstart=-1
これは、問題が参照制約の破損であることを示しており、実際には、あるいはいずれにしても、db2 V9 の新しいバージョン (まだ使用していません) で修正されていると考えられます。
助けてくれてありがとう!
1を確認してください。トリガー、プロシージャ、関数などの引数。2.引数のデータ型。