FreeTDS Development Group

[Kayak <smarshall AT kayak.com>]

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 <msabramo AT gmail.com> 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 <freddy77 AT gmail.com> wrote:
> 
>> 2014/1/2 Stephen Marshall <smarshall AT kayak.com>:
>>> 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
>> FreeTDS AT lists.ibiblio.org
>> http://lists.ibiblio.org/mailman/listinfo/freetds
>> 
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds