Geeks In Action

This is funny to me in light of my last post. I have installed UnixODBC, I installed the gui tool to manage it and then I installed MDBTools to allow me to connect to a JET database. (This is all on my Fedora 12 machine by the way for those just joining us.) The funny part is that the time I spent getting the gui tool was wasted as it wont work with the driver anyway, at least not the way I’ve set it up. Not sure why, not sure that I care. Here is what I did to get it to work. First I checked for the driver ( /usr/lib/libmdbodbc.so.0 in my case ). It was there so I edited /etc/odbcinst.ini and added the following entry.

[MDBToolsODBC]
Description = MDB Tools ODBC
Driver = /usr/lib/libmdbodbc.so.0
Setup =
FileUsage =
CPTimeout =
CPReuse =

That takes care of telling UnixODBC about the driver. I wonder if there is a file from MDBTools that I can use for the setup part. Not sure, may look into it at some point. The next step was creating a DSN. That involved adding the following lines to /etc/odbc.ini (Which existed but was empty because I hadn’t created any entries yet.)

[lintry]
Description = Microsoft Access Try DB
Driver = MDBToolsODBC
Database = /home/jr.peck/Documents/lintry.mdb
Servername = localhost
Username =
Password =
port = 5432

Here is what a connection in Python could look like.

import pyodbc

sql = 'Select * from foo'

conn = pyodbc.connect('DSN=lintry')
cursor = conn.cursor()
cursor.execute(sql)
rows = cursor.fetchall()

for record in rows:
    print record.FirstName + ' ' + record.LastName

cursor.close()
conn.close()

In my database the table foo contains three columns and the first two are FirstName and LastName. So anyone messing this will obviously need to change it to match their table name, column names, etc. This last piece of getting things to work on Linux wasn’t really necessary but it didn’t take all that long to figure out and I’m glad I did, in case I do need it down the road. I imagine this would work just the same for any other programming language that could take advantage of UnixODBC.

January of last year UnixODBC spun off non-core code to separate projects of their own. The reasoning they give on their site makes sense. I’m just not sure I follow all the ramifications when it comes to how this works out on the user level with different distros. What I do know is that with Fedora if one wants to use the gui ODBC manager, ODBCConfig, then that does not come in the unixODBC package – it comes in unixODBC-kde. What’s interesting is that over at their sourceforge file list it shows a GTK version but that doesn’t show up in my KPackageKit list. I’m not sure how that came to be and I’m not sure if I have time or the inclination to figure it out.

The thing that drives me to mention it at all is that if one is googling around looking for info. on how to use UnixODBC, they are going to come under the impression that ODBCConfig is part of that package. The reason I figured out to look for something else was I happened to google Fedora and UnixODBC and ran across a forum posting that put me on track.

Looking at the ODBCConfig page itself, with a last update over 10 years ago, I wonder if those goes back further than last year. I don’t know. I haven’t messed with UnixODBC in quite a while and last time I did it was on AIX and I was just concerned with MS SQL Server drivers. Now I’m trying to get my little Python program I wrote to read an MS Access database running on my Fedora machine. This is stupid in a sense as I’d never willingly use MS Access on a linux box but I just want to see if I can do it. It would make more sense to switch to SQLite.

So just to sum up – if you want to use UnixODBC on Fedora, with the gui admin tool, you need to install 2 packages rather than just one. Getting the drivers themselves is also another matter. My next task is to see if I can MDBTools and UnixODBC to play nice together. I’ve found examples from folks who say they’ve done it so I’m going to give it a whirl.