Попытка вставки неуникального значения в уникальный индекс:
Microsoft SQL Server Native Client 11.0: Выполнение инструкции CREATE UNIQUE INDEX прервано, поскольку обнаружен повторяющийся ключ для объекта с именем «dbo._InfoRg22530» и индекса с именем «_InfoRg22530_ByPeriod». Повторяющееся значение ключа: (0, 3900-01-01 00:00:00, 0x9100fa815581b9604de110ca98afc344, 0x00000000000000000000000000000000).
HRESULT=80040E2F, SQLSrvr: SQLSTATE=23000, state=1, Severity=10, native=1505, line=1
Ошибка возникает, если в базе есть у каких-то объектов, реквизитов, субконто — значение NULL, а у них такого значения быть не может. И появляется такая ошибка только в SQL базах. Т.е. если такую базу выгрузить в файловую, то там уже этой ошибки не будет. Т.к. у файловой базы свои таблицы (всего 4 шт.), а у SQL свои. И SQL база критично реагирует на такие значения в своих таблицах.
Эта проблема не решается никакими тестированиями (ни внешним, ни внутренним) ни в каких вариантах баз (SQL или файловая) и даже Процедурой _1sp_DBReindex в менеджере SQL, которая вроде как должна проводить реструктуризацию таблиц в SQL.
Разберём решение проблемы на примере перехода с Бухгалтерии 3.0 ПРОФ на КОРП. После перехода у счёта 68.01 появляется новое субконто РегистрацияВНалоговомОргане. И тогда, в базах на SQL, все создание в ПРОФ версии документы которые используют этот счёт, не будут перепроводится. Будет выходить выше показанная ошибка. Т.к. это новое субконто у старых документов, в проводках, запишется со значением NULL (хотя должно быть Пустое значение, ну или как-нибудь налоговый орган).
Чтобы устранить эту ошибку, нужно убрать значения NULL там, где их не должно быть. В данном случае в документах, где используется субконто РегистрацияВНалоговомОргане. Сделать это можно, написав обработку, которая заменит NULL на Пустое значение (готовую обработку можно скачать из этой статьи). Делать обработкой, т.к. попытка изменить значение этого субконто в проводках документа вручную, приводит к всё той же ошибке.
Обработку для замены NULL’ов во всех субконтах РегистрацияВНалоговомОргане можно скачать из этой статьи, внизу.
.НО так заменить NULL в SQL базе не получится, во время выполнения обработки будет выдана та же самая ошибка. Поэтому необходимо сделать так:
1. Выгрузить уже рабочую, переведённую на КОРП версию, SQL базу в dt’шник (в конфигураторе Администрирование – Выгрузить базу – выберите куда выгрузить базу в виде файла *.dt)
2. Загрузить dt’шник в файловую базу (в ненужной или заранее подготовленной, чистой, файловой базе, в конфигураторе Администрирование – Загрузить базу – выбрать выгруженный ранее dt’шник)
3. Выполнить обработку в файловой базе (там ошибки не будет и все NULL’ы корректно заменяться) (как выполнить обработку описано ниже)
4. Выполнить внешнее и внутреннее тестирование базы. Это обязательно нужно сделать иначе при загрузке базы обратно в SQL будет выходить та же ошибка. (как выполнить эти тестирования можно посмотреть тут: http://kb.stspp.ru/software/inner_and_outer_1c_testing)
5. Теперь наоборот выгрузить dt’шник из файловой базы и загрузить его в SQL базу. Теперь при проведении обработанных документов ошибки выходить не будет.
Обработка из этой статьи находит все документы, за указанный период, у которых в проводках фигурирует субконтно РегистрацияВНалоговомОргане (которое появляется в КОРП версии), у которого значение NULL. И заменяет это значение на Пустое значение.
В обработке необходимо указать период, за который необходимо обработать документы (можно за весь период в котором ведётся учёт в базе) и нажать «Заполнить табличную часть». После чего можно галками пометить какие документы обработать (можно выбрать все) и нажать кнопку «Выполнить обработку».
Соответственно если у кого-то такая же ошибка, но НЕ после перехода на КОРП, а на пример после обмена, загрузки каких-то данных, выполнения каких-то обработок и т.д. То необходимо выявить, где присвоилось значение NULL в конкретном документе/справочнике и подобным способом убрать этот NULL но уже своей обработкой, но в том порядке, как описано выше. Помните, что NULL может быть, как в проводках документа, в т.ч. не только бухгалтерских, так и где-нибудь на форме документа/справочника, в каком-нибудь реквизите, но в таком случае он наверно даже не откроется.
Также если это ошибка появилась у вас при проведении документа, после того как вы перевели файловую базу Бух КОРП на SQL (а база когда-то изначально была ПРОФ), то значит у тех документов что были созданы в ПРОФ версии, сейчас также в субконто РегистрацияВНалоговомОргане значение NULL и SQL база такое не приемлет. И при загрузке базы в SQL будет выходить такая ошибка. Тут на самом деле в файловой базе значений NULL по факту не будет, но SQL в свои таблицы загрузит именно такие значения. Поэтому тут надо заставить базу SQL создать эти NULL’ы и потом в файловой базе их исправить. Но как это сделать, уже не подскажу.
Все это очень легко исправить через SQL Server Management Studio
Просто находим таблицу на которую ругается 1С, и удаляем индекс
(1)
Просто находим таблицу на которую ругается 1С, и удаляем индекс
После реструктуризации таблицы регистра опять получим такую же ошибку.
Аналогичную проблему получил при включении среза последних для таблицы регистра сведений. Реквизит регистра сведений был индексируемым, после создания физической таблицы среза последних платформа создала индекс для этого реквизита в таблице среза последних, но при вставке данных в таблицу получаем сообщение об ошибке о не уникальном значении.
Индекс можно удалить в SSMS, но после реструктуризации этой таблицы индекс снова будет создан и при вставке значений в таблицу получим ошибку.
В итоге, индекс для реквизита пришлось отключить в платформе (аналогичный индекс можно уже создать вручную).
А если база больше 150 Гб ? каким образом вы ее в файловую выгрузите?
Обнаружили аналогичную ошибку. При обновлении бухгалтерии на 3.0.60.44 релиз создал операции создающими ошибку описанную в статье.
(3) на копии отключайте индекс , обновляйте, анализируйте причину дублирования , что бы не повторялось.
удаляете или сворачиваете «лишние» данные в таблицах, престраиваете индекс. воспроизводите на рабочей базе.
+(3) создание индекса 1с отключите с помощью ddl триггера
сделал попроще… поставил в SQL пропуск повторных значений -> обновил -> провел манипуляции -> убрал в SQL пропуск пустых значений…
Дело тут в другом
У меня несколько баз с разным объемом до 200 Гб
3 базы полностью штатные и ведутся не более 3-х лет. (чистая поддержка)
Почему я должен на платной поддержке и купленной программе получать такие болты при обновлении?
Почему я должен искать неуникальные записи и проводить с ними какие либо действия?
Техподдержка в 1С похожа на твердолобых бюрократов, а не на техподдержку своего продукта…
В 3-й раз убеждаюсь что от техподдержки компании Нуралиева — толку ноль — он может ее распустить и пополнить свой карман…
Вместо того, чтобы создать нормальный инструмент по избитой теме «неуникальное значение в уникальный индекс» пользователи раз от разу огребают на ровном месте.
В моем случае, неуникальное значение было создано предыдущим обновлением 1С, а последствия дурного обновления были замечены через месяц.
Почему пользователь должен исправлять ошибки программистов 1С — т.к. техподдержка в 1С убогая и неработоспособная?
Решение проблемы гораздо проще:
1.Выключить использование итогов. В режиме Предприятия перейти: Администрирование — Обслуживание — Регламентные операции — Управление итогами и агрегатами, нажать ссылку Полные возможности, найти в списке «Журнал проводок (бухгалтерский и налоговый учет) (регистр бухгалтерии)» и установить на него курсор, в командной панели выбрать команду «Итоги — Выключить использование итогов».
2. Перезаписать интерактивно документы с ошибками.
3. Включить использование итогов (см. п. 1, только выполнить команду «Итоги — Включить использование итогов»).
Словил эту проблему при переходе на корп. В sql не загрузился dt. Обработка ни одного документа не нашла.
(8) публикация помогла ?
(9) Нет. «Заполнить документы» не нашла ни одного документа, соответственно исправлять ей было нечего
(10) пробуйте (5)+(4)
(8) 7 пробовали, помогло?
(12) Мне неизвестны документы с ошибками, чтобы перепровести их интерактивно, соответственно искалась обработка, которая сделает это за меня. Времени на решение проблемы много не предоставили, клиента устроил вариант с файловой базой.
(7) Отключение итогов помогло, за что большое спасибо! И своя обработка, которая заменила NULL непосредственно в проводках, потому что проводить документы не хотелось.
(7)класс!
(6)
Где в скл устанавливается пропуск повторных значений? База у меня огромная, все остальные способы не подходят. Заранее спасибо.