Ошибка двойного ключа DB2 при вставке, НО работает после выбора счетчика (*)
У меня есть - для меня неизвестная - проблема, и я не знаю, какова логика / причина этого. Когда я пытаюсь вставить запись в таблицу, я получаю сообщение об ошибке DB2:
[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.
Что является достаточно ясным сообщением для меня. Но на самом деле не было бы дублирующего ключа, если бы я вставил свою новую запись, увидев, какие записи уже там. Когда я делаю SELECT COUNT(*) from SCHEMAYYY.TABLEXXX а затем попробуйте вставить запись, она работает без нареканий.
Как это может быть при выполнении SELECT COUNT(*) Я могу внезапно вставить записи? Есть ли какой-то индекс, связанный с ним, который может вызвать проблемы, потому что он не синхронизирован? Я не проектировал модель данных, поэтому у меня пока нет глубоких знаний о системе.
Оригинальный DB2 SQL:
-- 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;
4 ответа
Я хотел бы увидеть заявления... но так как этот вопрос годовалый... я не буду задыхаться.
Я думаю, что проблема может быть вызвана по умолчанию
И вместо того, чтобы передать NULL для столбца идентификаторов, вы случайно передаете ноль или какое-либо другое дублирующее значение в первый раз.
Либо всегда передайте NULL, передайте неповторяющееся значение, либо переключитесь на GENERATED ВСЕГДА
Посмотрите на предыдущие сообщения в журнале заданий на предмет специфики того, что вызвало это. Я не понимаю, как ВСТАВКА может внезапно работать после СЧЕТА (*). Пожалуйста, дайте нам знать, что вы найдете.
Так как это показывает *N (то есть н / д) в качестве имени индекса или ограничения, это наводит меня на мысль, что это не стандартный объект DB2, и поэтому может быть "логическим файлом" [LF], определенным с помощью DDS, а не SQL, с ключом структура отличается от того, что вы делали ваш COUNT(*).
В вашем магазине могут быть более совершенные инструменты для просмотра ключей зависимых файлов, но описанный ниже метод будет работать где угодно.
Если ваша таблица не может быть фактическим "физическим файлом", проверьте это с помощью Показать описание файла, DSPFD TZVDB.PRODUCTCOSTSв сеансе 5250 ("зеленый экран").
Используйте команду Показать связи с базой данных, DSPDBR TZVDB.PRODUCTCOSTS, чтобы найти, какие файлы определены в вашей таблице. Вы можете тогда DSPFD на каждом из этих файлов, чтобы увидеть определение индекса ключа. Также проверьте, что каждый из этих индексов поддерживается *IMMED, скорее, чем *REBUILD или же *DELAY, (Дикая длинная догадка относительно отдаленно возможной причины вашей странной аномалии.)
Поиск сообщений DB2 for i вы найдете здесь, в Информационном центре IBM i 7.1 или в других выпусках.
Это проблема подкачки? мы, кажется, иногда получаем -0803 на вставках, когда строка удерживается для обновления, и она блокирует страницу, которая, вероятно, содержит индекс, необходимый для вставки? Это только предположение, но мне кажется, что это то, что происходит.
Я знаю, что это старая тема, но это то, что Google показал мне в первую очередь.
У меня вчера была такая же проблема, вызывающая у меня много головной боли. Я сделал то же самое, что и выше, проверил определения таблиц, ключи, существующие элементы...
Затем я обнаружил, что проблема была с моей инструкцией INSERT. Он пытался вставить сразу в идентичные записи, но поскольку ограничение препятствовало фиксации, я ничего не мог найти в базе данных.
Совет: внимательно просмотрите оператор INSERT! :)