I'm attempting to read from an Access database using MDBTools drivers to execute an odbc_connect
on Ubuntu 11.10. It's working fine when using the DSN setup in /etc/odbc.ini
.
Below are the contents of /etc/odbc.ini
:
[logindb]
Description = Microsoft Access Try DB
Driver = MDBToolsODBC
Database = /home/folder1/TestDb.mdb
Servername = localhost
The Driver attribute in odbc.ini
references MDBToolsODBC
, so, here is my odbc setup in /etc/odbcinst.ini
:
[MDBToolsODBC]
Description = MDB Tools ODBC
Driver = /usr/lib/libmdbodbc.so.0
Setup =
FileUsage =
CPTimeout =
CPReuse =
My problem is, when using $conn = odbc_connect('logindb','','');
, I have to use the hardcoded value for the database location. Ideally, I would like to specify the first parameter of odbc_connect
using a DSN-less connection, so that my database file can be a variable (will be reading from different dbs). Something like:
if ($cond1) {
$db = "/home/folder1/TestDb.mdb";
} else {
$db = "/home/folder1/TestDb2.mdb";
}
$conn = odbc_connect("odbc:Driver={MDBToolsODBC};Dbq=$db",'','');
I've also tried it without the odbc: prefix, but it did not work. Can anyone tell me why specifying the DSN works, but when trying to specify it on the fly using what looks like the same attributes, it doesn't work? I'm thinking it has to do with the parameters and contents of the first parameter in the DSN-less connection. As always, any help is greatly appreciated.
It is supported in 0.7.1. You can get it from github:
https://github.com/brianb/mdbtools
Regarding the connection string, this works for me:
I think it might not support it. Going from the source of the actual driver you see that it loads the params it needs to check, checks wether it has been given a DNS string, checks the ini files next and if it hasn't errored out it sets the params.
for reference from odbc.c latest mdb-tools (mdbtools-0.6pre1)
then when you verify in connectparams.c, ExtractDSN specifically looks for the DSN= string
And LookupDSN looks for inifiles or immediately returns with TRUE, depending on the HAVE_SQLGETPRIVATEPROFILESTRING precompiler setting.
So given that
only works on the data it got from the 2 previous functions, I think it doesn't support DSN-less. Only either a proper DSN= string or ini files.