I've seen one but... what exactly is a 10g Package?

Scenario: I know nothing about packages except that they contain functions and procedures all wrapped into a nice little present. So today I was given this package (rather large) with the instructions of "here, this is broken please fix it".

I finally cleaned it all up, which brings me to my questions.

In the overall view of a package, that is going to be exported.

1) Other than a collection of everything does a package serve any other purpose?

2) To deploy this package do you need to set up the deployment space to already have all of the views/materialized views/ and tables that the package called? If not I am assuming the p开发者_如何学JAVAackage will fail to execute.

3) Can you code the package to skip functions and procedures it fails to execute on without bombing out?

4) When taking a package that successfully compiled in one place to another place what other things should I be aware of?

1) Other than a collection of everything does a package serve any other purpose?

Other than that, it reduces the need to recompile other procedures that are dependant on a specific procedure when the specific procedure is altered.

Consider an (ordinary, not package wise) procedure XYZ(a in number) that is called by many other procedures. If this procedure is altered, all the other procedures need to be recompiled which might reduce the availablity of the system.

On the other hand, if the procedure is declared in a package and defined in a package body and the procedure is changed in the body only, (almost) no recompiling takes place.

2) To deploy this package do you need to set up the deployment space to already have all of the views/materialized views/ and tables that the package called? If not I am assuming the package will fail to execute.

No, you can install a package body without the dependant views or tables in place. The state of the package body will then be INVALID and no functionality of the package body can be used.

3) Can you code the package to skip functions and procedures it fails to execute on without bombing out?

Not sure, what the question is exactly. If the state of the package body is INVALID, no code can be executed, hence no "bombing out" can happen.

However, if the bombing out occurs for a logical reason (such as a division by zero for example) you can always resort to the exception when others then construct.

4) When taking a package that successfully compiled in one place to another place what other things should I be aware of?

Again, not sure what you mean here. Could you elaborate what one place is? A schema? An instance? An installation, a company....?

1) Well you can almost think of a package as being analogous to a class. Its a logical grouping of related methods. It also allows you to encapsulate related "helper" methods that should not be used by anyone else. They can be included in the package and only accessible by member methods.

2) In order to successfully deploy a package, yes, you must have the necessary tables, views, etc. If they are not, its not a matter of the package not being able to execute any procedures or functions, it will not deploy properly. It will show up in the data dictionary as not compiled.

3) Define "bomb out". If the necessary objects exist to successful deploy the package, then everything else is a run time error - things that should be coded for. Think exception handling.

4) Again, the necessary schema objects referenced in your package must exist. If they do not, the package will not compile and will be marked as such in the data dictionary.

In addition to the other helpful answers above.

1) Package headers can also hold variables whose scope is not just to a proc or function.

2) If you are moving the package tables/views may not have to be copied if they are in the same database and the new schema has permission to see the old tables. or if a database link can be used to the database that contains the data. In some database versions there may be limits on using lobs across a database link. Tables in another schema need to be referenced {schema-name}.{table-name}. A database link is specified by {table-name}@{database-link-name}. Granting permission to a table in another schema will need to be done explicitly not through a role - thats just how oracle is

3. If you add: "exception when others then null; " as the 2nd last line in a proc (immediately before "end") it may do what you are after.

4) Grants/permissions/roles/sequences and possibly synonyms and other dependent procs/functions packages may be needed for the package to run. Actually any object in the original schema may be referenced in the package and may be needed or a grant on it may be needed..