Ошибка в работе приложения не удается вставить повторяющуюся строку ключа в объект

Обновлено: 07.01.2025

Невозможно вставить дубликат ключевой строки в объект 'dbo.CLIENT' с уникальным индекс 'CLIENT_idx_A'. Повторяющееся значение ключа: (14441828, 1).

Когда я проверил индексы, он был создан вот так:

На самом деле, я хочу обновить одно значение в SOURCE_SYSTEM_CLIENT_ID , и мой SOURCE_SYSTEM_ID равен 1 для всех SOURCE_SYSTEM_CLIENT_ID , которые я хочу обновить. Так что я думаю, что он столкнулся с дубликатом. Как я могу решить эту проблему?

1 ответ

В первый раз, когда я добавляю миграцию, мой посев работает. Однако, если я запускаю его снова, я получаю исключение System.Data.SqlClient.SqlException: не удается вставить дублирующуюся строку ключа в объект 'dbo.Attributes' с уникальным индексом 'IX_AttributeName'. Значение дубликата ключа равно.

Очевидно, что (?) следующий запрос вернет строку, с которой дублируется ваш оператор update;

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

Удаление ограничения немного экстремально, если вы намеренно не перестраиваете схему, и это сделает вас уязвимым для ошибок в вашем SQL и приложении, которые могут повредить ваши данные. Действуйте здесь только в том случае, если вы действительно знаете, что делаете и чего добиваетесь.

Похожие вопросы:

Сервер базы данных: SQL Server 2000 - 8.00.760 - SP3 - Стандартное издание У меня есть таблица с 5 столбцами, в которую я хочу добавить большое (300.000) количество записей. Существует уникальный.

У меня есть приложение, которое позволяет пользователям вставлять запись в таблицу со столбцом, имеющим уникальное ограничение индекса ключа, определенное как CREATE UNIQUE NONCLUSTERED INDEX.

Я думал, что MERGE - это атомарная операция вставки/обновления, но запуск теста с несколькими потоками, вызывающими мой sproc, выполняющий upsert, я сталкиваюсь с нарушением ограничения дубликата.

история : я провел исследование об использовании SQL Server для моего проекта Yii2 и успешно подключился и запустил миграцию. проблема : я хочу зарегистрировать нового пользователя из моего проекта.

На сайте электронной коммерции код вставляет информацию о доставке заказа в другую таблицу базы данных.

Вот код, который вставляет информацию в таблицу:

Он работает правильно, но также выводит следующую ошибку SQL:

Нарушение ограничения PRIMARY KEY PK_AC_Shipping_Addresses. Невозможно вставить повторяющийся ключ в объект 'dbo.AC_Shipping_Addresses'. Повторяющееся значение ключа - (165863).

Читая подобные вопросы, мне кажется, что я должен указать идентификатор в заявлении.

Любая помощь приветствуется!

Уверен, что pk_OrderID - это PK AC_Shipping_Addresses

И вы пытаетесь вставить дубликат через _Order.OrderNumber

Или выберите количество (*) .

Вполне уверен, что вы получите возвращенную строку.

Он сообщает вам, что вы уже используете pk_OrderID = 165863 и не можете иметь другую строку с этим значением.

Если вы не хотите вставлять, если есть строка

Я получал ту же ошибку в восстановленной базе данных, когда пытался вставить новую запись с помощью EntityFramework. Оказалось, что Indentity / Seed лажали.

Исправлено использование команды Reseed.

Это может быть вызвано несколькими причинами, и это в некоторой степени зависит от того, что вы настроили в своей базе данных.

Во-первых, вы можете использовать PK в таблице, которая также является FK для другой таблицы, создавая связь 1-1. В этом случае вам может потребоваться обновление, а не вставка. Если у вас действительно может быть только одна адресная запись для заказа, это может быть тем, что происходит.

Затем вы можете использовать какой-то ручной процесс, чтобы заранее определить идентификатор. Проблема с этими ручными процессами заключается в том, что они могут создавать условия гонки, когда две записи используют один и тот же последний идентификатор и увеличивают его на один, а затем вторая не может вставить.

