Доброго времени!
Имеется УТ 10.3.18, платформа 8.2.15.310.
При включении ограничения прав на уровне записей у всех кроме полноправных при сохранении объектов со свойствами (например нового контрагента или заказа покупателя) начинаются чудовищные зависания.
Обнаружено что 1С задумывается в обработке ЗначенияСвойствОбъекта в функции ПрочитатьТаблицуСвойствИЗначений при выполнении запроса.
При каждом обращении на несколько минут.
При записи контрагента туда попадает как минимум два раза - при записи контрагента и договора.
Конфигурация почти типовая (все изменения навешаны дополнительными объектами), менять типовые нельзя для полуавтоматического обновления.
Куда копать пока не знаю, посоветуйте пожалуйста, кто что может.

К этому же.
Регистр "Значения свойств объектов" не пуст. У контрагента есть свойство типа строка, длина 25, фиксированная.
У менеджеров право доступа к справочнику "Контрагенты" ограничено группами доступа к контрагентам.

а никто и не говорил что РЛС будет летать

Понятно, но чтоб так...
Не первая база в которой включено ограничение, нигде такого не было.

или с базой проблемы или в запросе налажал

(1) на запросы, которые обеспечивают работу рлс не пробовал смотреть? может у вас получиться скомбинировать работу с разграничением прав только по критичным для всеобщего пользования правам.

А вообще, ради права на чтение врубать рлс... я бы не стал

Файловая? Ну как бы это нормально

(4) Запрос типовой.
(5) Цель стоит ограничить просмотр контрагентов и документов назначенной группой доступа к контрагенту. Вроде другого варианта без внедрения в типовую нет.

(6) База еще небольшая, с июля работают.

(7) может групп уж слишком дофига?

(8) Да хоть пустая. Файловая и RLS несовместимые понятия

(9) Три. Причем хотят свести к одной (менеджеры видят только контрагентов-физлиц).

(10) Можно конечно проверки ради залить в MS SQL.

(12) Заливай. У меня в свое время включения RLS в файловой приводила к задержкам до 30 секунд при проведении ПКО задним числом

(12) в порядке буйной фантазии: написать свою обработку для сохранения этих объектов и избежать использования типового кода, который выходит на тромоза. откуда идет вызов тормозной функции? из модуля формы какой-то? или при из ПередЗаписью в модулях объектов?

У нас на типовой зарплате, сервер sql2000, при проведении документов выплаты зарплаты, со включенным RLS не проводятся документы.. одно и то же пытаются в регистр записать многократно (столько раз, сколько записей в документе), натыкаясь при этом на неуникальность ключа.. На файловой базе - нормально. Там есть запросик один, который некорректно транслируется платформой в TSQL, в результате запроса получается лажа. Ошибка проявляется даже на официальной демобазе ЗУП.. 1с это признала - но говорит "да, это ошибка платформы на sql2000 проявляется, а на sql2008 всё работает, переходите на него".

А вы про "тормоза на файловой версии".. всё гораздо печальнее!

(12)
Рад бы, да типовая конфигурация не позволяет.
Через подписку на события можно только не дать записать, а видеть все равно будут всех.

Стек вызовов:
Справочник.Контрагенты.Форма.ФормаЭлемента.Форма.ПриЗаписи
Справочник.Контрагенты.Форма.ФормаЭлемента.Форма.ОбновитьСвойства()
Обработка.ЗначенияСвойствОбъекта.МодульОбъекта.ПрочитатьЗаполнитьСвойстваИЗначения()
Обработка.ЗначенияСвойствОбъекта.МодульОбъекта.ПрочитатьТаблицуСвойствИЗначений()

(16) Это был ответ на (14).
(15) Угу, сталкивался с ошибками платформы, знаю что такое...

(13) Залил. В MS SQL все прошло без запинки.
Aleksey, большое спасибо за верную мысль.
Всем спасибо за участие!

(16) Понятно, что при возможности использования скуль-версии ошибку можно не замечать. Просто я как раз и ожидал, что стэк вызово окажется ровно такой, как он показан в (16). Это чистая заморочка типовой формы элемента. А если бы в стэке было видно использование такого же запроса в модуле объекта, то тогда никаких вариантов обхода не оставалось бы.

Можно написать свою собственную нетиповую форму элемента и рлс в данном конкретном случае не сработает, и тормоза при записи в форме не проявятся.