Готовишься к экзамену?
Полнофункциональный тренажер @bot_1cnik_bot с полноценным обучением, режимом экзамена и подробной статистикой.
После доработки конфигурации нужно проверить изменения в режиме отладки. Разрешено ли запускать отладку, если к этой же информационной базе уже подключены пользователи (есть активные сеансы)?
Да, можно - при условии, что специально не выполнять «Обновление конфигурации базы данных»
Неправильно: Если внесенные изменения затрагивают структуру данных, без обновления конфигурации базы данных они все равно не проверятся корректно, а иногда система вообще не позволит полноценно работать. Условие должно звучать не «не выполнять обновление», а «обновление не требуется», то есть изменения не меняют структуру таблиц.
Да, можно в любом случае, наличие пользователей не влияет
Неправильно: Наличие активных сеансов критично, когда требуется обновлять конфигурацию базы данных: для этого обычно нужен монопольный (эксклюзивный) доступ и отключение пользователей. Поэтому «в любом случае» неверно - все зависит от типа внесенных изменений.
Да, можно, если доработки не приводят к изменению структуры таблиц (и не требуют обновления конфигурации базы данных)
Правильно: Если изменения касаются только логики (модули), интерфейса (формы), отчетов, обработок, команд и т.п., то структура данных не меняется и обновление конфигурации базы данных не нужно. В таком случае отладочную сессию можно запускать, даже когда другие пользователи работают в базе.
Нет, нельзя, потому что при запуске отладки обязательно придется обновлять конфигурацию базы данных
Неправильно: Запуск отладки сам по себе не означает обязательное обновление конфигурации базы данных: оно требуется только при изменениях метаданных, влияющих на хранение данных (реквизиты, табличные части, регистры и т.д.). Если структура не менялась, отладка возможна без монопольного доступа.
Пояснение
В 1С важно различать два типа изменений: (1) изменения поведения и интерфейса и (2) изменения структуры данных. К первым относятся правки модулей, форм, команд, отчетов, обработок, ролей и т.п. Обычно они не требуют «Обновления конфигурации базы данных», поэтому вы можете открыть отладочную сессию и проверять логику, даже если в базе есть другие активные пользователи.
Ко вторым относятся изменения метаданных, которые влияют на хранение данных: добавление/удаление реквизитов объектов, изменение типов, новые регистры, табличные части и другие элементы, из-за которых меняется структура таблиц информационной базы. В таком случае для проверки вам почти всегда потребуется обновить конфигурацию базы данных, а эта операция обычно требует монопольного доступа (нужно, чтобы пользователи вышли, либо их пришлось бы отключить).
Практический пример: вы исправили алгоритм расчета в модуле документа «Начисление зарплаты» - это изменение логики, и его можно отлаживать параллельно с работающими пользователями (желательно в тестовой базе). Но если вы добавили новый реквизит в справочник «Сотрудники», чтобы хранить дополнительные данные, то для корректной проверки потребуется обновление структуры БД - и здесь уже придется обеспечить эксклюзивный доступ.
Лучшие практики: проверяйте доработки на тестовой/копии базы, планируйте структурные изменения на «окно обслуживания», заранее предупреждайте пользователей, и разделяйте задачи разработки и эксплуатации (разработка/тест - отдельно, рабочая база - отдельно).