What are the benefits of calling a stored procedure via its package name E.g. package.mystoredproc versus a direct call E.g. mystoredproc?
Does this give extra information to the calling code or is it just a good convention to use?
I've created a stored procedure which doesn't live in a package. I can execute the call without any problems however when the procedure was moved into a replicated environment where synonyms are used i ran into a problem whereby i had to include the schema name when calling the procedure.
Related
If there is a stored procedure across different schemas (SYS, User defined Schema), which schema would be called by default if we don't mention a Schema Name.
**Schema_1**
Sample_SP
**Schema_2**
Sample_SP
**SYS**
Sample_SP
execute Sample_SP
Which schema would be executed?
It depends on how you call the procedure. If you use the simple name (meaning: not prefixed by the schema name), then Oracle will only look in the current schema. To call the procedure from any other schema, you must use the qualified name. If you call the procedure using the simple name, and a procedure by that name does not exist in your schema, you will get an error - you will not get a "default" place to look in. And, of course, if you use a qualified name to call it from a different schema, but you don't have the required privileges, you will get an error as well.
You may also create a synonym, but that can only be pointed (in the synonym definition) to one of the procedures - in one specific schema.
If you are connected as user schema_1, then its procedure would be executed.
Others might, or might not ever be executed, depending on whether their owners granted you execute privilege on their procedures and whether there are (public or private) synonyms.
But, the bottom line is: first execute your own code, then - if it doesn't exist - search for it elsewhere.
It will execute the stored procedure from connected schema.
Stored procedure from SYS will be executed if there is no user defined schema is connected as SYS is default.
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.
Procedure for taking backup of procedures in toad oracle 12.1? I would also like to ask the difference between procedures and stored procedures
I would also like to ask the difference between procedures and stored procedures
A procedure is a subprogram that performs a specific action.
Oracle's documentation for CREATE PROCEDURE uses the term "standalone procedure" rather than "stored procedure" (but does state that it is stored in the db):
A standalone procedure is a procedure (a subprogram that performs a specific action) that is stored in the database.
A nested procedure is a procedure that is in a PL/SQL block or a package.
From the CREATE PACKAGE documentation:
The CREATE PACKAGE statement creates or replaces the specification for a stored package, which is an encapsulated collection of related procedures, functions, and other program objects stored as a unit in the database. The package specification declares these objects. The package body, specified subsequently, defines these objects.
Standalone procedures and procedures nested in a package are both stored (compiled) within the database - so are "stored" procedures. Procedures defined in an anonymous PL/SQL block are "nested" procedures but are not "stored" procedures.
This anonymous block defines a procedure which is not a stored procedure:
DECLARE
n NUMBER := 1;
PROCEDURE incr( a IN OUT NUMBER ) IS
BEGIN
a := a + 1;
END;
BEGIN
incr(n);
DBMS_OUTPUT.PUT_LINE(n);
END;
/
Toad has many ways to export that can be used to make backups of your objects. See the Database menu, Export sub-menu. Export DDL allows you to retrieve DDL for specific objects. Generate Schema Script will generate a complete script necessary to recreate an entire schema. You can also create actions for these tasks in the Automation Designer, available from the Utilities menu. Those actions can be scheduled. You can also add actions to zip the results, move them to another location (folder, ftp, email, etc.) You can create an "app" that will export the objects, zip the results, move them to another location, and email you when complete. There are many possibilities.
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.
I need to maintain state in a PL/SQL application. It needs to hold a small table during the session.
As I understand it, this is accomplished via a package variable, but I don't know how to create a table as a package variable.
Anyone explain how to do this or alternatives?
Expansion of Problem:
I have a WHERE IN condition that I must populate in a cursor at run time. Since to my knowledge I can only populate it with a hard-coded literal or a SELECT I need to hold all the IN's that are selected by the user during the session.
You define a variable with a table type in the package. If you want the state accessible from outside the package it is defined in the header - if you want it private then you define it in the body.
If you want to initialise the variable the first time the package is accessed then you use an initialisation block at the bottom of the package.
Some tips:
Be careful with exception handling when using initialisation blocks. If an exception is raised you need to ensure you use clear error messages or log messages. A maintenance programmer troubleshooting an issue may jump straight to the called method to troubleshoot rather than examining the implicit initialisation block.
Oracle can shuffle packages in and out of memory under various conditions at which point the package level variable is cleared. Ensure your state is required just for that session and that the session is fairly short lived (i.e not around for days). If you need more reliable persistence then use a physical table, not a package variable.
I often find a problem that starts out as being suitable for a package-level table usually grows more complex over time. It might be better to use a real table from an extensibility point of view. It depends on whether you are looking for a short-term solution for a simple problem or a long-term solution for a mission-ritical problem or a problem that will evolve over time.
Example using a simple "name-value" mapping table:
create or replace package bob as
procedure do_stuff;
end bob;
create or replace package body bob as
type my_table is table of varchar2(100) index by varchar2(100);
my_variable my_table;
procedure do_stuff
begin
--do stuff to my_variable
end;
begin
--initialise my_variable
end bob;
If you need to maintain state in your application, you can do this in a global table just as easily as a package-level table. The difference would be that the package table will not be accessible outside of the package.
From O'Reilly, we see that a table defined in the PACKAGE specification is considered global, but a table declared in the PACKAGE BODY specification is a package-level var.
A GLOBAL TEMP TABLE set to on Commit Preserve Rows that is setup as Key/Value can help in using the values throughtout the session not just within the package. SQL queries can then be built around IN or EXIST clauses with the table using access by the key.
Here is the Oracle Doc on Global Temp Tables