Убедитесь, что в вашей таблице еще нет строк, значения первичного ключа которых совпадают с идентификатором первичного ключа в вашем запросе.

Не ответ OP, но поскольку это был первый вопрос, который возник у меня в Google, я также хотел бы добавить, что пользователям, которые ищут это, возможно, потребуется повторно заполнить свою таблицу, что было для меня

Чтобы предотвратить вставку уже существующей записи. Я бы проверил, существует ли значение ID в базе данных. Для примера таблицы, созданной с помощью ПЕРВИЧНОГО КЛЮЧА IDENTITY:

Когда ДЖЕЙН ДОУ и ДЖО БРАУН уже существуют в базе данных.

ВЫВОД БАЗЫ ДАННЫХ ТАБЛИЦЫ [dbo]. [Люди] будут:

Я бы проверил, следует ли мне обновить существующую запись или вставить новую. Как следующий пример JAVA:

Какое значение вы передаете первичному ключу (предположительно «pk_OrderID»)? Вы можете настроить его на автоматическое увеличение, и тогда никогда не должно возникнуть проблем с дублированием значения - об этом позаботится БД. Если вам нужно указать значение самостоятельно, вам нужно будет написать код, чтобы определить максимальное значение для этого поля, а затем увеличить его.

. это называется так:

Необязательно, но я храню запрос отдельно:

Вы можете убедиться, что вы не собираетесь вставлять уже существующее значение с помощью (псевдокода):

Запрос выглядит примерно так: SELECT COUNT FROM TABLE WHERE BLA = @CANDIDATEIDVAL, а значение - это идентификатор, который вы потенциально собираетесь вставить:

Обратите внимание - до официального релиза техническая поддержка данной версии не осуществляется! Об ошибках можно сообщать в этой теме.

Новые возможности:
Поддержка электронных сейфов СК-24 (ключница).
Поддержка биометрических контроллеров C2000-BioAcess F8\F4.
Новая система речевого оповещения позволяет производить оповещение о любом событии системы, а так же воспроизводить произвольный текст из сценариев.
Экспорт базы данных в пульт полностью совместим с pprog. При этом формируются файлы конфигураций для pprog.
Расширен механизм управления сценариями, добавлены новые шаблоны сценариев.

Изменения:
Обновлённая документация.
Изменён механизм добавления портов и устройств в АБД - система следит за соответствием приборов, добавляемых к порту, указанному протоколу.
Модуль статистики отображает АЦП для любого типа зон.
Скорректированы отчёты для генератора отчётов.

Не вошедшее в выпуск:
Поддержка векторных планов.

ftp сервер почему то не работает. Остаётся только надеяться что он заработает раньше, чем закончатся новогодние праздники. Предрелизная. = с недоштопаными штанами.Ходить уже можно ..но не на публике.К тому же фтп. помер. Релизные как правило тоже напоминают тришкин кафтан. С месяц назад с sp5 пришлось на sp2 откатываться. fixer2005 писал(а): Предрелизная. = с недоштопаными штанами.Ходить уже можно ..но не на публике.К тому же фтп. помер. Ходить ещё нельзя, только померить .
А вот с ftp какая-то беда. Наверно тоже решил отдохнуть на новый год.
К сожалению до конца новогодних праздников я не могу узнать что с ним случилось и когда он заработает. В релизе поправят возможность вращать уго датчиков планах? Ни на 7 64бит ни на 8. нет элемента упраления вращением. х.з. может так задумано. но у приборов этот элемент есть. либо баг..либо враг.

FRP сервер работает.

