"Export User Objects" Enhancement request

[Ameen]

Hi
Current choices in Export-User-Objects window are:

* Single file
* File per object
* File per object/ Spec body in a single file.

It would by much nicer if the list contains :
* File per object type

so that all tables in one file, all grants in one file, all synonyms in one file ... etc. This can ease the management of large projects.

 

[Marco Kalter]

I have added this to the list of enhancement requests.

 

[Ameen]

It wold be better if you call these files in the following order (like Oracle Designer do):

*.tab for tables
*.vw for views
*.ind for indexes
*.con for constraints
*.typ for types
*.sqs for sequenses
*.pks packages spec
*.pkb packages body
*.prc procedures
*.fnc functions
*.syn synonyms
*.trg triggers
*.grt grants

this way it will eliminate the change to have invalid objects or even an error when running this script.
and finally it is even better to include an option to add a piece of code to compile all invalid objects (in all schema). I am using my own code to do this but it is better if it is there by default because I sometimes forget to add it at the end.

 

[Hilarion]

I do not see the materialized views on the list and they are particularly tricky on deployment. You are also missing type bodies, directories, java classes, etc.

Also if you view deployment scripts lack the FORCE keyword, then you may end up with views being missing when they rely on definitions of types, functions (including those in packages), synonyms or specific access grants.

I'd say to have packages, procedures, functions and synonyms first, as they will be created even when they rely on other objects and you can simply recompile them at the end using built in Oracle procedures. The views will also go into this category but remember to use FORCE keyword (and depending on the Oracle DB version used, you may need to have to write your own view recompilation scripts).

Raw tables (without constraints and indexes) are a safe step also (unless we are talking about index organized tables, etc.).

The materialized views should probably be split into two steps: creating a table for the MV (and this would be done at the same step as "normal" tables) and then the MV itself (probably as a last step or at least one of the last steps).

The rest probably depends on what you have and need.