Не удается вставить повторяющийся ключ в объект 1с

Обновлено: 07.07.2024

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

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

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

нарушение ограничения первичного ключа "PK_AC_Shipping_Addresses". Не может вставлять дубликат ключа в объекте ' dbo.AC_Shipping_Addresses'. Значение повторяющегося ключа is (165863).

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

это правильно? Как настроить код, чтобы устранить эту проблему?

любая помощь очень ценится!

довольно уверен, что pk_OrderID является ПК AC_Shipping_Addresses

и вы пытаетесь вставить дубликат через _Order.Номер заказа

или выберите функции count(*) .

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

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

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

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

С помощью команды reseed исправлено.

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

если у вас есть столбец с именем "ID" или такой, который не отображается в запросе, это нормально, если он настроен на autoincrement-но это, вероятно, нет, или вы не должны получить эту ошибку msg. Кроме того, вам было бы лучше написать более простой на глаз запрос и использовать params. Как заключил парень девяти лет, вы оставляете свою базу данных открытой для атак SQL-инъекций, если вы просто плюхаете введенные пользователем значения. Например, у вас может быть такой метод:

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

вам не нужно, но я сохраняю запрос отдельно:

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

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

Джастин хочет знать, будет ли это работать:

есть в основном 2 разных способа вставки записей без наличия ошибки:

1) когда IDENTITY_INSERT установлен. Первичный ключ " ID " НЕ ДОЛЖЕН ПРИСУТСТВОВАТЬ

2)Когда IDENTITY_INSERT установлен на. Первичный ключ " ID "ДОЛЖЕН ПРИСУТСТВОВАТЬ И ЗНАЧЕНИЕ" ID " НЕ ДОЛЖНО СУЩЕСТВОВАТЬ В БАЗЕ ДАННЫХ

в следующем примере из той же таблицы, созданной с первичным идентификатором Ключ:

1) в первом примере вы можете вставить новые записи в таблицу без получения ошибки, когда IDENTITY_INSERT выключен. Первичный ключ " ID " НЕ ДОЛЖЕН ПРИСУТСТВОВАТЬ из операторов "INSERT INTO"и уникальное значение ID будет добавлено автоматически:. Если идентификатор присутствует из вставки в этом случае, вы получите ошибку " не удается вставить явное значение для столбца identify в таблице. "

база данных Вывод таблицы [dbo].[Лица] будут:

2) во втором примере вы можете вставлять новые записи в таблицу без получения ошибки, когда IDENTITY_INSERT включен. Первичный ключ " ID " ДОЛЖЕН ПРИСУТСТВОВАТЬ из операторов" INSERT INTO " и**ЗНАЧЕНИЕ ПЕРВИЧНОГО КЛЮЧА НЕ ДОЛЖНО УЖЕ СУЩЕСТВОВАТЬ: если идентификатор отсутствует из вставки в этом случае, вы получите ошибку " явное значение должно быть указано для столбца идентификатора таблица. ". Если значение первичного ключа уже существует в базе данных, вы получите следующую ошибку "нарушение ограничения первичного ключа . Не удается вставить дубликат ключа в объект"

вывод базы данных таблицы [dbo].[Лица] будут:

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

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

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

В-третьих, запрос по мере его отправки в базу данных может создавать две записи. Чтобы определить, так ли это, запустите Profiler, чтобы увидеть, какой именно код SQL вы отправляете, и если ti является select вместо предложения values, затем запустите select и посмотрите, есть ли у вас из-за соединений, полученных некоторые записи должны быть продублированы. В любом случае, даже когда вы создаете код на лету, как это первый шаг по устранению неполадок всегда запустить Profiler и посмотреть, если то, что было отправлено, было то, что вы ожидали быть отправлены.

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

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

Он работает правильно, но также выводит следующую ошибку 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, а значение - это идентификатор, который вы потенциально собираетесь вставить:

Я несколько недель боролся с моим приложением WPF под названием «ContactManager», когда я хочу добавить записи в базу данных. У меня есть два объекта:

Когда база данных пуста, она работает, но после закрытия и перезапуска приложения я получаю следующее исключение:

SqlException: нарушение ограничения PRIMARY KEY «PK_dbo.Addresses». Невозможно вставить повторяющийся ключ в объект 'dbo.Addresses'. Повторяющееся значение ключа - (1). Заявление было прекращено.

Я не понимаю, почему сервер Sql (или структура сущности ??) хочет вставить ключ 1 вместо следующего идентификатора .

Если я удаляю строки в таблице Адреса, он снова работает, он без проблем вставляет строку со следующим / правым addressid. (то есть addressid не 1, а 5 из-за предыдущих строк контактов)

На мой взгляд, схема таблиц (ключей и т. Д.) Верна, проблема связана с другой проблемой, возможно, привязкой или контекстом, я не понял .

