I have 2 questions?

[sree_sri]

Hi Folks,
I have 2 questions, Any suggestions will help me.Thanks.

How do you know which procedure/function goes into a package?
How do you make procedure invisible?

Sree.

[kong]

Any func/proc can go into a package.
Func/proc are 'invisible' when they are private func/proc.

example:

create or replace package junk is
PROCEDURE do_nothing;
end junk;

create or replace package body junk is
FUNCTION my_private_func RETURN BOOLEAN IS
BEGIN
RETURN TRUE;
END;

PROCEDURE do_nothing IS
BEGIN
NULL;
END;
end junk;

[sree_sri]

Kong,
Please! That's not right, Some where on the web i got this information

How do you make procedure invisible?

A local module is a procedure or function that is defined within the declaration section of another module. The scope of a local module is the module in which it is declared. It is invisible to all other modules, and can be called only from within that defining module.

Folks, Is anybody have some more information to the above questions.

I know that any func/proc can go into a package. But what is the factors?
As per my knowledge the related(Logically) functions,procedures and other objects are kept in the one package. Like this any other specific reason is there. Please i need this information, Any suggestions will help me. Thanks.

[kris109]

I have seen huge ERM systems where packages are grouped based on funcationality, modularity, easy maintenance, reusabilityof the code and for consistency. For example an ERP system may have purchase orders, order entry, work orders, bill of materials, vendors, GL etc., Generally package is assigned for each of the modules and the procedures are created within that package. If the package gets too big, then 2 or 3 packages with similar names are used. It is not a big deal really. As the application grows, packages grow according to the need of the application.

Regarding your second question, any procedure that is defined in the body and not in the spec is PRIVATE to the package and is invisible.

[dave_young]

Using kong's example:

The package specification is:

create or replace package junk is
PROCEDURE do_nothing;
end junk;


The package body is:

create or replace package body junk is
FUNCTION my_private_func RETURN BOOLEAN IS
BEGIN
RETURN TRUE;
END;

PROCEDURE do_nothing IS
BEGIN
NULL;
END;
end junk;

The procedure do_nothing is public since the procedure do_nothing is referenced in the specification. The function my_private_func is private to the junk package since it is not listed in the specification.

[kong]

Another way of making a procedure/package/function 'invisible' is by 'wrapping' up the package:

prompt> wrap iname=junk.pkg oname=junk.wpkg

You can then compile junk.wpkg and viewing the package source will give garbled information. The package will still work as per usual though, you just can't 'see' it.