DB2-duplicate-key-Fehler beim einfügen, ABER die Arbeit nach select count(*)
Habe ich eine - für mich unbekannte - Problem und ich weiß nicht, was die Logik/Ursache dahinter. Wenn ich versuche, einfügen eines Datensatzes in eine Tabelle bekomme ich ein DB2-Fehler sagen:
[SQL0803] Duplicate key value specified: A unique index or unique constraint *N in *N
exists over one or more columns of table TABLEXXX in SCHEMAYYY. The operation cannot
be performed because one or more values would have produced a duplicate key in
the unique index or constraint.
Das ist eine ganz klare Nachricht an mich. Aber eigentlich würde es keine doppelten Schlüssel, wenn ich eingefügt, mit meinem neuen Album zu sehen, was Datensätze sind bereits dort. Wenn ich eine SELECT COUNT(*) from SCHEMAYYY.TABLEXXX
und dann versuchen einzufügen das aufnehmen funktioniert auch tadellos.
Wie kann es sein, dass bei der Durchführung der SELECT COUNT(*)
ich kann plötzlich einfügen der Datensätze? Gibt es irgendeine Art von index zugeordnet, mit denen Probleme geben könnte, weil es ist out of sync? Ich wusste nicht, design des Datenmodells, so dass ich nicht haben Tiefe Kenntnisse des system noch.
Des ursprünglichen DB2-SQL ist:
-- Generate SQL
-- Version: V6R1M0 080215
-- Generated on: 19/12/12 10:28:39
-- Relational Database: S656C89D
-- Standards Option: DB2 for i
CREATE TABLE TZVDB.PRODUCTCOSTS (
ID INTEGER GENERATED BY DEFAULT AS IDENTITY (
START WITH 1 INCREMENT BY 1
MINVALUE 1 MAXVALUE 2147483647
NO CYCLE NO ORDER
CACHE 20 )
PRODUCT_ID INTEGER DEFAULT NULL ,
STARTPRICE DECIMAL(7, 2) DEFAULT NULL ,
FROMDATE TIMESTAMP DEFAULT NULL ,
TILLDATE TIMESTAMP DEFAULT NULL ,
CONSTRAINT TZVDB.PRODUCTCOSTS_PK PRIMARY KEY( ID ) ) ;
ALTER TABLE TZVDB.PRODUCTCOSTS
ADD CONSTRAINT TZVDB.PRODCSTS_PRDCT_FK
FOREIGN KEY( PRODUCT_ID )
REFERENCES TZVDB.PRODUCT ( ID )
ON DELETE RESTRICT
ON UPDATE NO ACTION;
TABLEXXX
? Das sollte zeigen das index/unique-Einschränkungen, die Sie haben. Außerdem können Sie die insert-Anweisung?Wahrscheinlich etwas seltsam in Ihren Definitionen, aber ja, es ist möglich, dass Sie eine hohe Stufe der Optimierung, die mit Ihren Statistiken für die Tabelle out-of-date. Obwohl ich dachte, dass in der Regel unique-Einschränkungen wurden nur erzwungen nachdem die
INSERT
wurde versucht,...Hinzugefügt wurde die generierte SQL von der Tabelle in das original-posting.
Hast du eine Lösung finden? Ist das noch passiert?
InformationsquelleAutor tjeerdnet | 2012-12-14
Du musst angemeldet sein, um einen Kommentar abzugeben.
Ich würde gerne sehen, das Aussagen...aber da diese Frage ist ein Jahr alt...ich werde nicht alt mein Atem.
Ich denke, das problem kann sein
STANDARDMÄßIG GENERIERT
Und statt übergeben NULL für die identity-Spalte, du bist versehentlich übergibt keine oder einige andere doppelte Wert das erste mal um.
Entweder immer NULL übergeben, übergeben Sie einen nicht-doppelten Wert oder Schalter ERZEUGT IMMER
InformationsquelleAutor Charles
Blick auf vorhergehende Meldungen im joblog für Besonderheiten, was dies verursacht. Ich verstehe nicht wie man die EINFÜGEN kann plötzlich arbeiten nach dem COUNT(*). Bitte lassen Sie uns wissen, was Sie suchen.
Da es zeigt
*N
(dh n/a) wie der name des Indexes oder der constraing, dies lässt mich vermuten, das ist nicht ein standard-DB2-Objekt, und daher kann ein "logischen Datei" [LF] definiert mit DDS statt SQL mit einem Schlüssel, der Struktur anders als das, was Sie Taten, Ihre COUNT(*) auf.Ihrem shop haben können, bessere Werkzeuge zu betrachten Schlüssel auf die abhängigen Dateien, aber die Methode funktioniert überall.
Wenn Ihre Tabelle möglicherweise nicht dem tatsächlichen "physischen " Datei", überprüfen Sie diese mit Hilfe der Anzeige-Datei Beschreibung,
DSPFD TZVDB.PRODUCTCOSTS
, 5250 ("green screen") session.Verwenden Sie die Anzeige von Datenbank-Beziehungen-Befehl
DSPDBR TZVDB.PRODUCTCOSTS
zu finden, welche Dateien definieren sich über Ihren Tisch. Sie können dannDSPFD
auf jede dieser Dateien, um zu sehen, die definition des index-Taste. Überprüfen Sie auch dort, dass jeder dieser Indizes ist gepflegt*IMMED
eher als*REBUILD
oder*DELAY
. (Eine wilde longshot denke da an ein Netzwerk möglich Ursache Ihrer seltsamen Anomalie.)Finden Sie die DB2 für i message finder hier in der IBM i 7.1 Information Center oder andere Versionen
InformationsquelleAutor WarrenT
Ist es eine paging-Problem? wir scheinen -0803 auf Einsätze gelegentlich, wenn eine Zeile gehalten wird, für das update und sperrt es eine Seite, die wahrscheinlich enthält der index, der benötigt wird für das einfügen? Dies ist nur eine Vermutung, aber es scheint mir, dass ist das, was passiert ist.
InformationsquelleAutor jackanalyst