unixODBC macht mich echt fertig.

Nachdem ich die ODBC-Verbindung zu meiner Oracle-Datenbank scheinbar erfolgreich eingerichtet hatte, funktionierten die meisten DB-Funktionen mit dem danach installieren SquirreL SQL Client nicht.

Dauernd flog die Verbindung zum DBMS mit der Fehlermeldung: “[unixODBC][Driver Manager]Driver does not support this function” ab.

Ich schob den Fehler dem JDBC-Teil der Java-Anwendung zu (v.a. wg. der Meldung “Das Laden des JDBC-Treibers “{0}” ist fehlgeschlagen.” und dem Umstand, dass der Fehler in einer testweise angelegten OOO-Base-Datenbank nicht auftrat), und richtete für das Programm dann die Verbindung über den “Oracle OCI Driver” ein. Das funktionierte auch einwandfrei.

Als ich jedoch gerade anfing, eine QT-Anwendung zu erstellen, die auch über ODBC an meine Oracle-Instanz andocken sollte, rieselte es wieder die “Driver does not support..”-Fehler.

Der Connect funktionierte, die Abfragen blieben allesamt hängen.

Und weil in der OSS-Version von QT keinen OCI-Treiber gibt, musste ich mich nun zwangsläufig mit dem Fehler auseinandersetzen.

Ein Trace der unixODBC-Verbindung ergab folgende Log-Einträge:

[ODBC][25990][SQLSetStmtAttr.c][243]
Entry:
Statement = 0×811f6d0
Attribute = SQL_ATTR_CURSOR_TYPE
Value = 0×3
StrLen = -5
[ODBC][25990][SQLSetStmtAttr.c][356]Error: IM001
[ODBC][25990][SQLGetDiagRec.c][710]
Entry:
Statement = 0×811f6d0
Rec Number = 1
SQLState = 0xbf916856
Native = 0xbf916860
Message Text = 0xbf916867
Buffer Length = 512
Text Len Ptr = 0xbf916864
[ODBC][25990][SQLGetDiagRec.c][747]
Exit:[SQL_SUCCESS]
SQLState = IM001
Native = 0xbf916860 -> 0
Message Text = [[unixODBC][Driver Manager]Driver does not support this function]

Endlich hatte ich Futter fuer meinen Freund Scroogle. Gleich im ersten Link des Suchergebnisses fand ich eine vermeintliche Lösung: die “aktuelle” Version 2.2.12 von unixODBC - immerhin auch schon fast zwei Jahre veröffentlicht - sollte meine Verbindungsprobleme lösen.

Ein Debian-Paket dafür war nirgendwo in Sicht, also musste ich wohl selber den Compiler anschmeißen.

Blöd dabei wieder:

Vom noch installierten unixodbc ist das immer noch für die Eclipse-Umgebungen für Aptana und QT benötigte Java-Runtime-Environment abhängig. Ich entschied mich vorerst gegen die Deinstallation und für eine Parallelinstallation der Version 2.2.12 nach /opt.

Nach dem Übersetzen und der Installation der Software trug ich, schnell und schmutzig /opt/unixodbc/lib als erste Zeile in die ld.so.conf ein und erneuerte den Cache.

Und siehe da: meine QT-Anbindung schmeißt keine Fehler mehr.

Dann werde ich das JRE wohl auch händisch installieren und die Ubuntu-Pakete von unixodbc und JRE vom System verbannen.

Marc hatte unter meinem letzten Blogeintrag (Oracle-ODBC-Zugriff für Debian und Ubuntu) das Datenbanktool “SQuirreL SQL” empfohlen.

Die Featurebeschreibung liest sich gut, also ging’s gerade direkt in die Testphase.

Das Programm ist in Java programmiert, ist somit weitestgehend Betriebssystem-unabhängig einsetzbar, und dank JDBC-Schnittstelle sind auch alle Datenbanken ansprechbar, für die ein entsprechender Treiber existiert.

Bei mir kommt naturgemäß nur ein Debian-Derivat als Basis in Frage, in diesem Fall musste Ubuntu 8.04 (Hardy Heron) dran glauben.

Die Installation ist schnell über

$ java -jar squirrel-sql-2.6.5a-install.jar

erledigt, beim anschließenden Aufruf von squirrel-sql.sh startet der Client auch schon.

Da ich auf meinem System bereits ein ODBC-DSN zu meiner Oracle-Datenbank eingerichtet hatte, und der entsprechende Treiber als einziger in SQuirreL SQL schon zur Verfügung stand, versuchte ich zunächst, die “JDBC-ODBC-Bridge” als Verbindungselement zu benutzen.

Als URL für den Datenbank-Alias TEST trug ich “jdbc:odbc:test” ein, der mit dieser Einstellung durchgeführte Verbindungsversuch zur Oracle-Testinstanz wurde positiv beschieden.

