permissions required to describe package in toad 12.1.1.1 for Oracle

Using Toad 11.6.0.43 I am able to describe a specific package.

However using toad 12.1.1.1, I get Object not Found when trying to describe that same package.

Can you provide a list of minimum required permissions to successfully use Toad’s describe feature on a package in 12.1.1.1? And can you confirm that the requirements are different than they were in version 11?

thanks in advance.

-steve

Do you have “check for access to dba views” checked? If not, check it, restart Toad and try again.

If it is checked, are you logged in as the same user in Toad 12 as you did in 11.6?

I have seen this happen when describing an object in another schema and you are looking at the ALL_ views. You’ll see the package spec in ALL_OBJECTS but
won’t find the source in ALL_SOURCE.

From: steven.mahler [mailto:bounce-stevenmahler@toadworld.com]

Sent: Monday, April 28, 2014 7:36 AM

To: toadoracle@toadworld.com

Subject: [Toad for Oracle - Discussion Forum] permissions required to describe package in toad 12.1.1.1 for Oracle

permissions required to describe package in toad 12.1.1.1 for Oracle

Thread created by steven.mahler

Using Toad 11.6.0.43 I am able to describe a specific package.

However using toad 12.1.1.1, I get Object not Found when trying to describe that same package.

Can you provide a list of minimum required permissions to successfully use Toad’s describe feature on a package in 12.1.1.1? And can you confirm that the requirements are different than they
were in version 11?

thanks in advance.

-steve

To reply, please reply-all to this email.

Stop receiving emails on this subject.

Or
Unsubscribe from Toad for Oracle - General
notifications altogether.

Toad for Oracle - Discussion Forum

Flag
this post as spam/abuse.

Thank you John, ticking the “check for access to dba views” checkbox and restarting toad fixed the problem.

You’re welcome. Even without this problem, I’d recommend leaving this box checked because the DBA_ views are generally faster than the ALL_ views.

The only reason to ever uncheck it that I can think of is to possibly save some time on startup if you know that you aren’t going to have the SELECT privilege on any of these views anyway.