Если Вы когда-либо создавали запросы SelectQuery с CustomSQL-колонками, Вы наверняка обратили внимание на то, что запрос, прекрасно работающий под учетной записью администратора может оказаться нефункциональным под учетной записью пользователя, если в CustomSQLColumn используются таблицы, администрируемые по записям.
При этом обращение к тем же таблицам средствами дизайнера отчетов вполне успешно. В чем же секрет?
Дело в том, что если таблица администрируется по записям, дизайнер запросов при работе под пользователем автоматически подставляет вместо нее представление. А поскольку CustomSQL-колонки вставляются в запрос как есть, в результате у пользователя нет доступа к таблице, и есть доступ к предоставлению.
Схема работы:
Для того, чтобы запрос работал корректно, следует в CustomSQLColumn использовать не таблицу, а ее алиас, заданный в блоке FROM. В случае необходимости - присоединить таблицу в одном из JOIN-ов и также обращаться по алиасу.
Есть еще один способ - сразу указать в CustomSQLColumn представление таблицы. Однако такой способ медленнее, кроме того, запрос станет нефункциональным, если Вы отключите администрирование по записям.
В любом случае, при создании запроса в дизайнере постарайтесь все то, что можно реализовать минуя SQL-колонки сделать штатными средствами, и использовать их только для не реализуемых вычислений.
В том, что сделано при помощи дизайнера, разработчики могут добавить дополнительные проверки, а за запрос, написанный в CustomSQLColumn отвечаете лично Вы.
"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)