Re: CS_SERVERADDR tag is not handled correctly in ct_con_props

Let me try to explain in better detail:

Problem:
The CS_SERVERADDR enum is not properly honored in the ct_con_props function
call.
For example, this call should effectively set the host and port for a DB
connection, but it results in an error when the connection information is
actually used.
    ct_con_props( g_connection,
                      CS_SET,
                      CS_SERVERADDR,
                      (CS_VOID*)server,
                      CS_NULLTERM,
                      (CS_INT*)NULL
                    );
Here: g_connection is a pointer to type CS_CONNECTION, and server is text
of the form "<host> <port>".  Note that FreeTDS provides other ways to
specify host and port (e.g. setting the server parameter to
"<host>:<port>"; however, the method using CS_SERVERADDR does not work.

Approaches to fix:
I see two ways to attack this problem.  Of course, you may see others.

One approach is to ensure port information is set in the CS_CONNECTION data
structures and then passed to the other internal data structures used to
establish a connection in FreeTDS.  This would be a true fix to the
problem, but would require some changes to at least a few internal data
structures.

Another approach is the mark the CS_SERVERADDR tag as disabled in FreeTDS.
 This would not actually fix the problem, but would allow client
applications to work around the limitation.  However, I think this can be
achieved by simply undefining CS_SERVERADDR in cspublic.h.

If you have any thoughts on ways to fix this, I'm certainly open to
suggestions.

Steve



On Mon, Jan 6, 2014 at 9:58 AM, Kayak <[email protected]> wrote:

> Marc is right. By tag, I mean the enum CS_SERVERADDR
>
> Sent from my iPhone
>
> On Jan 6, 2014, at 9:40 AM, Marc Abramowitz <[email protected]> wrote:
>
> > My guess is that Stephen is referring to the code around this line in
> > src/ctlib/ct.c (around line 395) in the ct_con_props function:
> >
> >   case CS_SERVERADDR:
> >
> > There are comments mentioning that this code is handling the "[hostname]
> > [port]" syntax but from messages on the sqsh bug report it sounds like,
> > FreeTDS somehow still fails to connect.
> >
> >
> >
> >
> > On Mon, Jan 6, 2014 at 6:21 AM, Frediano Ziglio <[email protected]>
> wrote:
> >
> >> 2014/1/2 Stephen Marshall <[email protected]>:
> >>> FreeTDS 0.91 does not honor the CS_SERVERADDR tag in the  ct_con_props
> >>> function.  This function and tag are used to allow database connections
> >>> using a "<host> <port>" syntax.
> >>>
> >>
> >> Which "tag" ?
> >>
> >>> There is code in FreeTDS that compensates for this problem by allowing
> >> the
> >>> user to specify the server name as "<host>:<port>".  FreeTDS supports
> >> this
> >>> syntax as a fallback case when a server name cannot be found in the
> >>> configuration file. See freetds file src/tds/config.c,
> >>> parse_server_name_for_port function for details.  However, this is not
> a
> >>> standard part of the TDS protocol.  Client applications conforming to
> the
> >>> standard can end up doing the wrong thing.  I have noticed this problem
> >> in
> >>> the sqsh client, but may affect other clients as well.
> >>>
> >>> The connection code should either be fixed or the CS_SERVERADDR macro
> >>> should be disabled.  The latter would signal to client applications
> that
> >>> CS_SERVERADDR does not work per spec, which would allow client
> >> applications
> >>> to avoid calling this function when linked against FreeTDS.
> >>>
> >>> Note: this problem was originally submitted as a bug to the sqsh
> project,
> >>> but latter determined to be a problem in FreeTDS.  Further details of
> the
> >>> original submission can be found here:
> >>> http://sourceforge.net/p/sqsh/bugs/60/
> >>>
> >>> Also note that I tried to fix this myself, but I got a little lost in
> >>> mapping of connection information between several different data
> >>> structures.  It does not seem like the port information is carried
> >> through
> >>> all of them.  With some guidance on how to proceed without inducing
> side
> >>> effects, I would be happy to work on this problem.
> >>
> >> I do not follow at all.
> >>
> >> Frediano
> >> _______________________________________________
> >> FreeTDS mailing list
> >> [email protected]
> >> http://lists.ibiblio.org/mailman/listinfo/freetds
> >>
> > _______________________________________________
> > FreeTDS mailing list
> > [email protected]
> > http://lists.ibiblio.org/mailman/listinfo/freetds
>