В ASA 9.0.1 убрали префикс для временных таблиц. Как теперь быть с правами доступа?

Раньше у нас было так. Временная таблица, заведенная пользователем Z заполнялась в функции Y.f(), заведенной группой Y, потом данные из временной таблицы использовались вне функции Y.f(). Z говорил: declare local temporary table Y.#tbl(...), потом вызывал функцию Y.f() и никаких проблем не возникало.

Теперь не работает. При вызове Y.f() ASA говорит что нет прав доступа на таблицу #tbl, которая по-видимому интерпретируется как Z.#tbl. grant для временной таблицы не работает. Что делать?

Версия: ASA 9.0.1 1862.

Дело в том, что все как раз работает согласно документации.

Вопрос только как обратиться к временной таблице от имени другого пользователя и при этом не получить ошибку доступа. Раньше можно было просто создать временную таблицу с "owner name" того пользователя, который будет обращаться, а теперь как?

Пока решили создавать вызывающую функцию от имени пользователя, который создает временную таблицу. В этом случае с правами все нормально. Хорошо этот пользователь пока один, а если их станет несколько, то на каждого прийдется создавать функцию и эти функции будут одинаковые за исключением "owner name". Это не хорошо.

Спасибо за ответы, будем бороться.

Поясняю. Имеет место OLTP система, все ходят через одного пользователя, поэтому сессий много. Локальная временная таблица создается внутри сессии, заполняется процедурой, потом используется в относительно сложном запросе. Это все вместо отсутсвующего на сегодняшний день full text search. Таблица хранит id слов, введенных пользователем, а процедура сопоставляет словам их id согласно словаря и заполняет таблицу. Запрос получается статический. Все это конечно в пределах одной сессии.

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

Слова поступают в процедуру по одному, т.е. процедура вызывается много раз, поэтому воспользоваться советом White Owl, к сожалению не получится: если создать таблицу в процедуре то при выходе она убъется.

Можно использовать обычную таблицу и id сессии, он у нас есть. Но тогда изменения будут писаться в лог, это ни к чему, мне казалось что с временными таблицами будет быстрее. Плюс запросы получаются проще.

2 ASCRUS
Поскольку система OLTP, то строилась с постоянной мыслью о безопасности, хоть сервер и спрятан глубоко внутри системы. Поэтому групп пользователей несколько, по одной на каждый класс допустимых действий в базе: одна для веб сервера с middle tier, одна для нашего файл сервера. Права этих пользователей ограничены, каждый имеет доступ только к своим объектам БД (точнее только своей группы), функциональность которых тоже ограничена соответсвенно. Пусть теперь о безопасности болит голова у сервера. По-моему это проще чем запоминать в базе кому на какую функцию или представление выдать права, по крайней так мере привычнее для меня.

Группы были введена чтоб потом не морочить себе голову с доступами отдельного пользователя - добавил пользователя в группу и все. Пока что пользователь в веб серверной группе один, скорее всего так и останется, так что наше временное решение будет нормально работать и в будущем.

2 White Owl

>Так же, если создать локальную таблицу перед вызовом процедуры, но в той же сессии - процедура эту таблицу увидит. И сможет заполнить/изменить ее.

Так и делалось раньше, но теперь если владелец процедуры не совпадает с владелцем временной таблицы, а у нас всегда так и есть, таблица не заполняется.

Первый и последний предложенный варианты не подходят, поскольку тогда парсить пришедшую фразу нужно на сервере, чтоб таблица не вышла за область видимости. Я этого делать не хочу во-первых потому что парсер уже есть в middle tier и все довольны, а во-вторых прасер на ватком скл писать как-то не улыбается.

2 ASCRUS

>Все правильно, но владельцами обьектов то зачем всех делать ? Есть у меня DBA, все обьекты принадлежат ему. Есть у меня группы пользователей. В них расписаны гранты.

Не всех, еще есть группы не являющиеся владельцами объектов. Если все принадлежит ДБА, то нужно где-то, скорее всего в базе, держать информацию о том какой группе какой доступ к какому объекту выделить, а при добавлении нового объекта нужно не забыть прописать о нем информацию в это хранилище. В нашем подходе группа связана с объектами очевидным образом - по префиксу, права выдаются/забираются всем сразу простым скриптом. К другим объектам БД у группы непосредственного доступа нет, вероятность ошибки минимальна.

>И кстати локальные временные таблицы нормально работают, без таких вот заморов:

Когда начинали строить БД на ASA 8 и даже перешли на 9.0.0 таких проблем не было. Теперь это проблема. Кто ж знал. Но все равно по-моему проблема не очень большая. Пока мне кажется что наше решение проще.