Итак, вы решили использовать обновлятор для архивации семёрочных баз.

Он это прекрасно умеет делать, начиная с версии от 15 июня 2016 года, но вот незадача - в отличие от восьмёрочных баз, где механизм блокировки пользователей реализован на уровне платформы, семёрка нам таких возможностей не предоставляет.

И по умолчанию обновлятор не предпринимает попыток выгнать пользователей из базы. При этом та ситуация, когда копия была создана при работающих пользователях помечается как ошибочная и такая резервная копия отмечается в имени меткой [грязная копия].

Ниже я расскажу о возможных способах блокировки базы 7.7 перед архивацией, все они не лишены недостатков и окончательное решение об их применении должны принять вы сами.

Способ первый (правильный)

Первый и самый правильный способ - это доработать конфигурацию, чтобы завершение работы пользователей происходило автоматически по определенному условию, например, наличию файла block.txt в папке с базой.

Для доработки конфигурации вам потребуется помощь программиста.

Для того, чтобы создавать файл в базе перед блокировкой и удалять после разблокировки зайдите в свойства базы:

... и перейдите на закладку "События":

Здесь можно написать, например, такой код для создания файла block.txt в папке с базой перед блокировкой:

Обратите внимание на то, что второй строкой мы указали паузу в 10 секунд, чтобы после создания файла block.txt конфигурация обработала его появление и закрыла все подключения к базе.

И, например, такой код для удаление этого файла после разблокировки:

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

Внимание! В случае, если вы редактировали шаблоны для архивации для базы - убедитесь, что блокировочный файл (в данном примере block.txt) не попадает в указанный вами шаблон. Иначе обновлятор заблокирует его и ваш скрипт после разблокировки не сможет его удалить.

Способ второй (правильный, но не надёжный)

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

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

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

Способ третий (теневое копирование)

Возможности и нюансы теневого копирования описаны здесь.

Способ четвертый (неправильный)

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

Прежде всего, если работа с базой происходит локально, то есть к ней подключаются только пользователи этого компьютера - можно перед архивацией "убивать" все запущенные процессы 1с, вот так:

Такое завершение считается аварийным и после него обязательно понадобится запуск базы в монопольном режиме и её переиндексация. Поэтому я рекомендую этот способ завершения только в крайних случаях.

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

Всё это "жёсткие" способы и если в момент их применения кто-то запустил, например, обработку проведения в базе - вполне можно потерять часть данных. Будьте осторожны!