[unixODBC-support] DBD:ODBC doesn't locate unixODBC odbc.ini

Martin J. Evans bohica at ntlworld.com
Thu Oct 20 18:44:33 BST 2011


On 20/10/2011 17:11, Jean-Roch Grenetier wrote:
> Hi,
>
> I've got a working unixODBC <=> freeTDS tandem. Both isql and tsql
> return data successfully from tests "SELECT * FROM custome WHERE ...."
>
> I've also got a working Perl DBI <=> DBD:ODBC tandem. DBD:ODBC was
> compiled OK against the unixODBC. Here too, my Perl script returns data
> successully from a test: "SELECT * FROM customer WHERE ..." as long as
> executed with the same Linux user whom I've registered an odbc.ini with
> the odbcinst command-line utility.
> But.. it doesn't find the same DSN if I invoke the same script from a
> Web page, where it's Apache calling this same script.
>
> So I went back to this documentation
> http://www.unixodbc.org/doc/FreeTDS.html and focused on:
>
> "Note; we have executed previous commands as root (denoted by leading
> '#' character on given commands) but here we execute the command as a
> regular user. This is significant. All users of the system share FreeTDS
> and the ODBC Drivers but each user has his/her own list of DSN's (view
> odbcinst output for help on registering as a system DSN available to all
> users). So create the DSN as the user who is going to be using it. "
>
> $ odbcinst -i -s -f tds.datasource.template
> create ODBC data source
>
> and recreated:
> $ odbcinst -i -s -f *-l* tds.datasource.template
>
> What I'm not sure of yet, is if I should recompile DBC:ODBC after this
> change. I'd think not, because these odbc.ini files need to be
> dynamically read so that new additions are taken into account without
> having to touch anything of DBD:ODBC. But so far it still doesn't work:
>
> [unixODBC][FreeTDS][SQL Server]Unable to connect to data source
> (SQL-08001) [state was 08001 now 01000]\n[unixODBC][FreeTDS][SQL
> Server]Unknown host machine name. (SQL-01000)
>
> Thanks in advance!

Contrary to what you've said the above indicates a DSN was found as 
unixODBC loaded the freeTDS driver.

The error comes from FreeTDS hence the "[FreeTDS]" in the error string.

Without the -l argument to odbcinst you have installed a user DSN and it 
will be placed in ~/.odbc.ini. If you are logging in as different users 
all wanting to access the same DSN you need to copy the working 
~/.odbc.ini to each account that is going to use the DSN or create 
SYSTEM dsn which is accessible by everyone. odbcinst -j tells you where 
system DSNs go and you could copy the working ~/.odbc.ini to that file. 
However, the basic issue is the DSN used by your web user is wrong in 
some way and you'll need someone with freeTDS fu to find that issue.

Martin
-- 
Martin J. Evans
Wetherby, UK


More information about the unixODBC-support mailing list