Если Вы когда-либо создавали запросы SelectQuery с CustomSQL-колонками, Вы наверняка обратили внимание на то, что запрос, прекрасно работающий под учетной записью администратора может оказаться нефункциональным под учетной записью пользователя, если в CustomSQLColumn используются таблицы, администрируемые по записям.

При этом обращение к тем же таблицам средствами дизайнера отчетов вполне успешно. В чем же секрет?

Дело в том, что если таблица администрируется по записям, дизайнер запросов при работе под пользователем автоматически подставляет вместо нее представление. А поскольку CustomSQL-колонки вставляются в запрос как есть, в результате у пользователя нет доступа к таблице, и есть доступ к предоставлению.

Схема работы:
selectquery

Для того, чтобы запрос работал корректно, следует в CustomSQLColumn использовать не таблицу, а ее алиас, заданный в блоке FROM. В случае необходимости - присоединить таблицу в одном из JOIN-ов и также обращаться по алиасу.

Есть еще один способ - сразу указать в CustomSQLColumn представление таблицы. Однако такой способ медленнее, кроме того, запрос станет нефункциональным, если Вы отключите администрирование по записям.

В любом случае, при создании запроса в дизайнере постарайтесь все то, что можно реализовать минуя SQL-колонки сделать штатными средствами, и использовать их только для не реализуемых вычислений.
В том, что сделано при помощи дизайнера, разработчики могут добавить дополнительные проверки, а за запрос, написанный в CustomSQLColumn отвечаете лично Вы.

Нравится

Поделиться

6 комментариев

"Alimova Anna" написал:

Есть еще один способ - сразу указать в CustomSQLColumn представление таблицы. Однако такой способ медленнее


Кроме того что он будет медленнее для Администратора, он еще почти всегда будет работать некорректно - так как будет проверяться доступ на записи, а как правило Администратору никто его не дает, он и так все "видит".

Ну, а самое забавное начинается, когда таблица начинает администрироваться по полям =)

Максим, и что же начнется? :)

В случае добавления безобидной колонки Account.Name
И удалении прав на чтение этой колонки:

TSObjectLibrary.DBDataset: Ошибка открытия источника данных "ds_Account". 
Оригинальное сообщение об ошибке: The SELECT permission was denied on the column 'Name' of the object 'vw_Account", database 'XXX', schema 'dbo'

Это потому, что она ключевая? о_О

И еще: как это обойти?

Нет, это потому, что на нее доступ запрещен на уровне БД в самой таблице(и как следствие во вьюхе). Ядро в таком случае колонки заменяет на NULL, чтоб к ним вообще обращение не шло.
Пока мне известен один способ обхода - создавать отдельную функцию и использовать в CustomSQLColumn:

fn_GetAccountNameByID(Account.ID)
Показать все комментарии