SQL Developer - To see or not to see MAT VIEW LOGS

Имеется SQL Developer 1.5.1 под MS Windows XP и куча оракловых баз 9i.
Везде заведены MATERIALIZED VIEW LOGS на часть таблиц в другой схеме.
На рабочих базах подключаюсь с логином у которого права SELECT ANY TABLE и SELECT ANY DICTIONARY.
На базе для разработки с тем же логином + права DBA.

Когда я выполняю SELECT * FROM DBA_TABLES WHERE OWNER = '....' AND TABLE_NAME LIKE '%MLOG%' то вижу MAT LOG-и во всех базах.
А в дереве SQL Developer-а на рабочих базах MAT LOG-и не видно, только в базе для разработки.

Кто-нибудь в курсе этой фичи? Это в какой-то дополнительной привилегии дело или в особенностях SQL Developer-а все-таки? (Почему-то склоняюсь к первому варианту.)

Создал тестового пользователя дал права
grant connect to dwh_t;
grant create session to dwh_t;
grant select any dictionary to dwh_t;
grant select any table to dwh_t;

Подключился под этим пользователем в SQL Developer к базе для разработки - MAT LOG-и в дереве видно.
Права те же самые, что и у пользователя в рабочих базах, у которого в SQL Developer MAT LOG-и в дереве не видны. Загадка, однако, мистика.

RENO4

Кто-нибудь в курсе этой фичи? Это в какой-то дополнительной привилегии дело или в особенностях SQL Developer-а все-таки? (Почему-то склоняюсь к первому варианту.)

Учитывая глюкавость SQL Developer я бы склонился ко второму варианту

Gleb Reutov

RENO4 Кто-нибудь в курсе этой фичи? Это в какой-то дополнительной привилегии дело или в особенностях SQL Developer-а все-таки? (Почему-то склоняюсь к первому варианту.) Учитывая глюкавость SQL Developer я бы склонился ко второму варианту

Ко всему вышесказанному еще одно дополнение.

Команда
select * from dba_tables where owner = 'myuser' and table_name like 'MLOG%';
выдает ответ на всех базах.

А вот команды
desc advwm.mlog$_art_ref
select * from advwm.mlog$_tablename;
дают ответ только на базе для разработки,
а на рабочих - ERROR: object MLOG$_TABLENAME does not exist

RENO4

дают ответ только на базе для разработки, а на рабочих - ERROR...

Отчего бы вам не озвучить версии рабочих баз и баз разработки?!
А то "куча оракловых баз 9i" звучит как-то уж слишком обобщенно...

Проблему удалось решить. Увы, это, действительно, был глюк SQL Developer, причем изощренный.
Лечится удалением скофигурированного соединения и конфигурированием нового с другим именем.

Вот такие дела. :(