Is there a way to rename an oracle procedure, without having to drop and recreate the procedure?
UNfortunately there is no equivalent of ALTER TABLE ... RENAME TO for PL/SQL objects. So I'm afraid you will have to drop the procedure and create it afresh with the new name....
... unless using a SYNONYM will resolve your bind. Without knowing why you want to change the procedure name it's a bit difficult to give advice.
A way around this would be using a procedure inside a package. Then you might use CREATE OR REPLACE PACKAGE ... and CREATE OR REPLACE PACKAGE BODY ... to achieve your goal.
There is no way to rename a procedure unless you drop and create it again. Anyway:
If you have a lot of procedures you'd have to use PACKAGEs instead of PROCEDUREs. In this way you'd only need to change the PACKAGE BODY.
If your problem is to recreate the grants you can create easily an script to do it querying DBA_TAB_PRIVS (yes, also contains privileges for procedures).
You can effectively rename a Procedure by simply creating another procedure - with the new name - that simply calls the old procedure
create or replace procedure new_procedure_name
as
begin
old_procedure_name;
end;
Related
I am working on PL/SQL block where I need to read from the test-file, bulk collect and pass it as a parameter to other procedure.
The challenge I am facing is I have only procedure execute access, and I will be allowed to create the procedure which I am writing. (don't have permission to create External table )
steps
Read file,
bulk collect,
call proc_2(cursor)
please suggest me what is the best approach.
Thanks in Advance.
I am new to creating packages, I have to include a procedure and a function in a package,
I will create a package by declaring its head and body, Body will contains details about procedure and function.
My query is, after package is created, do I need to create that procedure and function again outside? i.e Create and Replace procedure ...and all?
No. You just define the procedure in the package body.
A procedure can either be a stand-alone procedure or it can be part of a package. In real systems, you almost never want to have stand-alone procedures. It virtually always makes sense to put related procedures together into packages to better organize them.
I got a scenario like this, I have an existing procedure that looks similar to this.
PROCEDURE A_DATA_B( p_ID IN SCHEMA1.TABLE1.ID%TYPE,
p_MATCH IN SCHEMA1.TABLE2.MATCH%TYPE,
p_STATUS IN SCHEMA1.TABLE3.STATUS%TYPE,
p_MSG IN SCHEMA1.TABLE1.MSG%TYPE,
The list goes on...
The SCHEMA1 was residing in the same database previously. Now this needs to be moved to another database in different server as such. But the schema name goes to be different but the Table name and the column name remain the same.
So I changed the procedure to look like this
PROCEDURE A_DATA_B( p_ID IN SCHEMA2.TABLE1.ID%TYPE,
p_MATCH IN SCHEMA2.TABLE2.MATCH%TYPE,
p_STATUS IN SCHEMA2.TABLE3.STATUS%TYPE,
p_MSG IN SCHEMA2.TABLE1.MSG%TYPE,
The list goes on..
But when I compile I got the error
PLS-00201: identifier 'SCHEMA2.TABLE1' must be declared PL/SQL:
Declaration ignored
I can understand from this error that SCHEMA2 is not in the database which gives the error. So How should I tackle it?
In the package body where ever am using this SCHEMA2 has been followed by an #db_link. So can I make use of that db_link to solve this?
By looking in to some article I came to know that SYNONYM can also be used. So is this the right way to create a synonym will work?
CREATE SYNONYM SCHEMA2 FOR SCHEMA2#db_link;
Can Someone help me in this regards.
Notes : I may not be able to convert the %type to varchar2 or numbers etc..
Thanks In Advance..
Synonyms are created for objects, not schemas.
You can create synonyms for each table (object, view, etc.) in the local database and use that to declare your anchored types.
CREATE SYNONYM schema2.table1
FOR schema1.table1#db_link
CREATE SYNONYM schema2.table2
FOR schema1.table2#db_link
CREATE SYNONYM schema2.table3
FOR schema1.table3#db_link
The %TYPE referencing items you use as subprogram parameters can point to remote objects through a Database Link by adding the #DBLINK_NAME clause, e.g.:
PROCEDURE A_DATA_B( p_ID IN SCHEMA2.TABLE1.ID#DBLINK_NAME%TYPE,
When building a deploy script for a Visual Studio 2010 SQL database project, is there any way to instruct the process to use DROP and CREATE for stored procedures and other DML instead of always ALTERing them?
As an example, if I change a stored procedure, the deploy script will generate something like this...
ALTER PROCEDURE MyProc
AS
SELECT yadda...
I want the deploy script to create something like this instead
IF EXISTS MyProc
DROP MyProc
CREATE PROCEDURE MyProc
AS
SELECT yadda....
It would make version controlled upgrade scripts a bit easier to manage, and deployed changes would perform better. Also if this is not possible, a way to at least issue a RECOMPILE with the ALTER would help some.
This question asks something that seems similar, but I do not want this behavior for tables, just DML.
I'm not familiar enough with database projects to give an answer about whether it's possible to do a DROP and CREATE. However, in general I find that CREATE and ALTER is better than DROP and CREATE.
By CREATE and ALTER I mean something like:
IF NOT EXISTS (SELECT 1 FROM INFORMATION_SCHEMA.ROUTINES
WHERE ROUTINE_NAME = 'MyProc'
AND ROUTINE_TYPE = 'PROCEDURE')
BEGIN;
-- CREATE PROC has to be the first statement in a batch so
-- cannot appear within a conditional block. To get around
-- this, make the statement a string and use sp_ExecuteSql.
DECLARE #DummyCreateText NVARCHAR(100);
SET #DummyCreateText = 'CREATE PROC dbo.MyProc AS SELECT 0;';
EXEC sp_ExecuteSql #DummyCreateText;
END;
GO
ALTER PROCEDURE dbo.MyProc
AS
SELECT yadda...
The advantage of CREATE and ALTER over DROP and CREATE is that the stored proc is only created once. Once created it is never dropped so there is no chance of permissions getting dropped and not recreated.
In a perfect world the permissions on the stored proc would be applied via a database role so it would be easy to reapply them after dropping and recreating the stored proc. In reality, however, I often find that after a few years other applications may start using the same stored proc or well-meaning DBAs may apply new permissions for some reason. So
I've found that DROP and CREATE tend to cause applications to break after a few years (and it's always worse when it's someone else's application that you know nothing about). CREATE and ALTER avoids these problems.
By the way, the dummy create statement, "CREATE PROC dbo.MyProc AS SELECT 0" , works with any stored procedure. If the real stored procedure is going to have parameters or return a recordset with multiple columns that can all be specified in the ALTER PROC statement. The CREATE PROC statement just has to create the simplest stored procedure possible. (of course, the name of the stored proc in the CREATE PROC statement will need to change to match the name of your stored proc)
Suppose you create a package in Oracle 10g and has defined a procedure and a function inside the package.
Now, How to delete a particular procedure or function in the package created, without physically DROPPING the package?? i.e. without using DROP PACKAGE package_name
I was wondering if i could actually perform the above action. Thank you in advance for any suggestions and solutions.
Since all objects in a package are stored as a unit, Oracle won't allow you to modify, drop or add packages or functions without replacing the whole package body.
You can find some discussion on the subject at the Oracle forums.