Can't see package body in SQL Developer version 3.1

Question

Hello,
Have been scouring the boards and google for this issue for quite some time now. I think I have discovered the issue, but would like to see if a work around exists.
Problem:
I am unable to view packages, procs, VIEW DDl, etc. of other users. When a colleague of mine uses Toad, with the EXACT same connection ID and setting, they are in fact able to see all the source code...
What I've found:
Looking around, apparently Toad and SQL Dev work in different ways. Toad apparently uses DBA_SOURCE and DBA_OBJECTS to generate everything.
SQL Dev uses the META_DATA package to retrieve everything. Further, in order to use the meta_data package, I need the grant catalog role, or something like that.
Is there a way to set up SQL Developer to use the same method as Toad to retrieve the code? It's a fact that I WILL NOT receive the catalog permission per the DBAs... I can write out the
select text from DBA_SOURCE where OWNER = 'OWNER' and NAME = 'OBJECT NAME';
But, I would prefer to just be able to use the tree nodes and click on objects to generate all this. Anyone know of any setting for this?

Answer 1

Hi,
No doubt SQL Developer wants to be competitive with Toad but, in terms of raising red flags over inconsistencies in basic functionality, any difference versus SQL*Plus would be more surprising than versus Toad.
DBA_SOURCE and DBA_OBJECTS are public synonyms available in any standard Oracle installation, but you also need the SELECT ANY DICTIONARY privilege to get maximum benefit from them. That lets you view code in another user's schema without having an explicit privilege (like EXECUTE) on a package/procedure/function.
If you already do have such privileges (either SELECT ANY DICTIONARY, or EXECUTE or DEBUG on specific executable objects), and the Code tab is empty, then you will need to provide a test case, as Vadim indicates.
In terms of any case where SQL Developer utilizes DBMS_METADATA, my understanding is the API relies on the SELECT_CATALOG_ROLE privilege if a user does not own or otherwise have an explicitly granted privilege on an object. Developers like to use this API wherever possible in place of writing a script that might break or need maintenance to deal with future versions of the Oracle database.
I have no idea how Toad works, and I probably shouldn't speculate, but here is one scenario that could explain the case you mention without the connection user having any of the privileges noted above. Let's say the Toad client software calls a PL/SQL package that selects from DBA_SOURCE and is installed in a schema that has the SELECT ANY DICTIONARY privilege. All Toad users are granted EXECUTE on this package and therefore inherit SELECT ANY DICTIONARY in the context of running the package. This will work, but at the price of complicating installation of Toad. Also, it doesn't afford an administrator fine-grained control over metadata security.
Regards,
Gary
SQL Developer Team