При обновлении типовых конфигураций, таких как 1С:Бухгалтерия предприятия 3.0, Зарплата и управление персоналом 3.1 или 1С:Розница, пользователи часто сталкиваются с критической ошибкой, которая останавливает процесс выполнения обработчиков обновления. Текст ошибки обычно выглядит так: Запись с такими ключевыми полями существует! : ОбработчикиОбновления: [ИмяОбработчика] (Регистр сведений: Обработчики обновления). Давайте разберем причины возникновения этой ситуации и рассмотрим пошаговые методы её решения.
Проанализируем техническую сторону вопроса. Современные конфигурации 1С построены на базе Библиотеки стандартных подсистем (БСП). Когда мы запускаем программу после обновления конфигурации в Конфигураторе, система начинает заполнять служебный регистр сведений ОбработчикиОбновления. В этот регистр записываются все процедуры, которые должны трансформировать данные из старого формата в новый для каждой версии программы.
Рассмотрим ситуацию: если вы «перепрыгиваете» через несколько релизов (например, обновляете базу с версии 3.0.69 сразу до 3.0.87), система пытается составить список всех необходимых обработчиков для всех промежуточных версий. Ошибка возникает в тот момент, когда в коде разных версий библиотек (например, основной конфигурации и встроенных в неё подсистем) встречаются обработчики с идентичными именами и номерами версий. Система пытается записать две одинаковые строки в регистр, который имеет уникальный ключ, и выдает отказ.
Также часто причиной становится некорректное «накатывание» файла конфигурации .cf без промежуточных запусков в режиме 1С:Предприятие. В этом случае данные в базе остаются старыми, а метаданные — новыми, что запутывает механизмы БСП.
Самый быстрый и эффективный способ, предложенный сообществом, — это применение специального расширения, которое принудительно «вырезает» дублирующиеся записи из списка обработчиков в момент его формирования. Посмотрим, как его применить:
.cfe).Проанализируем, что делать после успешного входа. После того как все обработчики завершат работу, расширение можно (и нужно) удалить, так как оно выполнило свою временную функцию по «пробиванию» затора в обновлении.
Если у вас Базовая версия программы, расширения в ней не поддерживаются. В этом случае нам потребуется «напильник». Разберем алгоритм действий:
Поскольку мы не можем добавить код, нам нужно очистить существующие записи, которые вызывают конфликт. Рассмотрим использование внешней обработки или программного кода. Если у вас есть возможность запустить консоль кода или внешнюю обработку, можно выполнить следующий скрипт для очистки проблемного регистра:
Набор = РегистрыСведений.ОбработчикиОбновления.СоздатьНаборЗаписей();
// Можно установить фильтр по конкретному имени обработчика, если ошибка точечная
// Набор.Отбор.ИмяОбработчика.Установить("РасчетЗарплатыДляНебольшихОрганизаций.ЗаполнитьУдержаноОтпусковИБольничных");
Набор.Записать();
ИнформационнаяОтладка = "Регистр очищен, пробуем запустить обновление снова";
После очистки регистра система при старте попытается сформировать список заново. Часто этого достаточно, чтобы ошибка исчезла. Для ручного вызова нужных процедур БСП можно использовать обработку для запуска процедур обновления.
Иногда ошибка при обновлении связана не с дублями, а с обращением к удаленным объектам. Рассмотрим ситуацию из сообщения 47: при обновлении Розницы код пытается обратиться к полю УдалитьСправка1, которое уже физически удалено из метаданных. Это происходит из-за слишком большого «прыжка» между релизами.
Разберем, как это исправить через Конфигуратор (только для ПРОФ версий):
ОбновлениеИнформационнойБазыРТ).ЗаполнитьСправкиБ).
// Фрагмент кода до правки
// ТекстЗапроса = "ВЫБРАТЬ ТТН.УдалитьСправка1 ИЗ ...";
// Фрагмент после правки (комментируем обращение к УдалитьСправка1)
ТекстЗапроса = "ВЫБРАТЬ ЗНАЧЕНИЕ(Справочник.Справки1ЕГАИС.ПустаяСсылка) КАК Справка1 ИЗ ...";
Выясним, как избежать подобных трехдневных ожиданий и ошибок. Опыт показывает, что наиболее надежный способ обновления сильно устаревших баз — это последовательное обновление.
Проанализируем основные правила:
.cf файл последнего релиза кажется быстрым, но оно пропускает логику трансформации данных. Используйте файлы обновлений .cfu.Тестирование и исправление в Конфигураторе. Поставьте галочки «Проверка логической целостности» и «Реиндексация таблиц». Это поможет избежать ошибок на уровне СУБД.%LOCALAPPDATA%\1C\1cv8.Если вы всё же решили рискнуть и обновить базу сразу на много релизов, всегда делайте архивную копию (выгрузку .dt или копию файла 1cv8.1cd). Как мы увидели из обсуждения, иногда автоматическое обновление в режиме Предприятия работает стабильнее, чем ручное в Конфигураторе, так как оно само контролирует последовательность шагов и запуск фоновых заданий. Для прямого перехода между удаленными версиями можно использовать инструмент для обновления устаревших версий БП 3.0.
В случае, если после всех манипуляций вы получаете ошибку «Преобразование значения к типу Дата не может быть выполнено», это может быть багом конкретного релиза (например, 3.0.75-3.0.77). Посмотрите на сообщение 11: применение патча или перепроведение документов выплаты зарплаты после завершения всех обработчиков обычно решает этот вопрос.