DB2 double de la clé d'erreur lors de l'insertion, MAIS le travail après select count(*)

J'ai un - pour moi inconnue - et je ne sais pas quelle est la logique/cause derrière elle. Lorsque j'essaie d'insérer un enregistrement dans une table-je obtenir une base de données DB2 d'erreur disant:

[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.

Qui est un message clair pour moi. Mais en fait il n'y aurait pas de clé en double si j'ai inséré mon nouveau record de voir ce que les enregistrements sont déjà là. Quand je fais un SELECT COUNT(*) from SCHEMAYYY.TABLEXXX et puis essayez d'insérer le dossier, il fonctionne parfaitement.

Comment se peut-il que lors de l'exécution de la SELECT COUNT(*) je peux soudain insérer les enregistrements? Est-il une sorte d'index associés qui peuvent donner des problèmes, car il est hors de synchronisation? Je n'ai pas de conception du modèle de données, donc je n'ai pas la connaissance profonde du système.

L'original DB2 SQL est:

--  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;
  • Pouvez-vous nous montrer la définition de la table de TABLEXXX? Qui devrait montrer l'index/contraintes unique que vous avez. Aussi, pouvez-vous montrer l'instruction insert?
  • Probablement quelque chose de bizarre dans vos définitions, mais oui, il est possible que vous avez un haut niveau d'optimisation, avec votre tableau de statistiques out-of-date. Bien que j'ai pensé que généralement les contraintes uniques ont été appliqués uniquement après la INSERT a été tentée...
  • Ajouté le SQL généré à partir de la table dans le message d'origine.
  • Avez-vous trouvé une solution? Est-ce encore qui se passe?
InformationsquelleAutor tjeerdnet | 2012-12-14