I have to import a stored procedure from Oracle database into Informatica.
But when I try to use the Stored Procedure Transformation I cannot view the respective stored procedure.
I am using the correct oracle driver since I don't have any trouble in importing target database tables.
I tried viewing the stored procedures in the oracle database using
select * from all_objects where object_type='FUNCTION' but could not find the
function I am looking for.
Please advise me on these:
Can we view the list and code of Stored procedure(s)/function(s) in Oracle
What am I missing in Informatica stored procedure transformation?
If you don't get any results from this..
select * from all_objects where object_type='FUNCTION'
It either means you don't have any functions or the current user does not have the privileges to execute any functions. Find out which user owns the function and grant the following.
example :
grant execute on <owner>.<function_name> to ETL_USER;
To avoid confusion, make sure the username in the informatica connection and the one you are using when connecting to the database are the same.
While importing object into Informatica, listed objects are always owned by the "connecting" user. If your object is owned by some other user, you wont see it. To see objects not owned by connecting user, you'd have to choose "All" in the schema text box, while connecting.
You should be looking for object_type='PROCEDURE' and not "FUNCTION". Therefore, your query should read as select * from all_objects where object_type='PROCEDURE'
If all this is done and you still dont see the object, check privileges on that object to your connecting user. For this, the best course is
a. ask your dba to grant execute privileges on that object to your connecting user. OR
b. connect to database as the owner of that object and run the following command
grant execute on <object_name> to <connecting_user>
Related
I would simply like to allow a colleague to view and edit the Database I've created.
I've tried:
GRANT ALL on FISHTABLE to CDEMARES;
and it returned Grant succeeded but nothing changed for him and he still wasn't able to view my table.
I also tried
GRANT SELECT smahala.fishtable to cdemares#sole.nefsc.noaa.gov;
but that failed with SQL Error: ORA_00990: missing or invalid privilege.
Is my issue that I don't have the administrative authority to allow someone else to view my Oracle table? Any advice is appreciated, thanks.
Your colleague needs to prefix your table with your schema name, otherwise Oracle doesn't know where to look for it, e.g.:
select * from smahala.fishtable
If they don't do that, and simply try to use:
select * from fishtable
then Oracle will look for the table in their own schema, and then look for a view, or a private synonym, or a public synonym. Your colleague could create a synonym if they'll be accessing this table a lot (and they don't have their own table with the same name). It's also possible to change their session's current schema, but that will make it harder to see their own objects.
You can read more about object naming and how to refer to objects in the documentation.
SQL Developer allows you to browse objects in other schemas. If your colleague was connected when you granted the permissions, they can refresh the object list, or disconnect and reconnect. Either way they should then be abke to see your table under your schema.
(Your second grant statement is missing an on, and you can't grant permissions across a database link, if that's what you're trying to do.)
I am using Oracle 11g. I am successfully extracting DDL of database using userA account who created database tables, SP, Functions etc using getddl() method.
Now here is a case userA has shared / grant some action (ie. select) to userB account. and When I tried to get DDL details using same getDDL method, it is not including that shared tables.
To resolve it I used following.
SELECT * FROM USER_TAB_PRIVS;
Statement. Using this I can get list of all shared table with some unknow system tables details.
Now I am looking for the solution which either gives only shared tables or a way using that I can ignore (filter) that tables
FYI: When I am executing the above query it gives this output.
As expected it returns data related to all tables including system tables and all users created in the database including system generated users.
So can please anyone help me to create a query which will give me data related to privileges granted to all the users created manually and not by system?
To get the list of all privileges given to USER_2 from USER_1, you can use the following query.
SELECT * FROM SYS.USER_TAB_PRIVS T WHERE T.GRANTOR = 'USER_2';
I want to get a a list of procedures in an Oracle database which a particular user has access to.
Lets say I have user scott which is owner of 10 procedures.
user scott has given all privileges to user xxx for some of these procedures.
Now is there any query through which I can find all such procedures which user 'xxx' can access?
There are multiple permissions that can be given, so the following query will depend on what you want to test,
but generally :
select * from all_procedures
Will provide the list of the procedures the current user has any permissions on (if to compile, and if to execute).
I have an oracle database shared by both an internal application and our website.
I know very little about oracle so will explain things how I understand it..
The database has two users APPUSER and WEBUSER when logged in (using Oracle SQL Developer) as APPUSER you can see all the tables in the database. When logged in as WEBUSER you cannot see anything but a couple of procedures, the APPUSER cannot see these procedures.
One procedure starts with:
create or replace PROCEDURE "UPDATE_DETAIL"
(v_ref IN APPUSER.DETAILS.REFERENCE%TYPE
,v_desc IN APPUSER.DETAILS.DESCRIPTION%TYPE
...
Line 2 has a red squiggly with "PLS-00201: identifier APPUSER is not declared"
I believe it has the "APPUSER.TABLE.COLUMN" because WEBUSER does not have direct access to the tables.
I have executed GRANT ALL ON UPDATE_DETAIL TO APPUSERlogged in as WEBUSER, but that did not fix the issue, WEBUSER is the owner of the procedure, but does not have anything listed in the Grants list (I assume because owner just has the rights be default?)
The Dependencies list for the procedure is also empty, but cannot find how to manually add one to it.
Not sure what else to try to fix this error.
Thanks.
If you want a procedure owned by WEBUSER (and I believe from your description that UPDATE_DETAIL is owned by WEBUSER) to reference objects owned by APPUSER, you would need to grant WEBUSER privileges on those objects. For example, as APPUSER
GRANT SELECT ON appuser.details
TO webuser;
This assumes that WEBUSER only needs to SELECT from the APPUSER.DETAILS table. If your procedure needs to INSERT, UPDATE, or DELETE data in that table, then WEBUSER would need to be granted additional privileges on the APPUSER.DETAILS table. You'd need to make similar grants for every table in APPUSER that the WEBUSER user needs to reference.
We want to grant a user execute on a stored procedure which will access certain tables, but prevent that same user from performing a direct query on the same tables.
Here is our current model. User foo is the owner of the stored procedures. It has direct select, insert, update, and delete privileges on all the necessary tables. The stored procedures have been created with AUTHID CURRENT_USER. Foo grants execute on its stored procedures to user bar.
User bar calls the stored procedures via the grants above. By design, it has no ability to change the source code of any stored procedures. It has access via a role to the necessary tables.
So far, that works fine. Now we have a new requirement. A new user must be created that can execute the stored procedures, but cannot directly query against the tables (via SQLPlus, JDBC, ODBC, etc.)
I can't see any obvious way to implement this. All suggestions are welcomed.
If the procedures that foo owns were defined as authid definer, the default, then callers would not need privileges on the underlying tables in order to execute the stored procedures. Normally, that is how privileges are managed in Oracle. It is somewhat uncommon to use authid current_user stored procedures because that forces the caller to have privileges on the stored procedure in addition to privileges on the underlying table.
You'll either need to modify your existing procedures so that they are definer's rights stored procedures or you'll need to create a separate set of definer's rights stored procedures that you give the new user access to.