(Я сделал более простой пример, опуская MVC, он работает.)

Вот код приложения MVC:

2 ответа

Спасибо за ответы, но я нашел проблему:

В конструкторе ContactRepository после вызова GetAll () мне нужно удалить текущий контекст:

И все работает нормально. я не знаю, есть ли лучшее решение вместо непрерывного вызова Context.Dispose () или это правильный путь?

Вероятно, это ваша проблема:

Вместе с этим вы удаляете свой DbContext после сохранения. Когда EF DbContext встречает новую сущность (контакт) со связанной сущностью, которая, как вы ожидаете, существует, но не отслеживается, он будет рассматривать эту сущность как новую сущность. Такое поведение, вероятно, является корнем того, что мешает вам перемещаться по объектам. Адрес больше не отслеживается, поэтому предпринимается попытка повторно вставить существующую адресную запись, и, поскольку это FK, указывающий на Контакт, он не будет генерировать новое значение, а попытается использовать текущий идентификатор контакта.

Обычно Address должен иметь PK (AddressID) и FK (ContactId), если у вашего контакта может быть несколько адресов. Либо это, либо контактный объект будет иметь AddressID. (Если один адрес может обслуживать несколько контактов) Если вы хотите, чтобы у одного контакта был только один адрес, либо поместите поля адреса в сам контакт, либо создайте таблицу ContactAddressDetails с ContactId в качестве PK + FK для HasRequired / WithRequired , если вы хотите, чтобы это было в отдельной таблице. Желаемые отношения будут определять, как будут выглядеть поля объекта / схемы.

Добрый день!
При считывании конф из пульта в базу данных Орион про 1,20,3 выходит ошибка.

(Ошибка в работе приложения: Не удается вставить повторяющуюся стороку ключа в объект "dbo.Devltems" с уникальным индексом "lbx_Devltems_DeviceID". Повторяющееся значение ключа: (37, 276, 3)

Подскажите, как быть?

1 год 4 месяца назад

avatar

Фархутдинов Сергей Валентинович

пишите письмо в техподдержку и скрин ошибки приложите, т.к. 100% попросят, пускай разработчики голову чешут

а возможно и файл конфига глючного

– Волков Андрей 1 год 4 месяца назад

Спасибо.
Я до сих пор от них жду ответа по вопросу о АСПТ+КПБ планы помещений

– Фархутдинов Сергей Валентинович 1 год 4 месяца назад

Сергей Валентинович, попробуйте сохранить конфигурацию пульта сперва в файл, а потом загрузить в АБД из файла. Так удобнее.

– Колобов Сергей Владимирович 1 год 4 месяца назад

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

– Фархутдинов Сергей Валентинович 1 год 4 месяца назад

Попробуйте удалить ППРог с компа который установился вместе с орионом и установить свежую версию Ппрог у меня так один раз было ,на орионе версия 1.20.2

– Ахтямов Михаил Владимирович 1 год 4 месяца назад

А вы можете сам файл конфигурации выложить? Попробую считать в АБД, если пройдет, то ответом уже бэкап базы пришлю. У меня 1.20.3 sp3 SQL2012.

– Тремасов Константин Александрович 1 год 4 месяца назад

Да, только я сегодня уже уехал с объекта. Завтра обязательно прикреплю. Не сильно правда понял как в этом окне это сделать.

– Фархутдинов Сергей Валентинович 1 год 4 месяца назад

– Тремасов Константин Александрович 1 год 4 месяца назад

Хорошо. Спасибо за пояснения. А то везде суют "справку" где она не сильно и нужна, а тут нет

– Фархутдинов Сергей Валентинович 1 год 4 месяца назад

Добрый день всем.
Константин Александрович, поршу прощения за "оперативность", Другой объект отнял неделю. Да и день города подарил три выходных. "Пир во время чумы". Вернемся к проблемам.
Конф пульта. – Фархутдинов Сергей Валентинович 1 год 4 месяца назад Все вообще без проблем загрузилось, ни одной ошибки не возникло – Тремасов Константин Александрович 1 год 4 месяца назад

– Тремасов Константин Александрович 1 год 4 месяца назад

Ваш номер телефона будет доступен только администраторам сайта.

Спасибо за понимание.

ПОКАЗАН

ЗАДАН

1 год 4 месяца назад

ПРОДУКТЫ

По каждому вопросу/ответу можно добавлять комментарии. Комментарии предназначены для уточнения вопроса/ответа.


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. Так как первое и второе значение будет содержаться во многих строках в таблице, нам нужно будет третье уникальное значение, по которому будет происходить поиск для удаления. Сумма нам может в этом помочь, т.к. значение суммы может совпадать с суммой сбойного документа.

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

Related Posts

12 Comments

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

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

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

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

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

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