Skip to Content.
Sympa Menu

freetds - [freetds] log ruminations

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "James K. Lowden" <jklowden AT schemamania.org>
  • To: TDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: [freetds] log ruminations
  • Date: Sun, 20 Jul 2003 11:18:10 -0400

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



  • [freetds] log ruminations, James K. Lowden, 07/20/2003

Archive powered by MHonArc 2.6.24.

Top of Page