Вопрос совместимости различных версий платформы 1С:Предприятие при работе с одной информационной базой является критически важным для стабильности системы. Рассмотрим ситуацию, когда в организации часть пользователей пытается работать на платформе 8.3.13, а другая часть — на 8.3.16. Разберем детально, почему такая схема работы не только не рекомендуется, но и зачастую технически невозможна.
Если ваша база 1С:Зарплата и управление персоналом (ЗУП) развернута в варианте «клиент-сервер», ответ на вопрос о возможности одновременной работы под разными версиями будет однозначным: нет, это невозможно. Проанализируем техническую причину этого ограничения.
Кластер серверов 1С:Предприятие требует полного соответствия версий исполняемых файлов на стороне клиента и на стороне сервера. При попытке подключения тонкого или толстого клиента версии 8.3.13 к серверу, на котором запущена служба версии 8.3.16, система мгновенно выдаст штатную ошибку: «Различаются версии клиента и сервера». Это происходит потому, что протоколы взаимодействия между клиентом и сервером могут меняться даже в минорных обновлениях (четвертая группа цифр в номере сборки), и платформа жестко блокирует любые попытки работы с несовпадающими протоколами во избежание некорректной передачи данных.
В случае с файловой базой (файл 1Cv8.1CD) ситуация выглядит иначе, но она гораздо опаснее. Технически, файл базы данных может быть открыт разными версиями платформы одновременно, так как платформа в файловом режиме сама выступает «движком» СУБД. Однако проанализируем последствия такого подхода:
8.3.13 и 8.3.16 произошли значительные изменения в механизмах управления блокировками и индексирования таблиц. Разные версии «движка» платформы могут по-разному интерпретировать записи в файле базы данных.1CD. Это может проявиться не сразу, а спустя время, когда утилита chdbfl.exe уже не сможет восстановить целостность данных.Проанализируем программные требования самой конфигурации «Зарплата и управление персоналом». Современные релизы ЗУП 3.1 разрабатываются с учетом возможностей новых платформ. Рассмотрим пример кода, который может выполняться при старте системы для проверки окружения:
Процедура ПриНачалеРаботыСистемы()
Если ПоддержкаВерсииПлатформы.ТекущаяВерсия() < "8.3.14" Тогда
Предупреждение("Для работы данной версии конфигурации необходима платформа не ниже 8.3.14");
ЗавершитьРаботуСистемы(Ложь);
КонецЕсли;
КонецПроцедуры
Если в свойствах конфигурации установлен РежимСовместимости со значением 8.3.14 или выше, то платформа версии 8.3.13 физически не сможет инициализировать метаданные и просто выдаст ошибку при запуске. Таким образом, сама программа ЗУП защищает себя от запуска на устаревших версиях платформы.
Выясним, как разные платформы взаимодействуют с локальными ресурсами компьютера. Каждая версия платформы создает свои временные файлы и кэш метаданных в папках Local AppData и Roaming. При одновременной работе (или даже последовательной, но частой смене версий) возникают следующие проблемы:
8.3.16, некорректно считывается версией 8.3.13.Если потребность в разных платформах вызвана тем, что офисы находятся далеко друг от друга и в одном из них невозможно обновить ПО, следует рассмотреть механизм РИБ (Распределенная информационная база).
Посмотрим на этот процесс по шагам:
В этом сценарии каждый узел работает под своей версией платформы независимо, и прямого взаимодействия «движков» с одним и тем же файлом базы данных не происходит. Это единственный безопасный способ использовать разные платформы для работы с одними и теми же данными.
Подведем итог: одновременная работа под платформами 8.3.13 и 8.3.16 крайне не рекомендуется и опасна. Для стабильной работы ЗУП необходимо привести всех пользователей к единой версии платформы, рекомендованной производителем (обычно это указано в файле ReadMe.txt к релизу конфигурации). Используйте механизмы автоматического обновления клиента с сервера, чтобы избежать подобных ситуаций в будущем.