Re: Printing debug statements in stored procedure/packages

In article <Do61E2.GA4_at_intruder.daytonoh.attgis.com>, dave.podnar_at_daytonOH.ATTGIS.COM says...
>
>We used the DBMS_PIPE package to send logging/debug info from a
>package to another session that continually retrieved the
>messages and inserted them into a table. This design sent all
>log/debug messages out of the current COMMIT/ROLLBACK scope.
>After they were inserted and committed by the receiver they were
>visible regardless of the outcome of the originating transaction.
>
>This worked well since we were writing server based daemons and
>wanted to record informative processing info but didn't have a
>user to view it. We did run into some situations where the pipe
>would overflow and some messages would be lost.
>

We used a similar concept as well. The calls were imbedded throughout our code and included a 'trace level' as one of the parameters to our trace package. The tracing package would only pipe out the data when a public variable was set at a value greater or equal to the trace level specified on each individual call. The global public variable is generally zero so that no tracing data is piped, but could be set during the session as required to dynamically turn the flow of debugging information on/off.

This allows the tracing mechanism to remain in place in the delivered code where it's passive until we need to enable it on for 'on the spot' debugging.  With careful choice of level values coded in the individual trace calls throughout the code, we can control how much detailed trace data we get. Level 1 is used for major entry/exit points, level 10 for minor, higher for more detailed logic flow tracing, etc.

There is obviously overhead involved in leaving these in the delivered code so that would not be appropriate for everyone. Received on Thu Mar 14 1996 - 00:00:00 CET