При работе в современных конфигурациях 1С, таких как ERP или Бухгалтерия предприятия 3.0, пользователи могут столкнуться с крайне неприятной ситуацией: при попытке сохранить изменения в справочнике Номенклатура или любом другом документе система выдает сообщение «Ошибка снятия блокировки объекта. Объект не заблокирован». Ситуация осложняется тем, что ошибка может проявляться хаотично, даже у пользователей с полными правами, и часто возникает после обновления платформы или переноса базы на новый SQL-сервер.
В этой статье мы подробно разберем, почему менеджер блокировок 1С теряет связь с объектом, проанализируем влияние конкретных релизов платформы и выясним, какие настройки MS SQL Server помогут навсегда забыть об этой проблеме.
Первым делом проанализируем версию платформы, на которой работает база. В ходе обсуждения было замечено, что проблема стала массовой после перехода на релиз 8.3.12.1469. Это крайне важный симптом. Дело в том, что в ветке 8.3.12 (особенно в ранних сборках) был зафиксирован программный баг, связанный с некорректной работой менеджера блокировок в управляемом приложении.
Система ошибочно пытается дважды инициировать процедуру снятия блокировки при закрытии транзакции записи или теряет контекст блокировки в момент обращения к серверу приложений. Рассмотрим подробнее: когда вы открываете форму объекта, 1С устанавливает «пессимистическую» блокировку. При записи данных должна произойти смена типа блокировки на транзакционную, а затем её полное снятие. В проблемных релизах этот механизм «ломается», и к моменту финального вызова метода снятия блокировки платформа считает, что объект уже свободен — отсюда и текст ошибки.
Решение: Рекомендуем обновить платформу до актуальных стабильных релизов (например, последних версий 8.3.22 или 8.3.23). Если переход на новые ветки невозможен, установите хотя бы финальный релиз из ветки 8.3.12 (8.3.12.1529 и выше), где многие ошибки управления сеансами были исправлены.
Если вы перешли на SQL Express 2014 или любую другую версию MS SQL Server и развернули базу из DT-файла, обязательно проверьте состояние настройки READ_COMMITTED_SNAPSHOT. По умолчанию в новых базах SQL эта опция выключена.
Для 1С:Предприятия работа без включенного RCSI может приводить к тому, что транзакции чтения блокируют транзакции записи более жестко, чем того требует логика управляемых блокировок 1С. Это создает условия, при которых менеджер блокировок сервера приложений 1С входит в диссонанс с состоянием таблиц в самом SQL.
Разберем по шагам, как проверить и включить этот режим. Выполните следующий скрипт в SQL Management Studio:
-- Проверяем текущее состояние (0 - выключено, 1 - включено)
SELECT name, is_read_committed_snapshot_on FROM sys.databases WHERE name = 'ИмяВашейБазы';
-- Если значение 0, включаем режим (требуется монопольный доступ)
ALTER DATABASE [ИмяВашейБазы] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
ALTER DATABASE [ИмяВашейБазы] SET READ_COMMITTED_SNAPSHOT ON;
ALTER DATABASE [ИмяВашейБазы] SET MULTI_USER;
Важно: Перевод базы в SINGLE_USER необходим, чтобы разорвать все активные соединения перед изменением настроек. После выполнения этих команд механизм блокировок на уровне SQL станет более «дружелюбным» к платформе 1С.
Иногда корень проблемы кроется в настройках конкретного объекта метаданных. Посмотрим на свойства справочника Номенклатура или документа, в котором возникает ошибка. Существует два режима: Автоматический и Управляемый.
В современных конфигурациях (ERP, БП 3.0) практически везде должен быть установлен Управляемый режим. Однако, если при разработке или в расширении для какого-то объекта был случайно оставлен Автоматический режим, это приводит к конфликту. На SQL-версии 1С пытается управлять блокировками через свой менеджер, а SQL Server параллельно накладывает свои блокировки на уровне страниц или таблиц. Этот конфликт часто манифестируется как ошибка снятия блокировки.
Проанализируем ситуацию: если ошибка возникает в расширении, убедитесь, что в свойствах расширения режим управления блокировками совпадает с основной конфигурацией.
При переходе на новую платформу и сервер часто забывают о «чистоте» рабочего каталога сервера 1С. Старые кэши могут содержать неверные индексы или описания структур, что ведет к ошибкам при обращении к объектам. Хотя автор темы упоминал, что сервер новый, разберем этот момент для общего случая.
Посмотрим, как правильно выполнить глубокую очистку:
1C:Enterprise 8.3 Server Agent.C:\Program Files\1cv8\srvinfo (или ваш путь к данным сервера).snccntx* и временные файлы внутри папки вашей базы (каталог с UID базы).Также проверьте в консоли администрирования 1С наличие «спящих» или «фантомных» сеансов. Если один и тот же пользователь «завис» в базе, его старый сеанс может удерживать объект, а новый сеанс будет пытаться его модифицировать, вызывая ошибку при попытке финализировать запись.
Выясним еще одну неочевидную причину — недостаток прав пользователя, под которым работает служба SQL Server. При записи объекта 1С активно использует временную базу TempDB. Если на новом сервере TempDB имеет жесткие ограничения по росту или диск переполнен, транзакция может быть прервана со стороны SQL без внятного уведомления сервера 1С. В итоге сервер приложений 1С считает, что он должен снять блокировку, но транзакция в SQL уже откатилась или находится в неопределенном состоянии.
Что нужно сделать:
USR1CV8 (или того, под кем запущен сервер 1С) есть права db_owner на базу данных.TempDB имеют достаточно места для автоматического расширения.rphost.exe, sqlservr.exe и каталоги с базами в исключения антивируса. Сетевые задержки при проверке пакетов антивирусом «на лету» часто становятся причиной разрыва связи между 1С и SQL в критический момент фиксации транзакции.Мы рассмотрели основные причины возникновения ошибки снятия блокировки. В 90% случаев для связки 8.3.12 + SQL 2014 решением является:
Если эти меры не помогают, следует выполнить тестирование и исправление информационной базы, а также проверить базу на наличие дублей в таблицах блокировок (через выгрузку/загрузку в DT). Помните, что стабильная работа с блокировками в 1С возможна только при полном соответствии системных настроек и актуальности программного обеспечения.