Ich konnte auch eine Sitzung mit dieser Konfiguration aufrufen. SQuirreL lud alle Schemes, Tables und weiteren Bestandteile der DB-Instanz und öffnete das Sitzungsfenster. Doch alle weiteren Versuche, auf der Datenbank zu arbeiten, wurden mit Fehlern, wie:

Error: [unixODBC][Driver Manager]Driver does not support this function

TEST: [unixODBC][Driver Manager]Connnection does not exist

oder

Das Laden des JDBC-Treibers “{0}” ist fehlgeschlagen.
Das Eigenschaftenregister konnte nicht geladen werden.

quittiert.

Und weil ich nicht wirklich ein Faible für Java habe, und mich mit den Exceptions nicht weiter auseinandersetzen wollte, entschied ich mich für die sowieso sinnvollere Alternative, den “Oracle OCI-Treiber” einzurichten.

Und so funktioniert’s:

Download der Dateien

“instantclient-basic-linux32-10.2.0.3-20061115.zip” und

“instantclient-jdbc-linux32-10.2.0.3-20061115.zip”

von oracle.com.

Die entpackten Dateien habe ich nach nach “~/SQuirreL SQL Client/lib/oracle/” geschoben.

Das Startscript squirrel-sql.sh benötigt eine kleine Erweiterung:

# Squirrel home
SQUIRREL_SQL_HOME=’/home/stefan/SQuirreL SQL Client’

# stpe - Patch starts here
LD_LIBRARY_PATH=$SQUIRREL_SQL_HOME/lib/oracle:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH

Die Bibliotheken aus der existierenden Oracle-XE-Client-Installation funktionierten mit den eben heruntergeladenen Jar-Dateien übrigens nicht, da diese in Version 10.2.0.3 vorliegen, das Debian-Paket des XE-Clients aber nur in 10.2.0.1 zu haben ist. Benutzt man die “alten” Libraries, stürzt Squirrel SQL reproduzierbar mit Fehlermeldungen, wie:

# An unexpected error has been detected by Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0×9e875776, pid=8838, tid=2677013392
#
# Java VM: Java HotSpot(TM) Server VM (10.0-b22 mixed mode linux-x86)
# Problematic frame:
# C [libclntsh.so.10.1+0x327776]

ab.

In der Treiberkonfiguration des Datenbank-Tools trug ich die heruntergeladenen Jar-Dateien als alternativen “Class Path” ein:

Jetzt war der Treiber benutzbar, die damit angelegte Verbindung “jdbc:oracle:oci8:@ora_tst:1529/test” funktionierte fehlerfrei:

Vielen Dank von dieser Stelle aus nochmal an Marc, ich werde das Tool bei den nächsten Arbeiten am DBMS auf jeden Fall intensiver unter die Lupe nehmen.

An meinem Lenny-Arbeitsplatz benutze ich sqlplus aus dem “Oracle Database 10g Express Client“, um Abfragen auf unseren Oracle-Datenbanken (9i) durchzuführen.

Bei der Einrichtung hatte ich seinerzeit viel zu basteln, deswegen freute ich mich nicht richtig auf die Aufgabe, auf einem Ubuntu-Client den Zugriff auf die Oracle-DB via UnixODBC einzurichten, um dort ein kleines Auswertungs-Tool programmieren zu können.

Aber es war garnicht so schlimm

Grundlage für die Installation war ein aktuelles Ubuntu 8.04 (Hardy Heron). Nach der Installation des o.g. Express Client von Oracle aus dem auf der dortigen Webseite angebotenen Debian-Paket, tauchte im Anwendungsmenü sofort ein Link zu SQL*Plus auf.

Nach dem Aufruf des Programms war über:
connect user/passwort@server:port/sid
die Verbindung sofort aufgebaut.

Herrlich

Jetzt zur Zitterpartie ODBC - die sich im Übrigen als nicht wirklich kompliziert herausstellte, wenn man denn fertige Ini-Dateien als Muster hat …

Als Grundlage werden eigentlich nur die Pakete unixodbc und unixodbc-bin benötigt.

Das zugehörige Tool ODBCConfig stellte sich dann jedoch quer, als es um die Anlage von Treiber und DSN ging und stellte wiederholt mit der Meldung:

