Доступ к журналу для пользователей

[Sokolov]

Как можно обеспечить доступ к журналу (а точнее до таблицы x$journal) для простых пользователей на платформах Oracle и MS SQL? Если используется модуль права доступа.

[cruger]

Через Атлантис - никак.
А зачем?

[Sokolov]

Через Атлантис - никак.
А зачем?

Уже у второго клиента возникает потребность запускать отчет из под пользователя, который должен выполнять запрос по таблице x$journal.
И понятно - администратору выводятся данные по запросу, а пользователю - пустая таблица.
1? Можно или нет дать права пользователю средствами администрирования СУБД для получения данных для конкретного пользователя по журналу - или это нельзя сделать?
2? Если можно, то каким образом?

[cruger]

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

Права обычному пользователю никаким образом дать не удастся.

[hope]

Поддерживаю потребность пользователей в доступе к таблице x$journal.
Например, нужно сделать анализ: как менялись цены в прайс-листе. У пользователя права на прайс-лист есть. Но анализ изменения цен он сделать не может, т.к. нет доступа к таблице x$journal.

[kroxa]

мне кажется нужно делать доступный для прикладников второй механизм (наверное он должен использовать журнализацию) но API должно быть немного другим (например содеражать и типовую визуальную часть). Дело в том, что независимо от того используется журнализация или нет, прикладная функция должна работать... ну или хотя бы выдавать сообщение "просмотр истории изменения [цены] недоступен в виду отсутствия журнализации". это должен быть некий системный API, а предоставлять прямой доступ к системной таблице напрямую неправильно.

[cruger]

А кто будет проверять, имеет ли пользователь права на доступ к данным журнала? И как разруливать протектные фильтры? Типа, новое состояние (удовлетворяющее протектным фильтрам) видно, а старое состояние - нет? А ведь ещё разруливать права на поля (совсем не журнала, но ограничивать придётся по журналу).
Тут, сдаётся мне, глюков будет больше чем пользы.

Штука в том, что как обычно - механизм (журнализация) делалась для одного, её пытаются попользовать для другого. Неудобно, вот и возникают такие предложения.

А если сделать, то возникнут другие неудобства. Сходу: такую историю захочется видеть за длительный промежуток времени. Стало быть придётся в БД хранить большой журнал. БД будет расти, клиенты жаловаться на необоснованный рост БД и торомоза... Сходу предвижу следующее предложение: сделать чистку журнала настраиваемой потаблично, ;)
И ведь это только начало.

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

Давным давно стоит задача возможности хранения истории изменений каких-то ключевых полей определённых таблиц. Совершенно без привязки к журнализации. Ибо нужно это для другого.

История изменений фамилий сотрудников, названий контрагентов...

В общем - это отдельная задача, и решать её надо отдельно. А журнал оставить в покое: он работает так, как и должен работать для решения поставленных перед ним задач.