H.Merijn Brand wrote:
>  On Tue, 02 Sep 2008 19:03:26 +0100, "Martin J. Evans"
>  <martin.evans@[...].com> wrote:
> 
>    
> > H.Merijn Brand wrote:
> >     
> >>  On Tue, 2 Sep 2008 11:15:20 +0100, Tim Bunce <Tim.Bunce@[...].com>
> >>  wrote:
> >>
> >>       
> >>> On Mon, Sep 01, 2008 at 05:01:40PM -0700, Jonathan Leffler wrote:
> >>>         
> >>>> On Mon, Sep 1, 2008 at 3:30 PM, Tim Bunce <Tim.Bunce@[...].com>
> >>>> wrote:
> >>>>
> >>>>           
> >>>>> On Mon, Sep 01, 2008 at 01:31:57PM +0200, H.Merijn Brand wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>             
> >>>>>> On Sun, 31 Aug 2008 23:56:43 +0100, Tim Bunce
> >>>>>> <Tim.Bunce@[...].com> wrote:
> >>>>>>
> >>>>>>               
> >>>>>>> Having said all that, I can see some value in having a
> >>>>>>> separate driver trace level. I suggest a few of the "middle
> >>>>>>>  16 bits" are given over to
> >>>>>>>                 
> >>>>>> IMHO 4 bits will do (0..15). If that is correct, I'll also
> >>>>>> change the levels to leave the basic levels 1 and 2 alone.
> >>>>>>               
> >>>>> Actually I'd rather squeeze the levels concept down to 0..7 for
> >>>>>  both DBI and DBD levels in order to make two more flag bits
> >>>>> available and to encourage greater use of flags.
> >>>>>             
> >>>> FWIW, DBD::Informix uses trace levels from about 3 to 9 (leaving
> >>>> 1 and 2 for DBI output only).
> >>>>
> >>>> Whether that matters is another issue, but 4 bits would be
> >>>> preferred (though three is not the end of the world).  Unless you
> >>>>  have a use for those 2 bits at the back of your mind...
> >>>>           
> >>> Although it looks like the trace level range is being reduced, it's
> >>>  effectively being increased. It's just that instead of a single
> >>> range you'd now have two.
> >>>
> >>> The current highest levels of driver internals tracing would then
> >>> be controlled via the DBD trace level. Something like this:
> >>>
> >>> $h->trace("2,-6"); # DBI trace level 2, DBD trace level 6
> >>>
> >>> That gives you more control because you can enable higher levels of
> >>>  DBD tracing without being swamped by higher levels of DBI tracing.
> >>>
> >>>
> >>>
> >>>         
> >>  Sounds ok
> >>
> >>       
> >>> You could/should also define some trace flags for specific topics
> >>> to give finer control. Something like this:
> >>>
> >>> $h->trace("2,-4,ix_charset");
> >>>         
> >>  We will need some extra macro's to get the dbd level and the flags
> >>  Any suggestions?
> >>
> >>       
> > I like what I'm reading in this thread. As others have said I would find 
> > it beneficial to be able to trace DBD::ODBC without getting DBI tracing. 
> > In an attempt to get DBD::ODBC tracing without DBI tracing I moved some 
> > tracing to trace flags. Unfortunately, this had a rather unfortunate 
> > side effect. I created an odbcconnection trace flag and put all my 
> > connection tracing under that. The problem is the only way to set the 
> > flag before connecting :-( is:
> >     
> 
>  That is why I also support $ENV{DBD_TRACE}, in analogy with
>  $ENV{DBI_TRACE}.
>   
>    
I would have to agree with $ENV{DBD_TRACE} It would be very useful for 
me while debugging connections as well.
> > use DBD::ODBC;
> > DBI->trace(DBD::ODBC->parse_trace_flags('odbcconnection|odbcunicode');
> >
> > The current trace macros allow tracing if a flag is set, tracing if a 
> > flag is set and the trace level is at least N, and tracing if the level 
> > is at least N but NOT tracing if a flag is set OR the level is at least 
> > N. I'd find the latter greatly beneficial for the above reason.
> >     
> 
>