Eine saubere und funktionierende ODBC Installation ist durchaus eine Herausforderung für jeden Systemadministrator.

Deshalb werde ich hier in den nächsten Tagen ein paar Tipps aus meinen eigenen Erfahrungen zu dem Thema geben.

Die Grundlage

Völlig unabhängig von Datenbanksystem wird für die Verwendung von ODBC eine Grundlage, der sogannte Treiber (Driver) benötigt. Hier hat der Anwender nun die Qual der Wahl, es gibt für die Open Source Unix Betriebssysteme genau zwei Möglichkeiten:

1. UnixODBC (/usr/ports/databases/unixODBC)
2. libIODBC (/usr/ports/databases/libiodbc)

Beide Treiber gleichzeitig lassen sich ohne weiteres nicht installieren, da sie sich beißen. Allerdings benötigt eine Reihe anderer Software (Java, OpenOffice, etc.) ebenfalls einen dieser beiden Treiber. In den meisten Fällen hat eine Software ihren Liebling, welcher installiert wird, wenn noch kein Treiber installiert ist. Ist bereits der Nicht-Lieblings-Treiber installiert, so verwendet die Software diesen.

Eine Uminstallation des Treibers ist bei manchen Linuxsystemen auch nicht so einfach. Einige automatische Installer stellen fest, huch, der Treiber, den ich jetzt vom System entfernen soll wird ja noch von anderer Software gebraucht, also entferne ich mal diese Software ebenfalls mit. Im schlimmsten Fall führt dieses zu einem nackten Betriebssystem nach dem Entfernen des Treibers. Bei meinem Versuch waren es jedoch bei einem Linuxbetriebssystem nur ganze 84 weitere Pakete die mit entfernt wurden (unter anderem auch Java).

FreeBSD ist an dieser Stelle cleverer. Wird in dem Port gesagt: make deinstall, so bekommt der Anwender nur einen Hinweis, welche Software noch eine Abhängigkeit zu dem Treiber hat, entfernt aber den Treiber dennoch und lässt die Software mit Abhängigkeit in Ruhe.

Der Client isql gehört zu UnixODBC. Leider wird dieser nicht bei einem "deinstall" sauber mit entfernt. Ein rm /usr/local/bin/isql ist hier aber ausreichend um auch diesen sauber zu entfernen.

Welcher Treiber ist nun der bessere?

Auch hier lässt sich keine Aussage über besser oder schlechter machen, sondern es kommt auf das Anwendungsgebiet an.

Meine persönliche Erfahrung mit UnixODBC ist, dass dieser doch einige funktionale Bugs beinhaltet, auf dessen Behebung ich nicht warten wollte. Vorallem im Unicode/UTF8 Bereich gewinnt hier für mich persönlich klar derzeit libIODBC.

Wer allerdings nicht über die SQL-Standardfunktionalitäten hinaus möchte (select, insert, delete, create, drop) und keine UTF8 oder Unicode Funktionalität benötigt, sollte die Unterschiede kaum merken.

Wer jedoch sein Datenbankencoding auf UTF8 gestellt hat, dem empfehle ich libIODBC zu verwenden.

Sowohl bei der Verwendung von MySQL als auch bei der Verwendung von PostgreSQL empfehle ich libIODBC.

Installation und Konfiguration:

Neben UTF8 Problemen hat UnixODBC einen weiteren Nachteil:
Die Version in den Ports ist sehr alt. Es empfiehlt sich hier, die Sourcen von http://www.unixodbc.org herunterzuladen und selbst zu kompilieren.

Der Treiber libIODBC läßt sich bedenkenlos einfach mit "make install clean" aus den Ports installieren.

Die Konfiguration ist einwenig trickreich und mit ausprobieren verbunden.
Zu dem Thema Konfiguration werde ich in den nächsten Tagen im Zuge der MySQL-ODBC-Konfiguration Beispiele bringen. Diese Beispiele lassen sich mit den richtigen Werten genauso für PostgreSQL verwenden.
Immerhin habe ich meine erste funktionierende MySQL ODBC Konfiguration dadurch erlangt, dass ich im Netz auf das Beispiel einer PostgreSQL ODBC Konfiguration gestoßen bin, welches ich auf mein System übernommen und alles PostgreSQL-typische einfach durch das entsprechende MySQL-typische ersetzt habe.

Zur Konfiguration lässt sich sagen, es gibt zwei Konfigurationsdateien:

1. odbcinst.ini
2. odbc.ini

Zu finden sind diese Dateien in /usr/local/etc/ oder aber in /usr/local/etc/libiodbc.

Die odbc.ini kann als .odbc.ini in das Homeverzeichnis des User, der die spätere Anwendung aufruft, verlagert werden.
Meine Erfahrung ist hierbei jedoch, dass es wichtig ist, dass die odbc.ini in /usr/local/etc leer oder nicht vorhanden ist, sobald die .odbc.ini im Homeverzeichnis genutzt werden soll.

Auch ist meine Erfahrung mit der odbcinst.ini unter FreeBSD und der Verwendung von libIODBC, dass diese komplett ignoriert wird und libIODBC nur auf die odbc.ini zugreift. Heisst, hier sollte dann alles in der odbc.ini stehen. UnixODBC dagegen kommt gar nicht klar, wenn keine odbcinst.ini konfiguriert wurde.

In allen nachfolgenden Beispielen habe ich libiodbc verwenden, sofern ich hier nicht explizit auch auf unixODBC eingehe.