ODBCConfig: ltdl.c:3104: try_dlopen: Assertion `filename && *filename’ failed.
Aborted

seinen Dienst ein.

Aber zum Glück lassen sich die Konfigurationsdateien auch händisch pflegen.

Dabei sollte die /etc/odbcinst.ini so aussehen:
[Oracle10g]
Description = Oracle 10g ODBC Driver
Driver = /usr/lib/oracle/xe/app/oracle/product/10.2.0/client/lib/libsqora.so.10.1
Driver64 =
Setup =
Setup64 =
UsageCount = 1
CPTimeout =
CPReuse =

Auf diese Weise ist der Oracle-Treiber schon einmal verfügbar.

Jetzt zur DSN, die sich entweder als System-DSN unter /etc/odbc.ini befindet, oder unter selbigem Namen als User-DSN im eigenen Homeverzeichnis Platz findet:
[TEST]
Application Attributes = T
Attributes = W
BatchAutocommitMode = IfAllSuccessful
BindAsFLOAT = F
CloseCursor = F
DisableDPM = F
DisableMTS = T
Driver = Oracle10g
DSN = TEST
EXECSchemaOpt =
EXECSyntax = T
Failover = T
FailoverDelay = 10
FailoverRetryCount = 10
FetchBufferSize = 64000
ForceWCHAR = F
Lobs = T
Longs = T
MetadataIdDefault = F
QueryTimeout = T
ResultSets = T
ServerName = ora_tst:1529/test
SQLGetData extensions = F
Translation DLL =
Translation Option = 0
DisableRULEHint = T
UserID = testuser
StatementCache=F
CacheBufferSize=20

Und nachdem man “/usr/lib/oracle/xe/app/oracle/product/10.2.0/client/lib/” in seine ld.so.conf aufgenommen, und den Cache mit ldconfig erneuert hat, steht einer Oracle-Verbindung über ODBC (beispielsweise mit dem DataManagerII) nichts mehr im Wege:

Bleibt mir nun “nur” noch die Programmiererei.

Eeeeeeeeewig hat’s gedauert, aber da ich sowieso gerade am Blog ‘rumbastel, habe ich einen Fehler behoben, der mir (und auch einigen Bloglesern) schon lange auf die Nerven ging.

Denn standardmäßig ersetzt Wordpress zwei Minuszeichen durch einen Gedankenstrich, macht also aus “- -” ein “–”.

Das nervt nicht nur, sondern verursacht, gerade in Shellscripten, auch Fehler und Missverständnisse.

Wem es ähnlich geht, der öffne die Datei wp-includes/formatting.php und suche dort nach “$static_replacements”. Die ersten drei Array-Elemente enthalten den Übeltäter.

Weitere Darstellungsfehler werde ich bei der gerade in Arbeit befindlichen Komplettrenovierung des Layouts berichtigen.

Wie oft möchte ich bei Präsentationen, denen ich beiwohnen muss, einfach mal Don McMillan ein paar Dinge geraderücken lassen…

.

Da hat es draußen endlich einmal sonnige Mittzwanziger auf der Temperaturskala, da macht in unserem Serverraum die Klimaanlage schlapp.

Auf knapp 30°C war die Raumtemperatur angestiegen, den ersten Servern drohte bereits die Puste auszugehen. War schon interessant zu hören, wenn bei allen Rechnern auf einmal die Lüfter im roten Bereich drehen.

Aber der alamierte Klimatechniker rettete selbstlos die Umgebungstemperatur vor weiterer Überhitzung und sicherte uns einen beruhigten Gang in den Feierabend. Von dieser Stelle aus dafür meinen besten Dank.

Ich habe soeben die Blogsoftware auf diesem Server auf den aktuellen Stand gebracht. Der Kalender läuft gerade nicht wirklich, auch optisch muss ich noch einiges nachfeilen (obwohl: das war in vielen Bereichen auch vorher so *hüstel*).

In kurz: ich arbeite dran - aber nicht mehr heute Nacht

So sieht’s aus, wenn das Design über der Usability das Aussehen über der Benutzbarkeit steht:

(Gesehen bei Andy)

Für “Zak McKracken 2 - Between Time and Space” gibt’s zwar schon einige Spiegel-Server, doch seit gerade bietet auch winboard.org das Spiel zum Download an.

Da werden Erinnerungen wach. Vor zwanzig Jahren veröffentlichte Lucas Arts nach “Maniac Mansion” das mindestens genauso abgedrehte “Zak McKracken” für den C64.

Ich habe diese Adventures, wie auch die weiteren Lucasfilm-Spiele wie “Day of the Tentacle”, “Sam’n'Max” oder die Indiana-Jones-Reihe geliebt. Sogar Loom habe ich gerne gespielt.

Gerade lese ich auf Golem.de, dass sich einige Zak McKracken-Fans hingesetzt haben, und einen inoffiziellen Nachfolger des Spiels programmiert haben. “Zak McKracken - Between Time and Space” heißt das Teil, und sieht ziemlich vielversprechend aus. Und Freeware ist es auch noch. Leider gibt’s nur eine Windows-Version.

Da muss ich wohl doch nochmal Wine reaktivieren. Hoffentlich läuft’s damit …

Im Forum heißt es zumindest, dass es mit kleinen Abstrichen funktionieren soll. Ich bin gespannt.