Frage

Ich habe also zwei Datenbankinstanzen, eine ist für die Entwicklung im Allgemeinen, eine andere wurde aus der Entwicklung für Komponententests kopiert.

In der Entwicklungsdatenbank hat sich etwas geändert, das ich nicht herausfinden kann, und ich weiß nicht, wie ich die Unterschiede erkennen kann.

Wenn ich versuche, aus einer bestimmten Tabelle zu löschen, zum Beispiel mit:

delete from myschema.mytable where id = 555

Ich erhalte die folgende normale Antwort von der Unit-Test-DB, die angibt, dass keine Zeile gelöscht wurde:

SQL0100W Für FETCH, UPDATE oder DELETE wurde keine Zeile gefunden;oder das Ergebnis einer Abfrage ist eine leere Tabelle.SQLSTATE=02000

Allerdings kann die Entwicklungsdatenbank überhaupt nicht gelöscht werden, und es erscheint die folgende Fehlermeldung:

DB21034E Der Befehl wurde als SQL-Anweisung verarbeitet, da es sich nicht um einen gültigen Befehl des Befehlszeilenprozessors handelte.Während der SQL-Verarbeitung wurde Folgendes zurückgegeben:SQL0440N Es wurde keine autorisierte Routine mit dem Namen „=" vom Typ „FUNCTION" mit kompatiblen Argumenten gefunden.SQLSTATE=42884

Meine Vermutung ist, dass ein Auslöser oder eine Ansicht hinzugefügt oder geändert wurde, die das Problem verursacht, aber ich habe keine Ahnung, wie ich das Problem finden soll ...Hat jemand dieses Problem gehabt oder weiß er, wie man die Ursache des Problems herausfinden kann?

(Beachten Sie, dass es sich hierbei um eine DB2-Datenbank handelt)

War es hilfreich?

Lösung

Hmm, als ich das große Orakel auf diese Frage anwendete, kam ich auf:

http://bytes.com/forum/thread830774.html

Es scheint darauf hinzudeuten, dass eine andere Tabelle einen Fremdschlüssel hat, der auf die problematische Tabelle verweist. Wenn dieser FK in der anderen Tabelle gelöscht wird, sollte der Löschvorgang wieder funktionieren.(Vermutlich können Sie den Fremdschlüssel auch neu erstellen)

Hilft das irgendjemandem?

Andere Tipps

Möglicherweise haben Sie eine offene Transaktion in der Entwicklungsdatenbank ... das bringt mich manchmal zu SQL Server

Ist der ID-Typ mit 555 kompatibel?Oder wurde es in einen nicht ganzzahligen Typ geändert?

Oder geht das 555-Argument irgendwie verloren (z. B.wenn Sie JDBC verwenden und die Argumente der vorbereiteten Anweisung vor der Ausführung der Abfrage nicht festgelegt wurden)?

Können Sie Ihrer Frage noch mehr hinzufügen?Dieser Fehler hört sich an, als wäre der Parser der SQL-Anweisung sehr verwirrt über Ihre Anweisung.Können Sie in dieser Tabelle eine Auswahl für die Zeile durchführen, in der id = 555 ist?

Sie könnten versuchen, RUNSTATS und REORG TABLE für diese Tabelle auszuführen, diese sollen wackelige Tabellen aussortieren.

@wegwerfen

Eine Auswahl mit der gleichen „Where“-Bedingung funktioniert einwandfrei, nur nicht löschen.Weder Runstats noch Reorg Table haben einen Einfluss auf das Problem.

@wegwerfen

Wir haben das Problem gerade erst gelöst, und tatsächlich ist es genau das, was Sie gesagt haben (ein Kollege hat genau dieselbe Seite auch gefunden).

Die Lösung bestand darin, Fremdschlüsseleinschränkungen zu löschen und sie erneut hinzuzufügen.

Noch ein Beitrag zum Thema:

http://www.ibm.com/developerworks/forums/thread.jspa?threadID=208277&tstart=-1

Dies deutet darauf hin, dass es sich bei dem Problem um eine Beschädigung der referenziellen Einschränkung handelt und dass es tatsächlich oder zumindest angeblich in einer späteren Version von db2 V9 (die wir noch nicht verwenden) behoben wurde.

Danke für die Hilfe!

Bitte überprüfen Sie 1.Ihre Argumente zu Triggern, Prozeduren, Funktionen usw.2.Datentyp von Argumenten.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top