FreeTDS Development Group

["James K. Lowden" <jklowden AT freetds.org>]

On Tue, 26 Nov 2013 04:28:45 +0600
?????? ???????? <mikhail.v.gavrilov AT gmail.com> wrote:

> I came here because I expected on your help, but instead got a story
> that shoot in the leg is hurt, I know about this, let me leave the
> choice, in my case for connect to MS SQL from MariaDB ideal is
> storing passwords in odbc.ini. 

You *are* getting help.  I explained the features, and offered a few
alternatives.  Or did you think it was my job to foresee your desires
before you wrote?  

As far as I know, Microsoft's driver doesn't read passwords from
odbc.ini either.  Using odbc.ini that way would be bad practice and bad
design.  

It's not a matter of choosing not to help.  It's a matter of choosing
what features to devote our time to.  We decided against bothering to
parse passwords from odbc.ini keeping them there creates more problems
than it solves.  

An odbc.ini entry describes a server: the TDS version it supports, the
name of the host, the port.  It does not describe a user.  If you add
the "default user" or somesuch goes in odbc.ini, it opens Pandora's
Box.  What to do about the second user?  What to do about *any* user
who forgets to provide credentials?  

Providing bad defaults leads to unhappy experiences.  Better not to do
it.  

When you think about it, the situations for which keeping user
credentials in odbc.ini works well are quite special.  Yours may be
such a case; I don't know.  I do know that special cases --
particularly when contraindicated by common cases -- belong in 
the application, not the library.  

--jkl