Re: is there a dictionary query that is able to tell which public procedure calls a particolar line of code?

From: Mark D Powell <Mark.Powell_at_eds.com>
Date: Wed, 16 Sep 2009 08:25:53 -0700 (PDT)
Message-ID: <82547167-9497-4f7c-a957-e5cd1ffd2cfa_at_f10g2000vbf.googlegroups.com>



On Sep 16, 7:54 am, Shakespeare <what..._at_xs4all.nl> wrote:
> yossarian schreef:
>
>
>
>
>
> > Good morning, Oracle 10.2.0.3 SE on Linux here.
>
> > I'm trying to understand an Oracle package horribly written by an
> > ex-coworker.
>
> > Is there a dictionary query that is able to tell which *public*
> > procedure (i.e. included in package specification) calls a particolar
> > line of code?
>
> > I'm getting lost with bad indentation and sub-sub-sub-procedures...
>
> > Thank you.
>
> > Kind regards,
>
> >    Yossarian
>
> Bad indentation can be repaired with a good editor like Toad by Quest or
> Pl/SQL Developer by Allround Automations.
>
> A procedure never calls a particular line of code, it can call other
> procedures or functions. With the tools above you can look at
> 'referenced by', but they will only show which package calls which
> package. You'll need a cross-reference program to see what you want to see.
>
> Shakespeare- Hide quoted text -
>
> - Show quoted text -

Indentation might make code easier to read, but the indentation should have no effect on your ability to follow the logic paths in the code. As far as sub, sub, sub procedures go I would think that would be a sign that the programmer isolated commonly performed actions into procedures which would be good coding practice.

The code may really be poorly written but I suspect the real problem is that the code is not documented so that a new developer can see what the overall processing logic is and see the steps in that logic.

Instead of worring about the way the code is physically written use a PL/SQL tool that has a debugger and try to process through the code with break points set on every procedure to get an idea of the flow. In the absence of a vendor tool you can use an anonymous logging routine or dbms_output statements added to the code to document the flow for specific sets of starting values.

Extracting an internal procedure and converting it to anonymous code then running it in test can allow you to zero in on specific processing when no debugging tool is available or if you isolate an issue to a specific routine.

HTH -- Mark D Powell -- Received on Wed Sep 16 2009 - 10:25:53 CDT

Original text of this message