Re: Dreaded "Server SYBASE not found!" question

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.  

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.  

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"?) 

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.  

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

Suggestions?  

--jkl