При обновлении технологической платформы 1С:Предприятие до версии 8.3.11 многие системные администраторы и разработчики столкнулись с неприятной ситуацией. Конфигурации, работающие в режиме совместимости с версией 8.1 (например, классическая Управление торговлей 10.3), перестают пускать пользователей под обычными правами. При попытке входа система выдает критическую ошибку У пользователя недостаточно прав на исполнение операции над базой данных. SDBL-команда: 'schema'. При этом пользователи с полными правами продолжают работать в штатном режиме.
В этой статье мы подробно разберем причины возникновения этой проблемы, проанализируем способы диагностики и рассмотрим несколько вариантов решения, от самого простого до наиболее правильного с точки зрения поддержки системы.
Давайте проанализируем ситуацию. Ошибка возникает на стыке двух факторов: использования платформы линейки 8.3.11 и режима совместимости 8.1. В журнале регистрации при этом фиксируется событие с правом Администрирование. Это говорит о том, что при старте системы платформа пытается выполнить низкоуровневую операцию со схемой базы данных (SDBL-команда schema), которая в данной версии платформы ошибочно требует административных привилегий.
Это классический случай регрессионной ошибки в коде самой платформы. Разработчики 1С в версии 8.3.11 изменили механизмы проверки прав при инициализации сеанса, что привело к конфликту со старыми режимами совместимости. Проблема носит массовый характер и не зависит от конкретных настроек прав в самой конфигурации — даже если у пользователя есть все необходимые роли, кроме ПолныеПрава, войти он не сможет.
Самый правильный и надежный метод — это установка версии платформы, в которой данная ошибка (баг 10188681) была официально исправлена. Рассмотрим, на какие релизы стоит ориентироваться. Согласно технической документации и опыту коллег, исправление вошло в релиз 8.3.11.3034 и все последующие сборки (включая ветки 8.3.12 и старше).
Если вы столкнулись с этой проблемой, выполните следующие шаги:
.dt).Если по каким-то причинам вы не можете оперативно обновить платформу на сервере, можно рассмотреть вариант изменения режима совместимости конфигурации в Конфигураторе. Участники обсуждения отмечают, что перевод базы в режим совместимости 8.2.13 или 8.2.16 снимает блокировку на вход. Однако этот путь таит в себе скрытые угрозы.
Давайте разберем, с какими сложностями мы можем столкнуться при смене режима совместимости. Основная проблема — ужесточение требований к языку запросов. Например, в режиме 8.2 и выше 1С более строго проверяет использование конструкции РАЗЛИЧНЫЕ (DISTINCT) совместно с УПОРЯДОЧИТЬ ПО.
Типичная ошибка, которая возникнет в модулях (например, при открытии списка номенклатуры), будет выглядеть так:
{Обработка.ЗначенияСвойствОбъекта.МодульОбъекта(62)}: Ошибка при вызове метода контекста (Выполнить)
по причине:
{(48, 2)}: В запросе с предложением РАЗЛИЧНЫЕ все поля, по которым происходит упорядочивание, должны присутствовать в списке выборки
Чтобы исправить это, нам придется переписывать запросы. Проанализируем пример. Если старый запрос выглядел так:
ВЫБРАТЬ РАЗЛИЧНЫЕ
СвойстваОбъектов.Ссылка
ИЗ
Справочник.СвойстваОбъектов КАК СвойстваОбъектов
УПОРЯДОЧИТЬ ПО
СвойстваОбъектов.Наименование
То для работы в режиме совместимости 8.2 его необходимо привести к виду:
ВЫБРАТЬ РАЗЛИЧНЫЕ
СвойстваОбъектов.Ссылка,
СвойстваОбъектов.Наименование
ИЗ
Справочник.СвойстваОбъектов КАК СвойстваОбъектов
УПОРЯДОЧИТЬ ПО
СвойстваОбъектов.Наименование
Важное предупреждение: Помните, что обратный откат режима совместимости с 8.2 на 8.1 штатными средствами может привести к непредсказуемым последствиям для структуры данных. Всегда делайте бэкап перед такими манипуляциями!
Если инфраструктура позволяет, временным решением может стать возврат на платформу версии 8.3.10 или даже 8.3.8. Рассмотрим этот вариант как экстренный, когда нужно восстановить работу предприятия «здесь и сейчас», а времени на тестирование новых релизов нет.
Проанализируем шаги для безопасного отката:
8.3.8.2137), чтобы система не пыталась использовать более новую 8.3.11.ragent.exe.Чтобы в будущем быстрее локализовать подобные проблемы, рекомендуем настроить Технологический журнал. Рассмотрим минимальный конфиг logcfg.xml, который поможет увидеть подробности SDBL-ошибок:
<config xmlns="http://v8.1c.ru/7.4/config/logcfg">
<log location="C:\1C_Logs\SDBL" history="24">
<event>
<eq property="Name" value="SDBL"/>
</event>
<property name="All"/>
</log>
</config>
Проанализировав логи после неудачной попытки входа, вы увидите конкретный SQL-запрос, который вызывает отказ в доступе. Это позволит понять, действительно ли дело в платформенном баге или же в базе данных есть поврежденные таблицы метаданных.
Подводя итог, можно сказать: если вы используете Управление торговлей 10.3 или другие конфигурации на базе 8.1, старайтесь избегать первых релизов новых веток платформы. Оптимальным выбором для стабильной работы будет использование исправленных сборок, таких как 8.3.11.3034, либо переход на современные долгосрочные релизы (LTS), где подобные ошибки уже давно устранены.