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

Jean-Roch Grenetier jgrenetier at hotmail.com
Fri Oct 21 00:08:33 BST 2011

Thanks Martin, this is an honor. You're right the DSN is actually found, in the 'system DSNs' file /usr/local/etc/odbc.ini . 
In the meantime I could narrow down further.. here's exactly what happens:
- For a user that doesn't have yet their own /home/<user>/.odbc.ini file yet, this:
my $dbh = DBI->connect("dbi:ODBC:MY_DSN1", 'user', 'password', {PrintError => 0});
results into the correct reading of /usr/local/etc/odbc.ini the system dsn entries, and this is what you pointed out, followed by apparently an attempt to create the /home/<user>/.odbc.ini file leaving this trace:
-rw-rw-r--    1 source   source          0 Oct 18 17:28 /home/<user>/.odbc.ini
and I'm not sure which of DBD:ODBC, unixODBC, or freeTDS attempts to create this file. On other installations, does it results into a full copy of /usr/local/etc/odbc.ini? I was looking at http://www.unixodbc.org/odbcinst.html  'System versus User' to see if there was something supporting the 'theory' of a dynamic copy of the system odbc.ini to the /home/<user>/.odbc.ini but I didn't see anything like that..  I'm not sure which of DBD:ODBC, unixODBC, FreeTDS runtime-creates this 
-rw-rw-r--    1 source   source          0 Oct 18 17:28 /home/<user>/.odbc.ini
- now manually copying the /usr/local/etc/odbc.ini to /home/<user>/.odbc.ini and everything works..
- also, having a full blown 'dbi:ODBC:DRIVER={FreeTDS};Server=10.1.1.xxx; Database=pxxx; Port=1433; uid=user; pwd=password;' works too.
To recap, the /usr/local/bin/odbcinst -i -s -l -f /usr/local/bin/tds.datasource.template works and creates the /usr/local/etc/odbc.ini file but *something* is happening at runtime that results in the above empty file created, and this error message:
 [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)
for the exact same connection string that works in both other 2 contexts I've mentioned.

> Date: Thu, 20 Oct 2011 18:44:33 +0100
> From: bohica at ntlworld.com
> To: unixodbc-support at mailman.unixodbc.org
> Subject: Re: [unixODBC-support] DBD:ODBC doesn't locate unixODBC odbc.ini
> 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
> _______________________________________________
> unixODBC-support mailing list
> unixODBC-support at mailman.unixodbc.org
> http://mailman.unixodbc.org/mailman/listinfo/unixodbc-support
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.unixodbc.org/pipermail/unixodbc-support/attachments/20111020/0a7cf4e4/attachment.html>

More information about the unixODBC-support mailing list