При переносе информационной базы 1С:Предприятие на новый сервер администраторы и разработчики часто сталкиваются с неприятной ситуацией: база начинает регулярно сигнализировать о том, что она является копией. Сообщение «Информационная база перемещена» блокирует работу регламентных заданий и внешних сервисов, а стандартная функция СтрокаСоединенияИнформационнойБазы() упорно продолжает возвращать адрес старого сервера, даже если подключение физически происходит к новому. Рассмотрим подробно, почему это происходит и как окончательно устранить этот конфликт.
В современных типовых конфигурациях, таких как 1С:Бухгалтерия 3.0, используется «Библиотека стандартных подсистем» (БСП), которая содержит механизмы контроля за перемещением базы. Проанализируем, как это работает изнутри. При каждом запуске система вызывает функцию СтрокаСоединенияИнформационнойБазы() и сравнивает полученный результат со значением, которое было сохранено в параметрах базы данных при последнем подтверждении «легальности» размещения.
Если система обнаруживает расхождение хотя бы в один символ, она делает вывод: база была скопирована или перенесена на другой ресурс. Проблема в том, что для платформы строки Srvr="192.168.0.1";Ref="base"; и Srvr="MyServerName";Ref="base"; являются абсолютно разными, несмотря на то, что они ведут в одну и ту же базу данных. Выясним основные причины, по которым это происходит.
Разберем ситуацию, когда разные пользователи подключаются к одной базе, используя разные форматы записи в строке соединения. Один специалист может прописать в списке баз IP-адрес сервера (например, 192.168.1.10), а другой — его сетевое имя (например, AppServer).
Когда администратор подтверждает, что «Информационная база перемещена», система записывает текущую строку соединения (например, с именем сервера) как эталонную. Если следующий пользователь зайдет по IP-адресу, его сеанс вызовет срабатывание триггера «Это копия», так как его локальная функция СтрокаСоединенияИнформационнойБазы() вернет строку с IP, которая не совпадает с сохраненным эталоном с именем сервера.
Существует официально зарегистрированная ошибка платформы (номер 00-00188874), суть которой заключается в том, что при работе в клиент-серверном варианте может ошибочно возникать сообщение о перемещении БД. Это происходит, когда параметр Srvr в строке соединения отличается от внутреннего имени рабочего сервера, зарегистрированного в кластере. В этом случае даже после подтверждения перемещения, следующее регламентное задание может снова заблокировать базу.
Самый надежный способ решить проблему — привести всех пользователей к единому стандарту подключения. Проанализируем шаги для реализации этого подхода:
server.domain.local) или только по краткому сетевому имени. Использование IP-адресов в продуктивной среде не рекомендуется..v8i должен содержать одинаковую строку подключения для всех.Если стандартные средства не помогают и база продолжает «сбрасывать» настройки, мы можем принудительно обновить эталонную строку соединения в параметрах БСП. Посмотрим на пример кода, который можно выполнить во внешней обработке под правами администратора:
// Получаем текущую строку соединения, которую видит платформа
ТекущаяСтрока = СтрокаСоединенияИнформационнойБазы();
// Записываем её как правильную в параметры работы программы
// Для БСП используется вызов из общего модуля
Если ОбщегоНазначения.ПодсистемаСуществует("СтандартныеПодсистемы.БазоваяФункциональность") Тогда
ПараметрыБСП = ОбщегоНазначения.ПараметрыРаботыПрограммы();
// В некоторых версиях БСП ключ может называться иначе
// Обычно это "СтрокаСоединенияИнформационнойБазы"
ОбщегоНазначения.УстановитьПараметрИнформационнойБазы("СтрокаСоединенияИнформационнойБазы", ТекущаяСтрока);
Сообщить("Эталонная строка соединения обновлена на: " + ТекущаяСтрока);
КонецЕсли;
Важно помнить, что после выполнения такого кода все пользователи, у которых в списке баз прописано другое имя (например, старое или IP), снова увидят сообщение о копии. Поэтому данный метод работает только в связке с Решением 1.
Иногда платформа «помнит» старое имя сервера из-за данных, хранящихся в каталоге служебных файлов кластера. Рассмотрим процедуру глубокой очистки:
1C:Enterprise 8.3 Server Agent.srvinfo (по умолчанию это C:\Program Files\1cv8\srvinfo).reg_1541).1CV8Reg.lst. Внимание: это критически важный файл, перед редактированием сделайте бэкап!snmp и временные файлы из каталогов конкретных баз внутри reg_1541 (папки с именами-GUID), если они есть.Проанализируем изменения в последних версиях платформы. Начиная с версии 8.3.18, механизмы контроля стали еще жестче. Платформа теперь анализирует не только строку соединения 1С, но и параметры СУБД. Если база была перенесена на другой SQL-сервер, система это заметит, даже если имя сервера 1С осталось прежним.
В этом случае при первом запуске обязательно нужно выбрать вариант «Информационная база перемещена». Если кнопка не нажимается или не дает эффекта, проверьте права пользователя Windows, под которым запущена служба сервера 1С — у нее должны быть права на запись в каталог srvinfo, иначе изменения конфигурации кластера не сохранятся.
Для стабильной работы функции СтрокаСоединенияИнформационнойБазы() выполним следующие настройки на уровне операционной системы:
hosts на сервере и на клиентских машинах. В нем не должно быть старых записей, связывающих имя сервера с неактуальными IP-адресами.ping -a [IP_адрес] возвращала именно то имя сервера, которое прописано в 1С.default.vrd. В нем параметр ib также должен содержать актуальную и единообразную строку соединения.Таким образом, решение проблемы кроется не в простой очистке пользовательского кэша, а в обеспечении идентичности способа обращения к серверу для всех участников процесса: пользователей, регламентных заданий и внутренних механизмов платформы.