[freetds] Dreaded "Server SYBASE not found!" question

Frediano Ziglio freddy77 at gmail.com
Sun Dec 13 03:23:13 EST 2009


Il giorno sab, 12/12/2009 alle 12.42 -0500, James K. Lowden ha scritto:
> Nelson, Erik - 2 wrote:
> > There's an outstanding todo in login.c to open the log file prior to
> > tds_set_server() where "SYBASE" is being set in to
> > connection->server_name, but it's not at all clear why the server
> > name/IP aren't being set correctly since the server info is clearly
> > being found in freetds.conf.  
> ...
> > [Hiruko] found in "/modleng/usr/etc/odbc.ini"
> > found this section:
> >         [Hiruko]
> >         Driver  =       FreeTDS
> >         Description     =       DataDirect 5.1 SQL Server Wire Protocol
> >         Servername      =       Hiruko
> >         Server  =       Hiruko
> >         Port    =       1433
> 
> Server and Servername cannot be in the same section.  One overrides the
> other.  
> 
> This highlights a more general question, for which I'd like to hear
> suggestions (and/or see a patch!) from anyone who's interested.  
> 
> We have two mutually exclusive attributes in our configuration files.  In
> odbc.ini we have server/servername; in freetds.conf we have port/instance.
>  These inevitably trip up some people, probably a lot more than write to
> the list, who over-specify the sever.  What to do?  
> 
> One solution is to die noisily with err(3) when invalid combinations are
> found for the requested server.  (Also, perhaps warnings writting to
> stderr for any other configuration problems e.g. invalid property names). 
> 
> 
> A second way is to document the conflict clearly and have a careful
> override policy.  I started working on that, but I'm not satisfied.  It
> reminded me of something one of the Bell Labs guys said about writing
> early UNIX man pages: sometimes the documented behavior was so
> embarrassing that it motivated them to fix it.  
> 

I would suggest a proper error using correct way (that is no stderr).

> Another solution is to eliminate the "other" name.  
> 
> For odbc.ini, we could eliminate "servername".  Instead, "server" would
> first be looked up in freetds.conf, if it exists.  If nothing is found,
> then "server" would be treated as a DNS name.  This is consistent with how
> a servername is treated during a db-lib/ct-lib lookup.  

Although this breaks compatibility I'd agree. I see not that difference
between two terms.

> For freetds.conf, we could eliminate "instance" and always use "port".  If
> "port" is a number, it's a port; if "port" is a string, it's a named
> instance.  Or, always treat "port" as a potential named instance,
> interrogate the server, and revert to a number only if the server refuses
> to reply with a valid port.  (I'm tempted to keep "instance" and eliminate
> "port" instead, but I'm held back, perhaps wrongly, by tradition.  And I
> wonder whether you can name your instance "80"?) 
> 

And what about port is a port specified in /etc/services ?
Personally I would eliminate both and use "compressed" syntax like
"server:port" or "server\instance". This for two reason:
- is already supported by libTDS
- is compatible with ODBC and the way you specify this in DSN
configuration.

> I tend to favor "die early and often": if the configuration file is
> invalid, complain and stop.  But, particularly in web environments (and
> given the way TDSDUMP logging works), it can be hard to diagnose why the
> server connection failed.  
> 

If upper layer do not read correctly error is not my problem.

> I *also* think it's better to make mistakes less likely by eliminating
> opportunities.  
> 

I think first step is eliminate confusion refusing to even try to
connect if both specified (server/servername and/or port/instance).

> Suggestions?  
> 

As a start see attached patch

freddy77

-------------- next part --------------
A non-text attachment was scrubbed...
Name: vedi.diff
Type: text/x-patch
Size: 7898 bytes
Desc: not available
Url : http://lists.ibiblio.org/pipermail/freetds/attachments/20091213/a82f71f9/attachment.bin 


More information about the FreeTDS mailing list