Как исправить ошибку "Недостаточно прав на исполнение операции над базой данных" в УПП 1.3

← На главную

В процессе сопровождения конфигурации 1С:Управление производственным предприятием (УПП) ред. 1.3 на платформе 1С:Предприятие 8.3 (особенно при работе на СУБД MS SQL Server) администраторы и разработчики часто сталкиваются с крайне неприятной проблемой. У обычных пользователей, которые годами успешно выполняли свои обязанности, внезапно при записи или проведении документов (например, таких как Отчет производства за смену) начинает лавинообразно сыпаться системная ошибка: "У пользователя недостаточно прав на исполнение операции над базой данных".

Ситуация осложняется тем, что видимых причин для этого нет: права и роли пользователей никто не менял, настройки доступа оставались прежними, а Журнал регистрации (ЖР) показывает крайне скудную или противоречивую информацию. Давайте вместе подробно разберем, почему возникает эта ошибка, как ее локализовать с помощью отладчика и технологического журнала, а также рассмотрим по шагам три основных сценария ее решения.

Симптомы проблемы и первичный анализ

При анализе поведения системы выясняется, что ошибка происходит в транзакции записи документа. Если мы попробуем пройтись отладчиком, то увидим, что выполнение кода конфигурации успешно доходит до самого конца обработчиков события записи. В частности, в УПП 1.3 сбой часто фиксируется сразу после выполнения подписки на событие ПередЗаписьюДокументаРегистрацияОбъектаИнформационнойБазыПередЗаписью.

Рассмотрим код этой процедуры:


Процедура ПередЗаписьюДокументаРегистрацияОбъектаИнформационнойБазыПередЗаписью(Источник, Отказ, РежимЗаписи, РежимПроведения) Экспорт
    НужноРегистрироватьМестоСоздания = Источник.ЭтоНовый И ПараметрыСеанса.СохранятьИнформациюОМестеСозданияОбъектов;
    Источник.ДополнительныеСвойства.Вставить("НужноРегистрироватьМестоСоздания", НужноРегистрироватьМестоСоздания);
КонецПроцедуры

После выхода из этой процедуры платформа выполняет запись данных непосредственно в СУБД и производит проверку ограничений доступа на уровне записей (RLS). Именно в этот момент СУБД возвращает ошибку, транзакция откатывается, а пользователь видит системное сообщение об отсутствии прав. При этом отладчик не может показать конкретную строку кода, так как падение происходит на уровне платформы и СУБД.

Если временно отключить ограничение доступа на уровне записей (константа Ограничить доступ на уровне записей), ошибка исчезает. Это однозначно указывает на то, что корень проблемы кроется в механизме RLS (Record Level Security).

---

Сценарий 1. Конфликт RLS и настроек «1С-Отчетности» (Справочник учетных записей)

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

Выясним причину внезапного появления ошибки:

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

Решение проблемы на уровне пользователя/администратора:

Нам не требуется вносить изменения в конфигурацию. Достаточно правильно настроить права в режиме "1С:Предприятие":

Зайдем в базу под пользователем с полными правами.
Перейдем в раздел 1С-Отчетность (или откроем настройки документооборота через настройки параметров учета).
Откроем форму "Настройки обмена с контролирующими органами".
Найдем активную учетную запись документооборота и перейдем на вкладку "Пользователи" (или в соответствующий регистр сведений, отвечающий за связь пользователей и учетных записей).
Принудительно добавим в список тех пользователей (или группы пользователей), у которых возникает ошибка при сохранении документов.
Попросим пользователей перезапустить свои сеансы 1С для обновления параметров сеанса.

---

Сценарий 2. Ограничение прав на параметры сеанса и подписки событий

Второй частый случай связан с тем, что у базовых ролей пользователей (например, роли Пользователь) отсутствуют права на чтение служебных объектов метаданных, к которым обращаются общие подписки на события при записи.

Обратим внимание на параметр сеанса ПараметрыСеанса.СохранятьИнформациюОМестеСозданияОбъектов, который используется в подписке ПередЗаписьюДокументаРегистрацияОбъектаИнформационнойБазыПередЗаписью. Если у роли, назначенной пользователю, нет права на Чтение этого параметра сеанса, любая попытка записи нового документа приведет к аварийному завершению транзакции платформой 1С.

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

