FreeTDS Development Group

["ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>]

> 
> Hi Steve, 
> 
> Brian Bruns wrote:
> > tsql with the -H and -p switches is useful for seeing if a server is
> > up and answers without a freetds.conf configuration.  
> 
> This technique gets employed frequently, if list traffic is at all
> representative.  ISTM FreeTDS gets used most often with ODBC 
> and/or PHP,
> environments that don't call for sqsh.  sqsh is definitely 
> overkill for
> straightening out configuration problems.  
> 
> tsql's unmediation is good, too: it helps people figure out 
> if the problem
> they're encountering is in FreeTDS or a higher layer.  
> 
> I'd think you should consider including freebcp, bsqldb, and defncopy,
> too.  These are user tools.  Have a quick look at the man pages if you
> haven't been keeping up.  :-)  
> 
> > We have to walk a fine line between providing a decent tool for
> > debugging configuration problems and accidentally encouraging people
> > to use it in a production setting.
> 
> We should have such problems.  If it gets *too* popular, we can always
> stop linking in readline.  Or maybe make people type  "I 
> accept the risk"
> instead of "go".  (cf.
> http://www.washington.edu/imap/documentation/imaprc.txt.html)
> 
> Maybe there should be a cautionary note in the tsql man page, warning
> people that (for example) tsql won't always exit with an 
> error code when
> it encounters a database problem.  
> 

I think tsql it's a strange tool. Is intended to help users to solve
FreeTDS connection problems. So someone should ask why it has options
for batch use or why it give user the ability to execute any query... I
think that the main advance to use tsql is that it bypass use library
using directly libTDS (you can note that others libraries use dblib).
I think that a reason to use tsql is that many login errors are not sent
to client but only to log, for example in login.c

        /* verify that ip_addr is not NULL */
        if (tds_dstr_isempty(&connection->ip_addr)) {
                tdsdump_log(TDS_DBG_ERROR, "IP address pointer is
empty\n");
                if (connection->server_name) {
                        tdsdump_log(TDS_DBG_ERROR, "Server %s not
found!\n", tds_dstr_cstr(&connection->server_name));
                } else {
                        tdsdump_log(TDS_DBG_ERROR, "No server
specified!\n");
                }
                return TDS_FAIL;
        }

(there is not a tds_client_msg call).
Calling tds_client_msg should help most users.

About packaging the most login package should be a tools package.
Sometimes I think that should good to split FreeTDS like

conf
core (depends on conf)
devel (depends on ??)
dblib (depends on conf only)
ctlib (depends on conf only)
odbc
tools (depends on dblib)

would help. The reason to split core (libTDS) in a separate library is
that libTDS change compatibility version every version we develop while
dblib/ctlib/odbc change quite less (odbc is still version 1...). Now if
we want (for istante) to update a PHP compiled with --with-mssql to use
a new FreeTDS version we have to update dblib but this cause the update
of libTDS (packaged with freetds main package) and this would probably
broke some binary compatibility.
Why don't deb/rpm support sub-package like hp-ux ??

freddy77