FreeTDS Development Group

[Frediano Ziglio <freddy77 AT gmail.com>]

2011/4/13 James K. Lowden <jklowden AT freetds.org>:
> On Mon, 11 Apr 2011 10:20:01 -0400
> Ken Collins <ken AT metaskills.net> wrote:
>
>> I happily found out that setting TDSHOST & TDSPORT from my ruby lib
>> before establishing the connection worked quite well. So, is this the
>> preferred solution?
>
> Yes, for now.  The *preferred* solution is a small matter of
> programming.
>
> If --with-tds-ver=7.0 (or higher) is used, IMO no freetds.conf should
> be required, because:
>
> 1.  DNS can resolve a hostname to an ip address
> 2.  The form hostname\instancename can be used
> 3.  If no instance is mentioned in the servername, dynamic port
> configuration can look for the MSSQLSERVER on port 1434.
> 4.  If port 1434 doesn't answer, the normal default default port 1433
> can be used.
> 5.  Client-side encoding can be set by applications calling setlocale
> (3).
>
> This arrangement would satisfy the vast majority of Microsoft SQL
> Server users without using freetds.conf.
>
> But we're not there yet.
>

If you specify as server name something like "my_server:5432" and
my_server:5432 and my_server are not found as entries in
freetds.conf/interfaces files FreeTDS should use my_server as hostname
and 5432 as port. There is also the "my_server\instance" syntax.
I must admit that ODBC supports many attributes you can specify
without even using odbc.ini and/or freetds.conf but this is normally
supported by ODBC standards.
If we want to add many attributes even in dblib I think we should
think about a standard way to add these. For this reason and cause the
patch is about adding feature I personally won't put it in rc version.

freddy77