При записи документа срабатывает механизм авторегистрации изменений для планов обмена (например, для обмена данными с "1С:Бухгалтерия" или "1С:Розница").
Если в базе настроены планы обмена, но для одного из них некорректно задан предопределенный узел (элемент "Этот узел"), либо у пользователя отсутствуют права на чтение/запись таблиц регистрации изменений этого конкретного плана обмена, платформа заблокирует транзакцию.

Решение проблемы в Конфигураторе:

Выполним по шагам проверку прав в Конфигураторе:

Откроем конфигурацию и найдем роль, которая назначена всем проблемным пользователям (обычно это роль Пользователь или специализированная базовая роль).
В дереве метаданных роли перейдем в ветку Параметры сеанса.
Убедимся, что для параметра СохранятьИнформациюОМестеСозданияОбъектов установлена галочка "Получение" (Чтение).
Перейдем к ветке Планы обмена. Проверим, чтобы у пользователей были права на чтение планов обмена, участвующих в миграции данных, а также права на изменение таблиц регистрации (если это необходимо по логике обмена).
Если используется распределенная информационная база (РИБ), проверим в режиме "1С:Предприятие", чтобы у каждого активного плана обмена был корректно назначен предопределенный элемент ("Этот узел"). Если узел был случайно помечен на удаление или недосоздан, восстановим его структуру.

---

Сценарий 3. Баги платформы 1С при оптимизации RLS

Иногда ошибка начинает проявляться после обновления платформы 1С:Предприятие (например, при переходе на новые релизы ветки 8.3). В версиях платформы 8.3.12 и выше разработчики существенно изменили внутренние механизмы кэширования и оптимизации RLS-запросов к СУБД.

При наличии сложных ограничений доступа, содержащих вложенные запросы и соединения нескольких таблиц (как это реализовано в УПП для организаций, контрагентов и учетных записей), СУБД (MS SQL Server) иногда не может построить корректный эффективный план выполнения SQL-запроса или падает по таймауту. Платформа 1С перехватывает эту системную ошибку СУБД и транслирует ее пользователю в виде стандартного сообщения: "Недостаточно прав на исполнение операции над базой данных".

Решение проблемы с кэшем и версией платформы:

Очистим серверный кэш базы данных. Для этого остановим службу сервера 1С:Предприятие, перейдем в каталог расположения временных файлов сервера (обычно это C:\Program Files\1cv8\srvinfo\reg_1541) и физически удалим папки с кэшем базы данных (папки с длинными буквенно-цифровыми именами UID). После этого запустим службу сервера снова.
Обновим платформу. Если используется нестабильный релиз платформы, рекомендуется обновиться до актуального стабильного релиза (LTS-версии), где исправлены известные ошибки оптимизатора запросов RLS.
Переведем RLS в производительный режим. Если конфигурация позволяет, в настройках параметров учета переключим режим работы ограничений RLS на "производительный", который формирует более простые с точки зрения СУБД SQL-запросы.

Как детально расследовать подобные ошибки

Если вышеописанные методы не помогли сразу локализовать ошибку, применим профессиональный инструмент — Технологический журнал (ТЖ) 1С. Он позволит нам увидеть "сырой" SQL-запрос, на котором происходит сбой прав доступа.

Для этого создадим в папке настроек ТЖ (по умолчанию C:\Program Files\1cv8\conf) файл logcfg.xml следующего содержания:


<config xmlns="http://v8.1c.ru/v8/config/config.xml">
    <log location="C:\v8logs\RLS_Error" history="24">
        <event>
            <eq property="Name" value="DBMSSQL"/>
        </event>
        <event>
            <eq property="Name" value="EXCP"/>
        </event>
        <property name="all"/>
    </log>
</config>

После этого воспроизведем ошибку под пользователем. В каталоге C:\v8logs\RLS_Error запишутся лог-файлы. Мы сможем найти событие EXCP или неудачный запрос DBMSSQL, содержащий ключевые слова ограничений RLS (например, обращения к таблицам _ReferenceXX, соответствующим справочнику учетных записей или организациям). Это укажет на конкретную таблицу БД, доступ к которой заблокирован политиками безопасности СУБД или платформы.

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