[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