Каждый администратор или активный пользователь систем на базе «1С:Предприятие 8.3» хотя бы раз сталкивался с предупреждением: «Информационная база была перемещена или восстановлена из резервной копии». Обычно при переносе базы достаточно один раз нажать кнопку «Информационная база перемещена» (или «Это копия», если создается тестовая среда), и система запоминает этот выбор. Однако в некоторых случаях это окно начинает появляться при каждом запуске программы под любым пользователем, превращая работу в бесконечный цикл подтверждений.
В этой статье мы подробно разберем внутренние механизмы этой проверки, выясним технические причины возникновения «бесконечного» окна и рассмотрим все штатные способы решения проблемы как для клиент-серверного (SQL), так и для файлового вариантов работы.
---
В основе этого механизма лежит функционал Библиотеки стандартных подсистем (БСП). Проверка уникальности расположения базы запускается при старте системы. Реализация этого контроля принципиально отличается в зависимости от режима работы базы данных:
DoNotCopy.txt. Внутри этого файла хранится точный локальный или сетевой путь к базе данных. При каждом запуске программа сравнивает текущий путь запуска с путем, записанным в файле. Если пути не совпадают (например, базу скопировали на другой диск или открыли по сети через другое имя компьютера), система бьет тревогу.ПараметрыБлокировкиРаботыСВнешнимиРесурсами. В этой константе фиксируется строка соединения с сервером (параметры Srvr и Ref). При каждом последующем сеансе система сверяет текущую строку подключения с той, что записана в константе.---
Давайте проанализируем ситуацию, когда база физически никуда не перемещалась, но окно появляется снова и снова. В клиент-серверном варианте это происходит из-за несогласованности строк подключения на рабочих местах пользователей. Программа считает базу перемещенной, если строки подключения хотя бы минимально различаются.
Рассмотрим пример. В локальной сети компании один и тот же сервер 1С может иметь разные адреса для разных групп пользователей или даже в настройках разных ПК:
// У Пользователя №1 в списке баз прописано имя сервера (NetBIOS):
Srvr="srv-sql";Ref="trade_db";
// У Пользователя №2 прописан IP-адрес сервера:
Srvr="192.168.1.100";Ref="trade_db";
// У Пользователя №3 прописано полное доменное имя (FQDN):
Srvr="srv-sql.local-domain.ru";Ref="trade_db";
Когда Пользователь №1 заходит в систему, БСП проверяет константу. Допустим, там записано значение srv-sql. Всё совпадает, база запускается без вопросов. Затем в систему заходит Пользователь №2. Его строка содержит 192.168.1.100. Система видит несовпадение, считает, что базу перенесли на другой сервер, и выводит предупреждающее окно. Пользователь №2 нажимает кнопку «Информационная база перемещена». В этот момент программа перезаписывает константу, сохраняя туда новое значение — 192.168.1.100.
На следующий день Пользователь №1 снова пытается войти в базу. Теперь система видит несоответствие его строки (srv-sql) и нового значения в константе (192.168.1.100). Окно появляется снова, Пользователь №1 опять нажимает «Перемещена» — и так продолжается бесконечно.
Аналогичная проблема часто возникает при использовании веб-серверов (IIS или Apache), когда часть пользователей работает через тонкий клиент по протоколу HTTP/HTTPS, а часть — напрямую через локальную сеть.
Также стоит упомянуть известную ошибку платформы 00-00188874. Она заключается в том, что в кластере с несколькими рабочими серверами имя активного сервера может динамически меняться в строке подключения, что также приводит к постоянной перезаписи параметров блокировки.
---
Для устранения этой проблемы разработчики «1С» предусмотрели несколько механизмов. Нам не обязательно устанавливать неофициальные расширения, достаточно грамотно настроить систему.
Если ваши пользователи заходят в базу под разными именами серверов или IP-адресами, и вы не можете оперативно это изменить, вы можете настроить систему так, чтобы она игнорировала адрес сервера и сверяла только имя самой базы данных (параметр Ref).
Выполним это по шагам:
После этого система перезапишет настройки в базе данных и в дальнейшем будет сравнивать только идентификатор базы данных Ref, полностью игнорируя различие между IP-адресами, NetBIOS и FQDN-именами серверов.
Если окно в данный момент не выводится, но вы хотите настроить этот параметр превентивно:
ПараметрыБлокировкиРаботыСВнешнимиРесурсами и откройте её.---
Этот способ является наиболее правильным с точки зрения системного администрирования. Вместо отключения защитных механизмов программы мы приведем конфигурационные файлы всех пользователей к единому стандарту.
Разберем, как автоматизировать этот процесс:
srv-sql), так как IP-адреса могут измениться при перенастройке сети или замене роутера..v8i) и размещается на сетевом ресурсе, доступном всем сотрудникам.---
Если кто-то из пользователей по ошибке нажал кнопку «Это копия», система переходит в защищенный режим. В заголовке программы появляется раздражающий префикс [КОПИЯ], а все регламентные и фоновые задания (синхронизация данных, отправка почты, загрузка курсов валют, обмены с банками) блокируются.
Это сделано для того, чтобы тестовая база случайно не отправила реальным клиентам повторные письма или не выгрузила искаженные данные в рабочую ERP-систему.
Чтобы вернуть базе рабочий статус и снять блокировку внешних ресурсов, выполните следующие действия:
[КОПИЯ] исчезнет из заголовка главного окна.---
Если бесконечный цикл вопросов возникает в файловой базе (которая лежит в сетевой папке или на локальном диске), это говорит о проблемах с правами доступа к файлам или о повреждении служебных данных.
Давайте разберем по шагам, как исправить эту ситуацию вручную:
1Cv8.1CD).DoNotCopy.txt.1cv8.exe «завис» в диспетчере задач сервера. Завершите все активные сеансы.DoNotCopy.txt.TradeBaza, переименуйте ее в TradeBaza_New).TradeBaza_New.DoNotCopy.txt с корректным актуальным путем, и проблема будет решена.---
Появление окна блокировки перемещения базы — это не просто назойливый баг, а важнейший элемент безопасности вашей учетной системы. Он защищает рабочие базы от зацикливания регламентных заданий и исключает отправку ошибочных транзакций из тестовых копий.
При возникновении проблем в клиент-серверном режиме всегда начинайте с проверки единообразия строк подключения на компьютерах пользователей и, при необходимости, отключайте флаг проверки имени сервера. В файловом режиме достаточно очистить устаревший файл DoNotCopy.txt и обновить путь в списке баз.