Re: Debug option
Volker Barth
Though I think it would be hard to administrate all those numerical
values when used across different procedures/triggers etc. ("err, what
option value was used to debug xxx in stp xy?").
Maybe it would be possible to use strings as argument for DEBUG and
define the DEBUG_MESSAGES as list of strings, such as
MESSAGE 'foo' DEBUG ('DBG_STP1');
MESSAGE 'foo' DEBUG ('DBG_STP2');
SET OPTION "PUBLIC"."debug_messages" = 'DBG_STP1, DBG_STP2';
However, the current implementation is said to have almost no overhead
when debugging is disabled to no, and any new solution should try to
share that useful property.
Volker
David wrote:
> The debug option is very helpful in allowing debug code to be at the
> ready when a development or production problem occurs. However in my
> case I find I have several levels of things I want to debug -- statement
> level triggers (normally on) and row level triggers (normally off) and
> internal (procedure/trigger) traces (almost always off). Often I can
> find a row level trigger problem without resulting to debug. Sometimes
> it would be nice to be able to create a detail trace through a
> complicated procedure.
>
> If debug instead of being one state either on and off were say 8 bits of
> on and off there could be up to 8 levels of debug coded and ready in an
> application.
>
> As an example 1 would be statement level trigger debug (trigger name), 2
> could be row level debug (trigger name), 4 could be all
> trigger/procedure internal traces and 128 could be a specific set of
> internal traces (set for the specific run).
>
> The message command would interpret the bit settings as belonging in
> multiple groups
> // a statement level trigger message in my design
> MESSAGE 'message content'
> TYPE INFO TO CLIENT DEBUG(1) ONLY;
>
> // a row level trigger message in my design
> MESSAGE 'message content'
> TYPE INFO TO CLIENT DEBUG(2) ONLY;
>
> // a general internal trace message in my design
> MESSAGE 'message content'
> TYPE INFO TO CLIENT DEBUG(4) ONLY;
>
> // a specifically requested internal trace message in my design
> MESSAGE 'message content'
> TYPE INFO TO CLIENT DEBUG(128) ONLY;
>
> // a specifically requested internal trace message also available
> // when a general internal trace is requested in my design
> MESSAGE 'message content'
> TYPE INFO TO CLIENT DEBUG(132) ONLY;
>
> The set command would have similar interpretation
>
> // enable statement level traces
> SET OPTION "PUBLIC"."debug_messages" = 1;
>
> // enable statement and row level traces
> SET OPTION "PUBLIC"."debug_messages" = 3; // (2, 1)
>
> // enable statement and row level and all internal traces
> SET OPTION "PUBLIC"."debug_messages" = 7; // (4, 2, 1)
>
> // enable statement and row level and specific internal traces
> SET OPTION "PUBLIC"."debug_messages" = 131; // (128, 2, 1)
David
debug bits against the message's debug bits) and testing for non zero is
considerably faster than string testing and even moreso than testing
against a list of strings. I have no problems with string testing, if
it is the chosen solution -- but if minimizing the impact when disabled
is a consideration bit testing appears to be considerably less machine
intensive (and the coding of message statements is generally performed
by a skilled coder -- admittedly this concept is more like C than like
SQL. But this database does offer bit (and arrays of bits) as datatypes
and bit manipulation operators for dealing with them.
If there could be global values like a #define in C then you could name
the bits and use the or operator to combine them -- which could occur
for both the message in the DEBUG operand as well as the SET
debug_messages command Could these names be assigned by Sybase or
should they be programmer assigned (assigned by Sybase, as a kind of
reserved word, would probably be easier to implement)?
MESSAGE 'foo' DEBUG (_DBG_STP1);
MESSAGE 'foo' DEBUG (_DBG_STP1 | _DBG_STP2);
SET OPTION "PUBLIC"."debug_messages" = (_DBG_STP1 | _DBG_STP2);