fixer2005 писал(а): В релизе поправят возможность вращать уго датчиков планах? . Когда на планах размещаешь извещатели. то ставятся как есть . Например объемник размещенный в углу комнаты. неестественно смотрит в стену. Также было бы екплохо чтоб вместо стрелки был уголок. Посмотрите как размещаются приборы на планах. Приборы это Сигналы и др. все поймете. Для приборов слева в окне размещения на планах есть контрол повороота прибора. там градусы задаются. Например размещаемый на плане прибор можно повернуть на 90 градусов и прислюнить к вертикальной стенке помещения. и курсор мняет форму со стрелки на уголок.Это удобно когда нужно расставить извещатели ровно по линии. например на ограждении периметра создается имитация вибрационного средства обнаружения. Оно по определению линейно. а в интерфейсе нет активных линий кроме разделов..Но вот есть заказчии кому нужно визуально показать блоировку участка периметра(Дельфин,Гюрза) в виде линии или группы точек. Так вот когда куросор уголком..то легко ровно расставить датчики на "проволоке" ограждения создав имитацию линеного извещателя. Понял вас. В 1.12 такой возможности не будет.
Планируется с векторными планами. Сроки векторных планов неизвестны. Ключик от 1.11 не подходит. сервер от 1.12 не видит ключей. пишет демо-режим. Где прочитать про векторные планы. что задумано реализовать на их базе?(zoom-ирование было бы оченеь гуд).Хотя это не критично.. Ну а уголок(крестик) - курсор для расстановки уго. желательно прикрутить к расстановке извещателей, а не только приборов. и контрол поворота на форме размещения извещателей (это всего одно доп. поле в SQL-табличке. угол поворота элемента)..Неплохо было бы патчем заклеить. fixer2005 писал(а): Ключик от 1.11 не подходит. сервер от 1.12 не видит ключей. пишет демо-режим.

Файлик prvd.ini не забыли скопировать?

fixer2005 писал(а): Где прочитать про векторные планы. что задумано реализовать на их базе? 1.12RC. перенос рабочей базы. через модернизацию(и соответственно создание новой БД) прошел с ошибками..и теперь вот так . в АБД вся конфигурация с планами есть. а ОЗ стартует просто девственно пустой. ни разделов ни планов..ни событий..Демонстратор приборов естественно в ОЗ ничего не передает. Думаю из-за ошибок модернизации. Ну база была 1.11 . ошибки
вот что выводит проверка присоединенной старой базы..
Спойлер

Не верная длина поля Contents в таблице EVENTS
Не верная длина поля Comment в таблице EVENTS
Несовпадение количества полей в таблице RSLINES = 20 ( должно быть 21 )
Несовпадение количества полей в таблице PMAPS = 9 ( должно быть 12 )
Не верная длина поля Name в таблице SCRIPT
Несовпадение количества полей в таблице GTIME = 5 ( должно быть 6 )
Несовпадение количества полей в таблице REASONS = 11 ( должно быть 12 )
Несовпадение количества полей в таблице GROUPS = 3 ( должно быть 5 )
Несовпадение количества полей в таблице PDIVISION = 10 ( должно быть 11 )
Несовпадение количества полей в таблице PPOST = 6 ( должно быть 7 )
Несовпадение количества полей в таблице PCOMPANY = 5 ( должно быть 6 )
Несовпадение количества полей в таблице PLIST = 26 ( должно быть 28 )
Несовпадение количества полей в таблице CAMERAS = 12 ( должно быть 13 )
Несовпадение количества полей в таблице VINSP = 9 ( должно быть 10 )
Не верная длина поля Remark в таблице PLOGDATA
Таблица VIDEORECOGNIZEPROFILES не существует!
Таблица VIDEORECOGNIZECHANNELS не существует!
Таблица PCAR не существует!
Таблица RELATIONSLISTCAR не существует!
Таблица MAPELEMENTS не существует!
Таблица MAPELEMENTSREGIONS не существует!
Таблица MAPELEMENTSLINKS не существует!
Операция прервана на этапе: Проверка структуры - в следствии ошибок

Вот окно которое выводится при модернизации

А вот что по окончанию если нажать ДА
Спойлер

Таблица: MAP_ELM; Ошибка: Не удается вставить повторяющуюся строку ключа в объект "dbo.Map_Elm" с уникальным индексом "Ibx_Map_Elm_MapID". Повторяющееся значение ключа: (2, 31, 0)
Источник: Таблица MAP_ELM; MapID = 3; GType = 31; Num = ; UnitID = 10; PictureCount = ; Pictures = ; ChangeTime = 28.12.2012 11:06:38;
Запись: Таблица MAP_ELM; MAPID = 2; GTYPE = 31; NUM = ; UNITID = 0; PICTURECOUNT = ; PICTURES = ; CHANGETIME = 28.12.2012 11:06:38; ID_OLD = 60;

