Как устранить постоянное появление сообщения «Информационная база перемещена» в 1С?

При работе с программными продуктами на платформе 1С:Предприятие 8.3, использующими Библиотеку стандартных подсистем (БСП), пользователи часто сталкиваются с защитным механизмом, который выдает сообщение: «Информационная база перемещена». Обычно это происходит после переноса базы на другой сервер, смены имени базы в кластере или перехода с файлового варианта на клиент-серверный. Однако бывают случаи, когда база не перемещалась или подтверждение выбора («Это копия» или «База перемещена») не сохраняется, и окно появляется при каждом запуске. В этой статье мы подробно разберем, как работает этот механизм, почему он может «зациклиться» и как окончательно решить проблему.

Почему 1С считает, что база была перемещена?

Для начала проанализируем логику системы. Механизм защиты предназначен для того, чтобы предотвратить дублирование регламентных заданий (например, рассылку отчетов клиентам, синхронизацию с банками или выгрузку в ОФД) из копии базы. Если система решит, что она является копией, она заблокирует работу с внешними ресурсами.

Рассмотрим, как происходит проверка. В типовых конфигурациях (БП, ЗУП, УНФ) за это отвечает модуль РегламентныеЗаданияСлужебный. Система сравнивает текущие параметры подключения (строку соединения) с теми, которые были сохранены в специальной константе при предыдущем «успешном» запуске. Если хотя бы один символ в строке отличается, 1С выведет диалоговое окно.

Разбор программного механизма проверки

Давайте заглянем «под капот» и проанализируем фрагмент кода, который осуществляет проверку в серверном варианте работы. Это поможет нам понять, почему даже при одинаковых настройках сообщение может появляться снова.

// Фрагмент логики из модуля РегламентныеЗаданияСлужебный
ИмяБазы = НРег(СтроковыеФункцииКлиентСервер.ПолучитьПараметрыИзСтроки(СтрокаСоединения).Ref);
ИмяСервера = НРег(СтроковыеФункцииКлиентСервер.ПолучитьПараметрыИзСтроки(СтрокаСоединения).Srvr);
СохраненноеИмяБазы = НРег(СтроковыеФункцииКлиентСервер.ПолучитьПараметрыИзСтроки(ПараметрыБлокировки.СтрокаСоединения).Ref);
СохраненноеИмяСервера = НРег(СтроковыеФункцииКлиентСервер.ПолучитьПараметрыИзСтроки(ПараметрыБлокировки.СтрокаСоединения).Srvr);

Если ИмяБазы <> СохраненноеИмяБазы Или (ПараметрыБлокировки.ПроверятьИмяСервера И (ИмяСервера <> СохраненноеИмяСервера)) Тогда
    // Система устанавливает признак необходимости принятия решения
    Возврат Истина; 
КонецЕсли;

Проанализируем эту ситуацию. Обратите внимание на функцию НРег() — система приводит параметры к нижнему регистру для сравнения. Однако существуют нюансы, которые код может не учесть автоматически:

1. Разное написание имени сервера у пользователей: Один бухгалтер прописал в списке баз сервер как 192.168.1.10, а другой — по сетевому имени SERVER-1C. Для платформы это разные строки соединения, что вызывает срабатывание защиты.
2. Использование FQDN: Если в одном случае указано server, а в другом server.domain.local, проверка не пройдет.
3. Регистр в строке соединения: Несмотря на использование НРег() в коде, в некоторых старых релизах платформы или БСП сравнение могло быть чувствительным к регистру в определенных узлах параметров.

Способ 1: Решение через пользовательский интерфейс

Прежде чем переходить к программированию, попробуем решить проблему штатными средствами. Если вы уверены, что база является основной (рабочей), выполним следующие действия:

1. Зайдем в раздел Администрирование.
2. Выберем пункт Обслуживание (в некоторых редакциях — «Поддержка и обслуживание»).
3. Найдем подраздел Регламентные задания.
4. Если база считает себя копией, вы увидите информационную надпись и кнопку «Разблокировать работу с внешними ресурсами». Нажмем её.

