2016-12-13 7 views
0

Я получаю SQLSTATE = 23505 ошибки, когда я выполнить следующий оператор DB2:SQL SQLSTATE/DB2 = 23505 ошибки при исполнении UPDATE заявления

update SEOURLKEYWORD 
set URLKEYWORD = REPLACE(URLKEYWORD, '/', '-') 
where STOREENT_ID = 10701 
and URLKEYWORD like '%/%'; 

После быстрого поиска, определена 23505 ошибки SQL состояния следующим образом:

AN INSERTED OR UPDATED VALUE IS INVALID BECAUSE THE INDEX IN INDEX SPACE CONSTRAINS COLUMNS OF THE TABLE SO NO TWO ROWS CAN CONTAIN DUPLICATE VALUES IN THOSE COLUMNS RID OF EXISTING ROW IS X

полная ошибка я вижу это:

The full error I am seeing is:

DB2 Database Error: ERROR [23505] [IBM][DB2/LINUXX8664] SQL0803N One or more values in the INSERT statement, UPDATE statement, or foreign key update caused by a DELETE statement are not valid because the primary key, unique constraint or unique index identified by "2" constrains table "WSCOMUSR.SEOURLKEYWORD" from having duplicate values for the index key. SQLSTATE=23505 1 0

Я не уверен, что «индекс язь ntified by '2' ", но это может быть значительным.

Свойства столбцов для таблицы SEOURLKEYWORD следующим образом:

enter image description here

Основываясь на моем понимании этой информации, единственный столбец, который вынужден быть уникальным является SEOURLKEYWORD_ID, основной колонке ключ , Это заставляет это звучать, как оператор обновления, который я пытаюсь запустить, пытается вставить строку с идентификатором SEOURLKEYWORD_ID, который уже существует в таблице.

Если я запускаю SELECT * заявление по рядам я пытаюсь обновить, вот что я получаю:

select * from SEOURLKEYWORD 
where storeent_id = 10701 
and lower(URLKEYWORD) like '%/%'; 

enter image description here

Я не понимаю, как выполнение оператора UPDATE является в результате здесь ошибка. Есть только 4 строки, на которые это утверждение должно даже смотреть, и я не вручную обновляю первичный ключ вообще. Кажется, это похоже на повторную вставку повторяющейся строки с обновленным значением столбца перед удалением существующей строки.

Почему я вижу эту ошибку при попытке обновить столбец URLKEYWORD из этих четырех строк? Как я могу решить эту проблему?

ВАЖНО: Поскольку я написал этот вопрос, я сузил проблему до последней из четырех строк в таблице выше, SEOURLKEYWORD_ID = 3074457345616973668. Я могу обновить три другие строки просто отлично, но четвертая строка вызывает ошибка, я понятия не имею, почему. Если я запустил select * из SEOURLKEYWORD, где SEOURLKEYWORD_ID = 3074457345616973668 ;, я вижу только 1 строку.

ответ

1

Это слишком длинный комментарий.

Ошибка довольно ясна. У вас есть уникальный индекс/ограничение в таблице. Скажем, у вас есть два ряда, как это:

STOREENT_ID URLKEYWORD 
    10701  A/B 
    10701  A-B 

Когда первая версия заменяется 'A-B', результат будет нарушать ограничение уникальности на (STOREENT_ID, URLKEYWORD) или (URLKEYWORD) (Обратите внимание, что другие столбцы могли бы быть включены в ограничение уникальности/индекс также).

Вы можете избежать этих ситуаций, не обновляя их. Я не знаю, в каких столбцах есть уникальное ограничение, но скажем только на URLKEYWORD.Тогда:

update SEOURLKEYWORD 
    set URLKEYWORD = REPLACE(URLKEYWORD, '/', '-') 
where STOREENT_ID = 10701 and 
     URLKEYWORD like '%/%' and 
     not exists (select 1 from SEOURLKEYWORD s2 where replace(s2.urlkeyword, '/', '-') = REPLACE(SEOURLKEYWORD.URLKEYWORD, '/', '-') 
       ); 

Обратите внимание на replace() требуется для обеих колонок, потому что вы могли бы иметь:

A-B/C 
A/B-C 

Эти только конфликт после замены в обоих значениях.

+0

Это действительно вопрос , Одна строка, о которой я упоминал, вызывала все проблемы с сестринской строкой в ​​таблице, которая уже была/заменена на. Единственное, о чем я до сих пор не знаю, это то, как вы можете сказать, что столбцы STOREENT_ID и URLKEYWORD имеют эти «вынужденные быть уникальными» отношениями? Очевидно, ошибка выдает его, но, глядя на свойства таблицы, я не вижу никаких указаний на это отношение. Поскольку эти строки имеют разные первичные ключи, не должны ли вы иметь эти два столбца одинаковыми до тех пор, пока значения SEOURLKEYWORD_ID не совпадают? – jros

+0

@jros У вас, похоже, есть более одного уникального ограничения для таблицы - первичный ключ, скорее всего, будет «уникальным ограничением или уникальным индексом, идентифицированным« 1 », но в сообщении об ошибке указано, что есть и тот, который идентифицирован (то есть , имеющий идентификатор) «2». – mustaccio

+0

@mustaccio Я вижу, я был не уверен, что этот идентификатор = '2' в ошибке имел в виду. Мне нужно выяснить, как увидеть эти отношения. Благодаря! – jros

1

В дополнение ответ дается @GordonLinoff, вот запрос, который может быть использован, чтобы найти уникальные ограничения таблицы, необходимо с их идентификаторами, а столбцы, включенные в них:

SELECT c.tabschema, c.tabname, i.iid AS index_id, i.indname, ck.colname 
FROM syscat.tabconst c 
INNER JOIN syscat.indexes i 
ON i.indname = c.constname -- unique index name matches constraint name 
AND i.tabschema = c.tabschema AND i.tabname = c.tabname 
INNER JOIN syscat.keycoluse ck 
ON ck.constname = c.constname 
AND ck.tabschema = c.tabschema c.tabname = ck.tabname AND 
WHERE c.type = 'U' -- constraint type: unique 
AND (c.tabschema, c.tabname) = ('YOURSCHEMA', 'YOURTABLE') -- replace schema/table 
ORDER BY i.iid, ck.colseq 
Смежные вопросы