Итак, вы решили использовать обновлятор для архивации семёрочных баз.
Он это прекрасно умеет делать, начиная с версии от 15 июня 2016 года, но вот незадача - в отличие от восьмёрочных баз, где механизм блокировки пользователей реализован на уровне платформы, семёрка нам таких возможностей не предоставляет.
И по умолчанию обновлятор не предпринимает попыток выгнать пользователей из базы. При этом та ситуация, когда копия была создана при работающих пользователях помечается как ошибочная и такая резервная копия отмечается в имени меткой [грязная копия].
Ниже я расскажу о возможных способах блокировки базы 7.7 перед архивацией, все они не лишены недостатков и окончательное решение об их применении должны принять вы сами.
Оглавление
Способ первый (правильный)
Первый и самый правильный способ - это доработать конфигурацию, чтобы завершение работы пользователей происходило автоматически по определенному условию, например, наличию файла block.txt в папке с базой.
Для доработки конфигурации вам потребуется помощь программиста.
Для того, чтобы создавать файл в базе перед блокировкой и удалять после разблокировки зайдите в свойства базы:
... и перейдите на закладку "События":
Здесь можно написать, например, такой код для создания файла block.txt в папке с базой перед блокировкой:
Обратите внимание на то, что второй строкой мы указали паузу в 10 секунд, чтобы после создания файла block.txt конфигурация обработала его появление и закрыла все подключения к базе.
И, например, такой код для удаление этого файла после разблокировки:
Теперь осталось только доработать вашу конфигурацию, чтобы она периодически проверяла наличие этого файла в базе и при его появлении закрывала все подключения и не пускала новых пользователей. Эта уже задача для вашего программиста.
Внимание! В случае, если вы редактировали шаблоны для архивации для базы - убедитесь, что блокировочный файл (в данном примере block.txt) не попадает в указанный вами шаблон. Иначе обновлятор заблокирует его и ваш скрипт после разблокировки не сможет его удалить.
Способ второй (правильный, но не надёжный)
Понимаю, что не у всех есть возможности доработать конфигурацию, хотя я крайне рекомендую первый вариант.
Поэтому для многих будет допустимым такое решение: если вы ставите архивацию на ночь - настройте уведомления на почту при ошибках архивации. Просматривайте почту утром и если какие-то из баз не смогли архивироваться (были сделаны грязные копии) - тут же выгоняйте всех пользователей и повторяйте процесс архивации этих баз утром. Тех кто оставил базу на ночь работающей - всячески мотивировать на "неповторение" ситуации.
Если компьютер на котором лежат базы выключается на ночь - можно поставить архивацию баз при загрузке компьютера, когда в них ещё никто не работает.
Способ третий (теневое копирование)
Возможности и нюансы теневого копирования описаны здесь.
Способ четвертый (неправильный)
Понимаю, что не у всех хватит сил и терпения реализовать правильный вариант блокировки, поэтому приведу так называемые "жёсткие" способы выгнать всех пользователей из базы.
Прежде всего, если работа с базой происходит локально, то есть к ней подключаются только пользователи этого компьютера - можно перед архивацией "убивать" все запущенные процессы 1с, вот так:
Такое завершение считается аварийным и после него обязательно понадобится запуск базы в монопольном режиме и её переиндексация. Поэтому я рекомендую этот способ завершения только в крайних случаях.
Если к базе подключаются с других компьютеров, то к упомянутым выше способам можно добавить сброс сетевых подключений к компьютеру:
Всё это "жёсткие" способы и если в момент их применения кто-то запустил, например, обработку проведения в базе - вполне можно потерять часть данных. Будьте осторожны!