MS SQL Ошибка 229: В разрешении SELECT на объект отказано
Иерархия прав SQL Server и суть ошибки 229
Ошибка уровня базы данных 229 «В разрешении SELECT (или UPDATE/INSERT) на объект 'Имя_Объекта', базу данных 'Имя_Базы', схему 'dbo' отказано» возникает, когда логин (Login), подключенный к MS SQL Server, пытается выполнить операцию, на которую у его связанного пользователя (User) внутри базы нет явных прав. Симптомы: внешние обработки или отчеты (Power BI, Excel, прямые SQL-запросы), которые лезут в таблицы 1С (например, _InfoRg123), возвращают пустой результат или падают с ошибкой. Сама 1С под служебной учетной записью при этом работает нормально. Бизнес-риски: остановка интеграций, поломка аналитических дашбордов.
Сравнение прав доступа (1С vs MS SQL)
| Уровень | Инструмент контроля | Кого касается |
|---|---|---|
| Прикладной (1С) | Роли в конфигураторе, RLS (Row Level Security) | Пользователи, заходящие в клиент 1С:Предприятие. |
| Системный (СУБД) | SQL Logins, Database Roles (db_datareader, db_owner) | Программы (1С Сервер, Power BI), обращающиеся к БД напрямую. |
Алгоритм настройки прав доступа в MS SQL Server
Сценарий 1: Выдача глобальных прав на чтение (db_datareader)
Если внешняя система должна только читать данные для аналитики (самый частый кейс), достаточно дать роль db_datareader.
- Откройте SQL Server Management Studio (SSMS).
- Разверните Security (Безопасность) -> Logins (Имена входа). Найдите логин интеграции.
- Дважды кликните по нему -> вкладка User Mapping (Сопоставление пользователей).
- Поставьте галочку напротив базы данных 1С.
- В нижнем окне ролей поставьте галочки public и db_datareader. Нажмите OK.
Сценарий 2: Точечная выдача прав GRANT (через T-SQL)
Политики ИБ запрещают давать доступ ко всей базе? Даем доступ только к одной таблице (или представлению).
Переключаемся на нужную БД
USE [Ваша_База_1С];
GO
Выдача права SELECT (Чтение) конкретному пользователю SQL
GRANT SELECT ON [dbo].[_InfoRg12345] TO [integration_user];
GO
Выдача прав на выполнение хранимой процедуры
GRANT EXECUTE ON [dbo].[SomeProcedure] TO [integration_user];
GOТиповые ошибки администраторов
- Использование SA или db_owner для интеграций: Давать внешним отчетам или скриптам полные права (sysadmin) на базу 1С — катастрофическое нарушение безопасности. Интеграции, которые только читают, ДОЛЖНЫ иметь только
db_datareader. - Путаница между Login и User: Login (Имя входа) дает право подключиться к самому инстансу MS SQL. User (Пользователь) живет внутри конкретной базы. Ошибка 229 говорит о том, что Login пустили на сервер, но его User внутри БД бесправен.
Прямая запись (INSERT/UPDATE) в таблицы SQL базы 1С в 99% случаев нарушает бизнес-логику (итоги не пересчитываются, триггеры 1С не срабатывают). Команда ITSTM проектирует безопасные интеграции (API, OData, HTTP-сервисы), которые работают на прикладном уровне 1С, гарантируя консистентность данных.
Частые вопросы (FAQ)
Почему под учеткой 'sa' всё работает без ошибки 229?
Учетная запись 'sa' (System Administrator) имеет серверную роль sysadmin. Она обходит все локальные ограничения баз данных и имеет абсолютный доступ (чтение/запись/удаление) ко всем объектам на сервере.
Как узнать, как называется нужный справочник 1С в таблицах MS SQL?
Таблицы 1С имеют нечитаемые имена (Reference12, Document34). Для получения структуры используйте встроенную функцию 1С ПолучитьСтруктуруХраненияБазыДанных() или скачайте сторонние утилиты-обработки для просмотра физической структуры ИБ.
Можно ли дать права на определенную схему (Schema)?
Да, базы 1С по умолчанию хранят все таблицы в схеме 'dbo'. Команда GRANT SELECT ON SCHEMA :: dbo TO [user] даст права на чтение всех существующих и БУДУЩИХ таблиц в этой схеме.
Влияют ли роли 1С (Бухгалтер, Кладовщик) на ошибку 229?
Абсолютно нет. Ошибка 229 — это уровень MS SQL. СУБД ничего не знает о ролях пользователей 1С, она проверяет только права SQL-логина, под которым подключился сервер 1С (или внешний скрипт).