Подозреваю что с мапам связь. но АБД открывает модернизированную базу. всю структуру показывает..планы..датчики..приборы. а ОЗ них-нихя

После этого пишет что версия БД 1.12.

Проверка старой базы в новом менеджере сервера не имеет смысла.
Судя по всему не перенёсся один из элементов расположенных на панах и скорее всего это была висячая ссылка, которая ни на что не влияет.
Если АБД всё показывает (все карты и элементы на них), то модернизация прошла нормально.
Вам стоит попробовать очистить кеш системы. Закройте все программы и удалите папку "TEMP" в каталоге с Орион ПРО 1.12

Кстати сервант БД от версии 1.12 работает с прожками от 1.11. бд 1.11 проходит проверку на ура..с оснасткой управления сервером от 1.11. абд от 1.11 и оз запускаются и все корректно рисуют. А вот ОЗ и АБД от 1.12 без модернизации БД..них-нихя..АБД ругается на поля . ОЗ стартукет девственно чистым(это в принципе ожидаемо). ну про модернизацию..см.выше.

То бишь ..база 1.11 сервант 1.12 оснастка 1.11(оснастка 1.12 проверяет с ошибками). абд 1.11 оз 1.11. и робит сей комплектик.Времени конечно мало на тест совместимости. но старт проходит ровно по плану. проверю еще демонстратор. (Лучше назвать ТЕСТЕР СИСТЕМЫ)

4. В окне запроса пишем код для поиска данных в таблице:

_AccRgAT118760 – название таблице в котором произошел сбой. Оно отображается в окне ошибки в 1С.
_AccountRRef – название столбца_1 где будем искать.
0xab52f3e52b35efa847b0cfef9c90ff9d – значение_1 которое будем искать. Оно отображается в окне ошибки в 1С.
_Fld18737RRef – название столбца_2 где будем искать.
0x95eb00112f2a1abf11dac09f12116a47 – значение_2 которое будем искать. Оно отображается в окне ошибки в 1С.

Название столбцов можно посмотреть следующем образом:

test_stand_2_cb – название нашей сбойной базы

_AccRgAT118760 – таблица, в которой будем производить удаление объекта

_AccountRRef – столбец_1, в котором будем искать параметр для удаления

0xab52f3e52b35efa847b0cfef9c90ff9d – значение_1, которое должно стоять в столбце_1

_Fld18737RRef – столбец_2, в котором будем искать параметр для удаления

0x95eb00112f2a1abf11dac09f12116a47 – значение_2, которое должно стоять в столбце_2

_Fld18739 – столбец_3, в котором будем искать параметр для удаления

-1500.00 – сумма, которая должна стоять в столбце_3. Так как первое и второе значение будет содержаться во многих строках в таблице, нам нужно будет третье уникальное значение, по которому будет происходить поиск для удаления. Сумма нам может в этом помочь, т.к. значение суммы может совпадать с суммой сбойного документа.

После написания запрос на удаления значения из таблицы нажимаем кнопку «Выполнить» или F5 на клавиатуре.
После выполнения процедуры в SQL мы можем произвести нужные нами манипуляции со сбойным документом, которые ранее выдавали нам ошибку.
Так же крайне желательно произвести пересчет итогов и проверить обороты.

12 Comments

Очень бы хотелось узнать, по какой причине возможно такое? Что такое смогли сделать пользователи, что 1С вываливается в такую ошибку.

Я не утверждаю что это золотой грааль решения данной проблемы, но данный способ нам помог и я решил им поделиться. SQL-я боятся не надо и если все делать грамотно и аккуратно, то ни чего не сломаешь.

Что выделаете? Вы удаляете запись из таблицы итогов. Напрямую из таблицы. По какому-то счету. После чего у вас все проводится и вы думаете, что исправили ошибку.

Итоги после этого пересчитали и оборотку формировали, все норм.

Могу да же больше сказать, эта проблема возникла в последний день сдачи отчетности и проблему надо было решать оперативно. Отчетность сдана успешна.

Читайте также: