DBAsupport.com Forums - Powered by vBulletin
Results 1 to 2 of 2

Thread: Is there an Internal method for recognizing passed in parms?

  1. #1
    Join Date
    Nov 2001
    Location
    New Brunswick, NJ
    Posts
    67

    Is there an Internal method for recognizing passed in parms?

    Hello All,

    I'm creating a new (trace) package in which I will track the call stack path of my system, to find out what's being called under multiple scenarios. I can turn this tracing on and off at a system level and can have multiple output paths (i.e. dbms_output, log file, or a table)

    The calls to my new package will be placed into at least 2 points of every package, procedure and function in my system. The first will be the entry point into one of the above, and the second will be the exit.

    On entry into a package/proc/func, I will call my new package and pass in a few things such as:
    1) Package/proc/func name
    2) Any in parameters
    3) Any addition debug info

    On exit, I will call my new package and pass in a few things such as:
    1) Package/proc/func name
    2) Any returned values
    3) Any addition debug info

    I'd like to make my code as generic as possible, but the problem I have is that every procedure and function will have different input parameters. I'd like to be able to go into each and just add a simple call to my new package without having to manually add each input parameter one at a time. We have thousands of procedures and functions in our system and I already have to modify every one of them. I want to add as little as possible to each piece of code.

    Is there a way to recognize passed in parameters so that I can call my new package and pass something which can parse the parameters and write them out? If there isn't that's fine too, but before I got started with the mass modification, I figured I'd at least ask the question.

    Thanks a lot.

    Paul

  2. #2
    Join Date
    Jan 2004
    Posts
    162
    AFAIK there is no method for retrieving the values of formal parameters (apart from referencing them by name of course). If you wanted a single generic logging procedure you could pass the parameters as ANYDATA but you would still have to explicitly construct the ANYDATA from the parameters.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Click Here to Expand Forum to Full Width