Это действие должно обновить сохраненные параметры в базе данных. Если после этого при перезапуске сообщение появляется снова, значит, запись в базу не прошла или параметры сеанса снова отличаются.

Способ 2: Работа с константой «Параметры блокировки работы с внешними ресурсами»

Вся информация о «прошлом» месте жительства базы хранится в константе с типом ХранилищеЗначения. Рассмотрим, как найти и очистить её, если стандартная кнопка не помогает. Название константы: ПараметрыБлокировкиРаботыСВнешнимиРесурсами.

Выясним причину, почему сообщение может «зациклиться». Часто это происходит из-за нехватки прав доступа у пользователя SQL-сервера, под которым работает сервер 1С, на изменение структуры или данных в таблице констант. Также возможны проблемы с кэшем сервера 1С.

Для программного сброса блокировки мы можем воспользоваться консолью кода или создать небольшую обработку со следующим фрагментом:

// Программная разблокировка через механизмы БСП
Процедура ПринудительнаяРазблокировка() Экспорт
    УстановитьПривилегированныйРежим(Истина);
    ПараметрыБлокировки = Константы.ПараметрыБлокировкиРаботыСВнешнимиРесурсами.Получить().Получить();
    Если ПараметрыБлокировки <> Неопределено Тогда
        ПараметрыБлокировки.РаботаСВнешнимиРесурсамиЗаблокирована = Ложь;
        // Обновляем строку соединения на текущую, чтобы проверки проходили успешно
        ПараметрыБлокировки.СтрокаСоединения = СтрокаСоединенияИнформационнойБазы();
        Константы.ПараметрыБлокировкиРаботыСВнешнимиРесурсами.Установить(Новый ХранилищеЗначения(ПараметрыБлокировки));
        Сообщить("Параметры блокировки успешно обновлены.");
    КонецЕсли;
КонецПроцедуры

Способ 3: Проверка настроек сети и протокола IPv6

Иногда корень проблемы кроется в настройках операционной системы сервера. Выясним, как протокол IPv6 может влиять на 1С. В некоторых релизах платформы (особенно 8.3.10, 8.3.12) наблюдался баг: при обращении к серверу система иногда получала адрес в формате IPv6 (например, ::1), а в константу сохраняла IPv4 или имя хоста.

Разберем, что можно сделать в этой ситуации:

• Проверим файл hosts на сервере 1С и на рабочих станциях. Убедимся, что имя сервера однозначно сопоставлено с его IPv4-адресом.
• Попробуем временно отключить протокол IPv6 в свойствах сетевого адаптера сервера, если база продолжает «перемещаться» без видимых причин.
• Убедимся, что в консоли администрирования кластера 1С имя сервера указано точно так же, как в настройках подключения у пользователей.

Способ 4: Очистка локального кэша пользователей

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

Выполним полную очистку кэша по шагам:

1. Закроем все сеансы 1С на компьютере пользователя.
2. Перейдем в папки:
   • %AppData%\Local\1C\1Cv8
   • %AppData%\Roaming\1C\1Cv8
3. Удалим все папки с длинными идентификаторами (вида eb08966c-843b-4d32...).
4. Удалим базу из списка и добавим её заново, внимательно прописав адрес сервера и имя базы (лучше всего скопировать строку подключения из рабочей консоли администрирования).

Рекомендации по обновлению платформы

Важно помнить, что в старых версиях платформы (например, указанной в обсуждении 8.3.10.2772) механизмы взаимодействия с SQL-сервером и определения сетевых параметров имели ряд недоработок. Рассмотрим целесообразность обновления. Начиная с релизов 8.3.12 и выше, многие ошибки, связанные с ложным определением перемещения базы, были исправлены разработчиками 1С. Если вышеуказанные способы помогают лишь на время, настоятельно рекомендуем обновить платформу до актуальной версии.

Подведем итог. Сообщение о перемещении базы — это не ошибка, а работа системы безопасности. Чтобы оно исчезло, необходимо добиться полной идентичности строки соединения у всех пользователей и корректной записи этих данных в константу ПараметрыБлокировкиРаботыСВнешнимиРесурсами. Совместное использование инструментов администрирования и программных методов разблокировки позволяет решить эту задачу максимально оперативно.