Переход с конфигурации 1С:Управление торговлей 11.3 на версию 11.4 является одной из самых трудоемких процедур обновления. Это связано не только с изменением интерфейса, но и с глубокой реструктуризацией данных, обновлением Библиотеки стандартных подсистем (БСП) и изменением механизмов хранения цен. Часто технические специалисты сталкиваются с тем, что стандартный процесс обновления прерывается критическими ошибками. Разберем по шагам основные причины этих проблем и способы их «лечения».
Первая и самая коварная причина сбоев при переходе на УТ 11.4 — это использование определенных версий платформы 1С:Предприятие 8.3. Рассмотрим ситуацию: при выполнении обновления система выдает ошибку, а в журнале регистрации фиксируется некорректное состояние константы СведенияОбОбновлении. В процессе отладки выясняется, что вместо ожидаемой структуры или соответствия в константе хранится значение Неопределено.
Проанализируем причины этого поведения. В версиях платформы 8.3.13.1513 (и некоторых соседних релизах ветки 8.3.13) был зафиксирован баг, связанный с некорректной десериализацией объектов из хранилища значений. Поскольку БСП активно использует хранилища для записи состояния обработчиков обновления, ошибка платформы приводит к тому, что конфигурация «теряет» информацию о том, на каком этапе она находится. Это вызывает цикличные ошибки или аварийное завершение работы.
Решение: Как показывает практика, наиболее стабильным вариантом для выполнения самого процесса перехода является откат на проверенные версии платформы, например, 8.3.11.3133 или 8.3.12.1855. Также можно использовать более поздние сборки, такие как 8.3.13.1644 и выше, где данные ошибки были исправлены. После завершения всех процедур обновления платформу можно будет снова повысить до актуальной.
Вторая распространенная проблема — ошибка СУБД duplicate key value violates unique constraint. Рассмотрим пример сообщения, которое часто возникает при работе на PostgreSQL:
ERROR: duplicate key value violates unique constraint "_inforgs25935_bydims"
Эта ошибка указывает на то, что система пытается записать в регистр сведений запись с набором измерений, который уже существует. В УТ 11.4 была значительно усилена проверка уникальности данных в регистре ЦеныНоменклатурыПоставщиков. Выясним, почему это происходит:
Поставщик, Номенклатура и Вид цены.Для исправления ситуации выполним следующие действия:
Во-первых, перед началом обновления запустим Тестирование и исправление (ТИИ) с включенными опциями проверки логической и ссылочной целостности. Однако ТИИ не всегда находит физические дубли в PostgreSQL или MS SQL. Если ошибка повторяется, необходимо выявить дублирующиеся записи с помощью консоли запросов, ориентируясь на поля, указанные в ошибке СУБД (например, _fld706, _fld20062rref и т.д.).
Рассмотрим вариант радикального решения, если данных в регистре слишком много и ручная чистка невозможна: полная очистка регистра перед обновлением. Это допустимо, если цены поставщиков можно пересчитать или загрузить заново после перехода. Для этого можно использовать простой код в обработке:
Набор = РегистрыСведений.ЦеныНоменклатурыПоставщиков.СоздатьНаборЗаписей();
Набор.Записать();
После очистки регистра процедура обновления должна пройти без блокировок со стороны СУБД.
Многие специалисты задаются вопросом: очищается ли константа СведенияОбОбновлении самостоятельно? Проанализируем этот механизм. Данная константа хранит сложную структуру данных о каждом выполненном и отложенном обработчике. Если во время обновления произошел сбой, запись в константе может «зависнуть» в статусе «Ошибка» или «Выполняется».
При повторном запуске обновления система считывает эти данные. Если в них содержится «шлак» (некорректные данные из-за ошибки платформы), обновление не продолжится. В таких случаях мы можем программно вмешаться в процесс. Рассмотрим пример того, как можно сбросить состояние обновления, если стандартные методы не помогают:
// Пример программного сброса сведений об обновлении (использовать с осторожностью!)
Константы.СведенияОбОбновленииПрограммы.Установить(Неопределено);
ПараметрыСеанса.ИнформационнаяБазаОбновлена = Ложь;
Однако помните, что после такой очистки система может попытаться запустить все обработчики с самого начала, что на базе объемом 50 Гб и выше может занять десятки часов.
Официально 1С разрешает переход с версии 11.3.4.228 сразу на актуальные релизы 11.4.5.х или 11.4.6.х. Но на практике мы часто видим, что «прыжок» через много релизов вызывает ошибки в данных. Рассмотрим два подхода:
.cf файла. Это экономит время на сравнении/объединении конфигураций, но создает огромную нагрузку на систему при первом запуске, так как БСП придется выполнить сотни обработчиков за один раз.Если ваша база имеет доработки, мы рекомендуем сначала подготовить чистый .cf файл объединенной конфигурации последнего релиза, а затем накатывать его на копию базы. Если возникают ошибки в фоновых заданиях, разберем, как ими управлять. В интерфейсе 1С перейдем в Администрирование — Обслуживание — Результаты обновления программы. Здесь можно увидеть список всех отложенных обработчиков и запустить их вручную или в несколько потоков.
Если вы используете PostgreSQL, обычная реиндексация из консоли 1С может быть недостаточной. Выясним причину: при массовых операциях обновления таблиц в Postgres накапливается большое количество «мертвых» строк (dead tuples). Это может приводить к ложным срабатываниям ошибок уникальности.
Рекомендуем перед важными этапами обновления выполнять операцию VACUUM FULL ANALYZE для всей базы данных через pgAdmin или командную строку. Это полностью перестроит таблицы и индексы на диске, освободив место и устранив возможные логические несоответствия в индексах _bydims.
Итог: Для успешного перехода с УТ 11.3 на 11.4 необходимо:
Соблюдение этих правил позволит завершить переход без потерь данных и многодневных простоев системы.