Ошибка "Violation of PRIMARY KEY constraint … Cannot insert duplicate key in object"

При работе в 1С на SQL может появиться ошибка "Violation of PRIMARY KEY constraint … Cannot insert duplicate key in object".
Сегодня попытаемся понять, почему она возникла и как ее устранить!

Предыстория:

Никого не удивлю, типичный случай. Приходит бухгалтер и сообщает, что хотела провести документ в 1С 7.7, но он выпадает в ошибку.

Начал разбираться, прошелся отладчиком в копии по коду. Причину сразу не нашел, до конца кода отладку не провел и решил нажать F5, чтобы продолжить работу в базе. Документ провелся. Но я решил отменить проведение и повторно провести его. И вот тут вылетела ошибка «Violation of PRIMARY KEY constraint ‘PK_RA17286’. Cannot insert duplicate key in object ‘RA17286’.» Естественно, это только частный случай, как эта ошибка может возникнуть, но ее решение подойдет для каждого!

 

Решение:

Данная ошибка в моем случае связана с тем, что в SQL есть движение документа, но документ не проведен. В момент его проведения должна создаться запись в регистре, но она уже есть!

Я нашел два решения:

1. Простой, но долгий.

2. Сложный, но быстрый. 

Решение 1.

Зайти в конфигуратор и нажать ТиИ (Тестирование и исправление ИБ). В моем случае база весит ~ 16 гигабайт. ТиИ работало на тестовом сервере ~ 24 часа. Думаю, время решение такой ошибки не устроит вас! Но если у вас есть время или нет в штате опытного программиста, то можете выбрать этот вариант решения вопроса!

Решение 2.

У нас 1С 7.7 стоит на MS SQL Server 2000. Копия базы также развернута на SQL. 

Итак, что нам понадобится:

1. Файл «1Cv7.DDS», который лежит в каталоге базы 1с 7.7.

2. Имя документа из конфигуратора.

3. Доступ в SQL.

Откроем файл «1Cv7.DDS» (я использую просмотр по F3 в тоталкомандере). Найдем строку с именем документа. Вы увидите таблицу и в колонке «Name» или «SQLTableNam» будет написано название таблицы в SQL (в моем случае это было «DH17245»). Заходим в «Enterprise Manager» нашего SQL. Находим нашу базу и ищем в ней таблицу с нужным названием (я искал «DH17245»). Когда нашли таблицу с таким именем, то кликаем по таблице ПКМ «Открыть таблицу» (Open table) -> «Вернуть все строки» (Return all rows). Там ищем запись по вашему документу. Мне удалось его легко найти, документ был один в нужном периоде. Нашли запись и запомнили его IDDOC (у меня было «KLMN»). Теперь ищем таблицу, которая вывалилась в ошибке (у меня «RA17286»). Аналогично открываем таблицу с ошибкой (моя таблица «RA17286») и находим запись на нужный документ (мой документ «KLMN»). Удалим запись ПКМ по строке нажать Delete -> Yes. 

Все, теперь ошибка при проведении возникать перестанет!

 

Итог:

Важно! Я четко знал, какой документ был сбойный. У меня была копия базы для экспериментов! Повторять только на копии!

