Какая версия платформы 1С 8.3 выше и как правильно выбрать релиз для работы?

В практике администраторов и программистов 1С часто возникает вопрос: какую версию платформы считать «старшей», если компания 1С одновременно выпускает обновления для нескольких веток, например, 8.3.17, 8.3.18 и 8.3.21? Ситуация, когда конфигурация требует версию «не ниже 8.3.17.1851 или 8.3.18.1208», может запутать, так как по математической логике любая версия 18-й ветки должна быть выше 17-й. Рассмотрим подробнее, как устроена иерархия релизов и с какими техническими сложностями можно столкнуться при обновлении.

Понятие параллельных веток разработки платформы

Проанализируем стратегию выпуска обновлений 1С. Разработчики системы поддерживают несколько технологических линий одновременно. Это необходимо для того, чтобы пользователи, чьи доработки или инфраструктура жестко привязаны к определенному функционалу конкретной ветки, могли получать критические исправления (баг-фиксы), не переходя на принципиально новую версию движка.

Выясним причину, почему в требованиях к конфигурации (например, «Бухгалтерия предприятия 3.0») указываются разные номера сборок для разных веток. В определенный момент законодательство требует внедрения новых механизмов — например, обновленных протоколов работы с ЭЦП для маркировки товаров или ЭДО. Эти механизмы внедряются во все актуальные ветки сразу. Поэтому сборка 8.3.17.1851 может содержать те же исправления по криптографии, что и сборка 8.3.18.1208. При этом версия 8.3.18.1201 может оказаться «ниже» по функциональным возможностям работы с подписью, чем более поздняя заплатка в 17-й ветке.

Таким образом, старшинство платформы определяется не только первой цифрой после мажорного номера (17 или 18), но и датой выхода конкретного исправления внутри ветки. Если ваша конфигурация требует конкретный билд, это означает, что именно в нем реализованы методы, необходимые для работы кода программы.

Выбор между стабильностью и новыми возможностями

Разберем ситуацию: что выбрать, если доступны последние релизы веток 8.3.17 и 8.3.18? Рассмотрим основные критерии:

1. Совместимость с оборудованием и ОС. Более старые ветки (8.3.15, 8.3.16) лучше работают на устаревших серверных операционных системах, таких как Windows Server 2008. Новые ветки могут требовать обновления системных библиотек.
2. Производительность. В новых ветках (например, 8.3.18) внедряются новые механизмы управления памятью и отрисовки форм. Однако на первых этапах это может приводить к «тормозам» или утечкам памяти в процессе rphost. Если ваша база работает стабильно на 8.3.17, переход на 8.3.18 стоит делать только при необходимости использования нового функционала.
3. Ошибки платформы. Каждая новая ветка приносит не только возможности, но и новые баги. Иногда 1С рекомендует временно откатиться на более стабильную предыдущую ветку (например, с 18-й на 17-ю), пока ошибки в новой версии не будут исправлены.

Технический анализ проблемы: Ошибка формата файла журнала регистрации

Переход на новые версии платформы иногда вскрывает проблемы в существующих механизмах. Одним из таких механизмов является Журнал регистрации, который в современных версиях 1С (начиная с 8.3.5) хранится в формате SQLite (файлы с расширением .lgd).

Рассмотрим пример кода, который может вызвать ошибку Ошибка формата файла журнала регистрации при попытке программной выгрузки данных:

// Пример кода выгрузки журнала регистрации во внешнюю таблицу
ИмяФайлаКопииЖР = ПутьККаталогуЖурналаРегистрации + "\1Cv8_copy.lgd";
Фильтр = Новый Структура;
Фильтр.Вставить("ДатаОкончания", ДатаФормирования);

// Создание копии файла журнала
СкопироватьЖурналРегистрации(, ИмяФайлаКопииЖР, Фильтр);

ТекущийЖурнал = Новый ТаблицаЗначений;
ДополнительныйЖурнал = Новый ТаблицаЗначений;

// Выгрузка может завершиться ошибкой на больших объемах данных
ВыгрузитьЖурналРегистрации(ТекущийЖурнал, Фильтр, , , 50);
ВыгрузитьЖурналРегистрации(ДополнительныйЖурнал, Фильтр, , ИмяФайлаКопииЖР, 50); 

Проанализируем ситуацию. Данная ошибка часто возникает по следующим причинам:

• Размер файла. При достижении файлом .lgd критического размера (десятки гигабайт), механизмы SQLite могут работать нестабильно, особенно если на сервере недостаточно места для временных файлов.
• Блокировки. Если в момент выгрузки фоновые процессы или пользователи активно записывают события в журнал, метод ВыгрузитьЖурналРегистрации может конфликтовать с блокировками базы данных.
• Повреждение индексов. Внутри файла журнала существуют индексы для быстрого поиска. Если они повреждены (например, после аварийного завершения работы сервера), платформа выдаст ошибку формата.

Как решить проблемы с журналом регистрации при обновлении платформы

Если после перехода на релизы типа 8.3.17.1851 вы столкнулись с подобными ошибками, рекомендуем выполнить следующие шаги:

1. Сокращение журнала регистрации. Используйте стандартную процедуру сокращения (архивирования) журнала. Это уменьшит размер основного файла и перестроит его структуру.
2. Пересоздание индексов. Иногда помогает физическое удаление или перемещение старого файла 1Cv8.lgd (при остановленной службе сервера 1С), чтобы система начала писать новый чистый файл.
3. Проверка прав доступа. Убедитесь, что у пользователя, под которым запущена служба 1C:Enterprise Server, есть полные права на папку с журналом регистрации.
4. Использование альтернативных методов. Если стандартный метод ВыгрузитьЖурналРегистрации падает, рассмотрите возможность чтения журнала напрямую через SQLite запросы (для опытных разработчиков) или используйте специализированные инструменты для анализа логов.

Подводя итог, отметим, что при выборе версии платформы необходимо ориентироваться не на абстрактное «большее число», а на конкретные требования вашей конфигурации и стабильность релизов в выбранной ветке. Помните, что версия 8.3.18.1201 может быть функционально беднее версии 8.3.17.1851 в части критически важных государственных сервисов, если последняя вышла позже.