При переходе на новые релизы конфигурации 1С:Бухгалтерия предприятия 3.0 (начиная с ветки 3.0.167 и выше) многие специалисты сталкиваются с критической ошибкой на этапе реструктуризации базы данных. Проблема проявляется в невозможности завершить обновление из-за нарушения уникальности индексов в таблицах журналов документов. Рассмотрим детально, почему это происходит и как привести базу в рабочее состояние.
Типичная ситуация: при обновлении в клиент-серверном варианте (SQL) процесс прерывается сообщением следующего содержания:
"Microsoft SQL Server Native Client 11.0: Выполнение инструкции CREATE UNIQUE INDEX прервано, поскольку обнаружен повторяющийся ключ для объекта с именем 'dbo._DocumentJournal6982' и индекса с именем '_DocumentJournal6982_1'"
Проанализируем это сообщение. Имя таблицы _DocumentJournal6982 (номер может отличаться) соответствует системной таблице Журнала операций. Ошибка означает, что в базе данных появились записи с абсолютно одинаковыми ключевыми полями (обычно это комбинация даты, ссылки на документ и разделителей), что недопустимо для уникального индекса. Чаще всего "виновниками" становятся документы типа Регламентная операция.
Прежде чем приступать к лечению, нам необходимо убедиться в наличии дублей и определить их масштаб. Для этого воспользуемся механизмом консоли запросов. Рассмотрим следующий алгоритм поиска дублирующихся записей непосредственно в журнале операций:
ВЫБРАТЬ
Подзапрос.Дата КАК Дата,
Подзапрос.Ссылка КАК Ссылка,
СУММА(Подзапрос.КоличествоЗаписей) КАК КоличествоЗаписей
ИЗ
(ВЫБРАТЬ
ЖурналОпераций.Дата КАК Дата,
ЖурналОпераций.Ссылка КАК Ссылка,
1 КАК КоличествоЗаписей
ИЗ
ЖурналДокументов.ЖурналОпераций КАК ЖурналОпераций) КАК Подзапрос
СГРУППИРОВАТЬ ПО
Подзапрос.Дата,
Подзапрос.Ссылка
ИМЕЮЩИЕ
СУММА(Подзапрос.КоличествоЗаписей) > 1
Если данный запрос возвращает список документов, значит, в логической структуре журнала действительно присутствуют дублирующие ссылки. Это подтверждает, что проблема не в физической поломке индекса SQL, а в некорректных данных внутри таблиц 1С.
Разберем основные причины, которые приводят к такому состоянию базы при обновлении на релизы 3.0.167 – 3.0.173:
РегистрБухгалтерии поддерживает корреспонденцию. При обновлении алгоритмы пересчета итогов или перегенерации записей журнала могут сбоить, если документ Регламентная операция формирует специфические проводки.Как показывает практика, обычное отключение расширений помогает редко. Необходимо выполнить процедуру "жесткой" очистки метаданных. Рассмотрим пошагово, как это сделать:
Администрирование — Расширения. Нам нужно не просто снять галочку "Активно", а полностью удалить все расширения из списка, используя штатные функции или специальное удаление расширений списком.Администрирование — Тестирование и исправление.dbo._DocumentJournal.Если ошибка CREATE UNIQUE INDEX в SQL не позволяет даже запустить ТиИ, проанализируем ситуацию в файловом варианте:
Выгрузим базу в файл .dt и развернем её локально. Файловая версия базы данных более "терпима" к дублям индексов на этапе загрузки. После того как база развернута в файле, выполним Тестирование и исправление с включенной Реструктуризацией. После успешного завершения ТиИ и удаления дублей (проверяем запросом из Шага 1), загрузим базу обратно на SQL-сервер.
Если предыдущие шаги не помогли, воспользуемся методом временного исключения объектов из состава журнала:
Регламентная операция и снимем галочку его участия в журнале.Регламентная операция обратно в состав журнала.Резюме: Основной причиной проблемы является конфликт механизма расширений и масштабной реструктуризации журналов в новых релизах БП 3.0. Совместное использование удаления расширений и глубокого ТиИ позволяет полностью устранить ошибку и успешно завершить обновление программы.