24 Comments

  1. CheBurator

    Не описано действительно нужное — 1. причина почему такая ошибка появилась 2. как избежать появления такой ошибки.

    Reply
  2. alyaev.a.v

    Даже если сбойный док 1, то вариант так себе. Потом бух найдет еще один, потом еще и понеслась…

    ТИИ избавляет сразу от ВСЕХ таких кривых доков/записей.

    Да и не безопасно все это.

    Reply
  3. Xershi

    (1) CheBurator, моя причина описана в предыстории. Ваша может быть совсем другой!

    (2) alyaev.a.v, я привел 2 варианта! Можете предложить третий? Не забываем читать ИТОГ!

    Reply
  4. alyaev.a.v

    (3) Ок, знали док это хорошо, сейчас есть уверенность что таких кривых доков больше нет?

    Reply
  5. Xershi

    (4) alyaev.a.v, конечно! Код отлажен, ТиИ сделано!

    Reply
  6. alyaev.a.v

    (5) Если ТИИ сделано, тогда вообще не пойму зачем вариант 2 ???

    Вариант 2 никакого отношения к проблеме не имеет получается, описание как найти по структуре базы таблицу в скуле и удалить запись.

    Reply
  7. Xershi

    (6) alyaev.a.v, потому что у меня 2 копии базы. На одной запустил ТиИ. На второй сделал удаление.

    А на рабочей базе повторил второй вариант. Согласись запустить ТиИ на рабочей базе на 24 часа не вариант!

    Reply
  8. shmellevich

    (1)

    1. причина — нагрузка на SQL базу при большом количестве пользователей, особенно когда они работают с одним видом документов, и главная причина платформа 1С 7.7 и архитектура хранения документов в базе данных.

    2. как избежать появления такой ошибки. — по своему опыту скажу подобные ошибки возникают настолько редко, что их даже воспроизвести не получится, у меня из 13 баз идентичных такие ошибки встречались за 3 года всего 2 или 3 раза, при этом размеры баз 10-ки ГБ.

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

    Reply
  9. alyaev.a.v

    (7) Не соглашусь.

    Как временный вариант, чтобы дотянуть до выходных и сделать ТИИ подходит.

    Но оставить так базу…Я бы сделал ТИИ и не парился бы.

    Ну как говорится это решает специалист, повторюсь если есть уверенность что больше нет косяков, то почему и нет.

    Reply
  10. CheBurator

    (3) «Данная ошибка в моем случае связана с тем, что в SQL есть движение документа, но документ не проведен»

    — это не ошибка. Это следствие ошибки. Штатными вариантами действий добиться такой ситуации — навскидку не представляю.

    Reply
  11. CheBurator

    (8) спсб за поснения. Но причина — так и осталась невыясненной… 😉

    Reply
  12. Xershi

    (11) CheBurator, еще раз повторяю как получить такую ошибку: в моем случае в документе была ошибка и документ не проводился. Я решил пройти отладчиком, шел через ф8. До конца кода не дошел и нажал ф5. Документ провелся без ошибки! Но не должен был проводиться, а выйти в ошибку. Но он провелся, конечно не корректно. И после отмены проведения и повторного проведения возникает ошибка. Я думаю это баг платформы.

    Reply
  13. CheBurator

    (12) фигня какая-то…

    > Документ провелся без ошибки! Но не должен был проводиться, а выйти в ошибку. Но он провелся, конечно не корректно.

    — тем не менее провелся. штатно. с записью движений в регистр. ПРОБЛЕМ НЕ ВИЖУ.

    > И после отмены проведения и повторного проведения возникает ошибка.

    — отмену проведения штатно делали? повторное проведение выполнилось нормально (провелось с записью движений)? или не провелось с выдачей штатного сообщения? Дополнительным кодом с использованием транзакций — игрались?

    .

    Такая ошибка воспроизводится устойчиво? если да — просьба записать коротенькое видео.

    Reply
  14. Xershi

    (13) CheBurator, вы статью прочитайте!!!

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

    Reply
  15. MadDAD

    (12) может в табло в отладчике было что-то хитрое?

    Вообще вот нашел методику — http://www.klerk.ru/print/1996 по аналогии можно и с регистрами.

    Reply
  16. Xershi

    (15) MadDAD, ничего хитрого не было, вы же уже читали первоисточник http://forum.infostart.ru/forum9/topic136472/. Ссылка ваша хорошая, только сложно это переварить, если не работать со скулем.

    Reply
  17. CheBurator

    (14) а что такого ХИТРОГО было в коде, что приводило к появлению ошибки?

    то что документ провелся (хотя по вашему замыслу не должен был проводиться) — это штатное поведение.

    то что документ отменили проведение — это штатная возможность

    то что потом документ повторно провели (успешно или неуспешно) — это штатная возможность.

    здесь ничего косячить не должно.

    а вот то, что поправили код и внезапно у непроведенного документа не стало движений как и должно быть (а раньше были) — вот это и напрягает…

    может вы там хитро с транзакциями баловались.. или прямые запросы юзаете…

    Reply
  18. Xershi

    (17) CheBurator, вот именно

    то что потом документ повторно провели (успешно или неуспешно) — это штатная возможность.

    Он выпал в ошибку. Решение указал выше.

    Прочтите (16).

    Без удаления записи в скуле документ при проведении вывалился с ошибкой на скуле.

    С удалением записи в скуле документ при проведении вылетает на ошибке кода в 1с.

    После удаления и правки кода документ провелся нормально.

    Reply
  19. vasyak319

    Вы удаляете движение из таблицы регистра. А что у вас при этом с итогами?

    Reply
  20. CheBurator

    (18) он выпал в ошибку (скуль отрапортовал и это вообщем неинтересно) потому что до этого была ошибочная ситуация: документ не проведен, но движения присутствуют — а вот это интересно как именно этого добились…. и какой именно код (исходный, приводящий устойчиво к скульной ошибке ) поменяли, что теперь цепочка операций «проведение-распроведение-повторное проведение» отрабатывает нормально как и должно?

    ответа на вопросы чуть выше вообщем так и не было: — игрались с транзакциями при проведении/распроведении доков? прямые запросы использовали в проведении/распроведении? использовали отмену проведения путем модификации прямыми запросами признака проведения документа? до возникновения ошибочной ситуации — про которую написал скуль — модифицировали что либо в таблицах регистров прямыми запросами или непосредственно в самом скуле?

    Reply
  21. Xershi

    (20) CheBurator, если бы вы прочли все внимательно, то вопрос бы не возник. По коду как я понял: делалась проводка, но в счете дебета использовался старый план счетов(до 2012,а сейчас используем новый), из-за этого он не подставлялся в проводку. В этом была ошибка кода, после правки счет берется из нового плана счетов. Когда удалил запись, то и проблемы не стало!

    Reply
  22. CheBurator

    А при чем здесь ПРОВОДКИ и наличие движений ПО РЕГИСТРУ у непроведенного документа…?

    Reply
  23. Xershi

    (22) CheBurator, для этого написана статья.

    Reply
  24. _Z1

    (8) Это не причина.

    sql держит любую нагрузку.

    Как бы принцип транзакции или все сделано или все откатили.

    Поддержу Cheburator прав на все 100%

    Reply

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *