Reverse Engineering after clearing repository.

Question

Hello - I am new to this tool, but gaining traction fairly quickly.
I have a team of developers. They're developing several applications and we have used designer to generate the ERD and the table structures (of course). Then, once the tables and the relationships are finalized we have been developing the PL/SQL in Toad without much more thought to the designer repository.
That was my mistake. I have been told that it is policy at my new place of business to generate ALL DML and DDL code from the designer repository when it is time to move from development to test (and test --> prod).
Since I was not operating under that assumption I need to synchronize the repository with the actual schema we are working in. Then it is my aim to keep it up to date as progress is made with the coding.
I have, from the Design Editor, deleted all of the objects from the repository. I then capture the design of the server model.
The captured server model produces a lot of enumerated stuff in the "Procedure Definitions" (like "CASCADE_DELETE1" through "CASCADE_UPDATE7") area that I have no explanation for. In our schema all procedures exist in packages. In the Server Model Navigator it does not appear to be so.
Can someone explain what I'm seeing, or can someone clarify whether or not I am completely clearing the Server Model from the Repository?
Edited by: KevinRyan on Jan 28, 2009 5:38 AM

Answer 1

Boy, I REALLY hate the way Designer stores PL/SQL in the repository. That is why we went back to maintaining all of our PL/SQL packages in files with TOAD. But you don't have that option, so here is how it works:
If you do a "Capture Server" for a PL/SQL package, each procedure and function in the package will become a separate module. That includes overloaded modules - that is where you get CASCADE_DELETE1, CASCADE_DELETE2 etc. Each of those is stored as a separate module, but if you look at the implementation name (one of the properties of the module), you will see that all overloaded versions have the same implementation name (probably CASCADE_DELETE, right?). If implementation name is null, it defaults to the short name of the module.
So what happened to the package itself, and how does the repository know that all of these procedures and functions belong to it? You'll find the package under Packages, and the modules that it contains are referenced as Sub Program Units, with the Method of Use property set to "INCLUDE". Their order in the package is maintained by the Called Sequence property. Look at the procedure or function's Scope property. If Scope is Private, the module is in the package body, but not the specification. If Scope is Public, the module is in both body and specification.
If you generate the package, you should get the entire package generated, but if you generate just one module, that's all you get - a standalone procedure or function. One interesting side effect - you can have the same procedure or function in more than one package, just by including it in more than one.
Hope this helps. Please ask if you need some clarifications.