Как в 1С определить, что база была перемещена, и выполнить свой код?

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

Основной механизм: Библиотека стандартных подсистем (БСП)

Вся логика определения перемещения базы встроена в Библиотеку стандартных подсистем (БСП), которая используется в большинстве типовых конфигураций. Механизм сравнивает текущие параметры подключения к базе с эталонными значениями, сохраненными ранее.

Ключевыми компонентами этого механизма являются:

1. Константа ПараметрыБлокировкиРаботыСВнешнимиРесурсами. Это "сердце" механизма. В ней хранится структура с параметрами "оригинальной" базы: строка соединения, идентификатор ИБ, имя сервера и флаг, является ли база копией. Когда вы в диалоге подтверждаете, что база перемещена, система записывает текущие параметры в эту константу как эталон.
2. Общий модуль БлокировкаРаботыСВнешнимиРесурсами. Здесь сосредоточен весь код, который выполняет проверки при старте системы.
3. Файл DoNotCopy.txt (только для файловых баз). Служебный файл в каталоге с базой данных, содержащий ее уникальный идентификатор (GUID).

Алгоритм проверки при запуске системы

Давайте по шагам проанализируем, как система принимает решение о показе диалогового окна.

1. Сравнение с эталоном. Система считывает сохраненные параметры из константы ПараметрыБлокировкиРаботыСВнешнимиРесурсами и сравнивает их с текущими. В первую очередь проверяется строка соединения.
2. Если все совпадает. Если текущая строка соединения совпадает с сохраненной, система считает, что с базой все в порядке, и дальнейшие проверки не выполняет. Именно поэтому, если в уже работающей базе просто удалить файл DoNotCopy.txt, ничего не произойдет — проверка до него просто не дойдет.
3. Если есть расхождения. Если строки соединения отличаются (например, изменился путь к каталогу файловой базы или имя сервера в клиент-серверной), система запускает более детальный анализ.

Особенности для файловой и клиент-серверной баз

В зависимости от типа базы, логика детальной проверки различается.

Для файловой базы:

Ключевую роль играет файл DoNotCopy.txt. Если строка соединения изменилась, а этот файл в каталоге базы отсутствует (что типично при копировании папки или восстановлении из .dt), система делает вывод, что это копия, и показывает диалог.

Важный нюанс: если вы переместите каталог с базой вместе с файлом DoNotCopy.txt, система не выдаст сообщение о перемещении. Однако эталонная строка соединения в константе при этом не обновится. Если вы позже удалите DoNotCopy.txt, система "вспомнит" о несоответствии пути и покажет окно блокировки.

Для клиент-серверной базы:

Здесь анализ основан на параметрах строки соединения: имени кластера серверов 1С и имени базы в этом кластере. Если они изменились по сравнению с сохраненными в константе, база считается перемещенной. В параметрах блокировки также есть флаг ПроверятьИмяСервера, который позволяет настроить строгость проверки, что полезно в сложных инфраструктурах с несколькими DNS-именами.

Как программно использовать результат проверки?

Теперь перейдем к главному вопросу: как встроить свою логику, которая будет срабатывать, если система определила базу как копию. Для этого нам понадобится функция из общего модуля БСП.

В общем модуле БлокировкаРаботыСВнешнимиРесурсами есть функция СохраненныеПараметрыБлокировки(), которая возвращает структуру с текущим состоянием. Нас интересует ее поле РаботаСВнешнимиРесурсамиЗаблокирована.

Посмотрим на пример. Допустим, нам нужно очистить регистр сведений МоиНастройкиОбмена при первом запуске копии базы. Этот код можно разместить в подходящем месте, которое выполняется при старте системы, например, в обработчике события ПриНачалеРаботыСистемы в модуле управляемого приложения.

Процедура ПриНачалеРаботыСистемы()

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

    // ... остальной код обработчика
    
КонецПроцедуры

Таким образом, используя стандартные функции БСП, мы можем легко встроить собственную логику, которая будет выполняться только в копиях информационных баз, делая их использование более безопасным и предсказуемым. Для быстрого поиска и изучения готовых примеров программных вызовов подсистем пригодится справочник по методам БСП с примерами использования.