Обновление технологической платформы 1С — это всегда ответственный шаг, который может обернуться серьезными простоями в работе предприятия. Релиз 8.3.12.1440 стал одним из самых проблемных в истории 1С, особенно для пользователей конфигурации «Зарплата и управление персоналом 3.1». В этой статье мы подробно разберем, почему этот релиз вызывает сбои, стоит ли переходить на промежуточную версию 8.3.12.1469 и какой алгоритм действий выбрать для восстановления стабильной работы системы.
Основная причина массовых «вылетов» конфигурации ЗУП 3.1 на этой версии платформы кроется в критической ошибке механизма SDBL (Simple Data Base Layer). Это внутренний слой платформы, который отвечает за преобразование запросов 1С в SQL-запросы к базе данных. В релизе 1440 была допущена ошибка при обработке вложенных запросов и работе с временными таблицами.
Поскольку ЗУП 3.1 активно использует механизм расширений и сложные запросы для расчета заработной платы и формирования регламентированной отчетности, система сталкивается с ошибкой Internal error SDBL. Рассмотрим ситуации, в которых она проявляется чаще всего:
Важный момент: на этом релизе подтверждены случаи разрушения структуры базы данных. При сохранении изменений в конфигураторе системные таблицы (такие как Config и DBSchema) могут перестать соответствовать физической структуре таблиц на SQL-сервере. Это приводит к невозможности запустить базу даже после перезапуска службы сервера 1С.
Многие системные администраторы рассматривают версию 1469 как «спасательный круг», поскольку в ее описании официально заявлено исправление критических ошибок 1440-й сборки. Однако, проанализировав опыт эксплуатации этого релиза, можно выделить следующие риски:
rphost на этой версии склонны к неконтролируемому потреблению оперативной памяти, особенно при работе с внешними компонентами или COM-соединениями.Таким образом, переход на 8.3.12.1469 является лишь временным решением, которое исправляет одну критическую ошибку, но добавляет несколько других.
Если вы столкнулись с разрушением базы или постоянными сбоями, наиболее надежным вариантом будет возврат на проверенные временем релизы веток 8.3.10 или 8.3.11. Выясним, как сделать это правильно, чтобы избежать потери данных.
Простое удаление новой платформы и установка старой может не сработать, если структура таблиц уже была изменена релизом 1440. Проанализируем правильную последовательность действий:
.dt. Несмотря на ошибки в работе, механизм выгрузки данных обычно остается работоспособным.8.3.10.2732..dt в эту пустую базу через конфигуратор стабильной платформы.Такой подход заставляет платформу заново перестроить все индексы и служебные таблицы базы данных, полностью исключая влияние некорректных структур, созданных проблемным релизом 1440.
Если специфика вашей конфигурации (например, использование новейших функций расширений) не позволяет откатиться на 8.3.10, необходимо двигаться вперед по ветке 8.3.12, минуя первые сборки. Посмотрим на статистику исправлений:
Наиболее стабильными в итоге были признаны финальные сборки 12-й ветки, такие как 8.3.12.1714 и выше. В них исправлено более 100 ошибок, включая те, что вызывали аварийное завершение работы при печати и работе с динамическими списками. Если политика компании требует оставаться на актуальной платформе, рекомендуется рассматривать переход на релизы не ниже 17-й серии.
Подводя итог, проанализируем ситуацию: релиз 8.3.12.1440 критически непригоден для промышленной эксплуатации с конфигурацией ЗУП 3.1. Если вы уже обновились, выберите одну из двух стратегий:
Стратегия А (Консервативная): Полный откат на платформу 8.3.10.2732 через процедуру выгрузки/загрузки .dt. Это гарантирует максимальную стабильность расчета зарплаты.
Стратегия Б (Прогрессивная): Обновление до финальных релизов ветки 8.3.12 (например, 8.3.12.1798) или переход на ветку 8.3.13 (с учетом ее актуальных требований к оборудованию). При этом обязательно выполните проверку логической и физической целостности базы данных после обновления:
// В конфигураторе:
Администрирование -> Тестирование и исправление...
- Проверка логической целостности
- Реиндексация таблиц
- Пересчет итогов
Помните: перед любыми манипуляциями с платформой создание резервной копии базы данных средствами SQL Server является обязательным условием безопасности ваших данных.