FreeTDS Development Group

["James K. Lowden" <jklowden AT schemamania.org>]

All, 

Queries for help on the list frequently involve applications written in
something other than C.  The difficulty we face in diagnosing these
problems is that both parties are blind to the API.  The (say) PHP
programmer doesn't usually know precisely what was passed to or received
from FreeTDS.  That makes it hard for us to know where to start tracking
things down.  

Some time ago, we set up debugging levels with the intention to vary the
granularity of the logged information.  We never really did anything with
them; the only logs I ever see are "with debug level 99".  Instead of
levels, it seems to me we need categories of logging, and tds_g_debug_lvl
should be a bitmapped value.  

As usual, Sybase got there first.  They define these levels:

Value              Resulting Client-Library behavior
-----------------  ----------------------------------------
CS_DBG_API_        Prints out information each time the
 LOGCALL           application calls a Client-Library
                   routine, including the routine name and
                   the parameter values.
CS_DBG_API_STATES  Prints information relating to Client-
                   Library function-level state transitions.
CS_DBG_ASYNC       Prints function trace information each
                   time an asynchronous function starts or
                   completes.
CS_DBG_DIAG        Prints message text whenever a Client-
                   Library or server message is generated.
CS_DBG_ERROR       Prints trace information whenever a
                   Client-Library error occurs. This allows
                   a programmer to determine exactly
                   where an error is occurring.
CS_DBG_MEM         Prints information relating to memory
                   management.
CS_DBG_NETWORK     Prints information relating to Client-
                   Library's network interactions.
CS_DBG_PROTOCOL    Captures information exchanged with a
                   server in protocol-specific (for
                   example, TDS) format. This
                   information is not human-readable.
CS_DBG_PROTOCOL_   Prints information relating to Client-
STATES             Library protocol-level state transitions.

Of these, it seems to me that CS_DBG_API_ LOGCALL, CS_DBG_ASYNC,
CS_DBG_DIAG, CS_DBG_ERROR, CS_DBG_NETWORK, and CS_DBG_PROTOCOL would be
helpful.  I don't think state-transition information plays an important
role.  And I would define CS_DBG_NETWORK to include calls to libtds.  I
would replace CS_ with TDS_, and add TDS_DBG_LOGIN for diagnosing login
problems; otherwise the username/password information would be suppressed.
 

I wonder if anyone objects, has a better idea, or is interested in working
on this.  

--jkl