Einer der Haupthinderungsgründe für den Weiterbetrieb der Alertbird-Software war ja immer der Ressourcenbedarf (sowohl Rechner- als auch Geld-) der Oracle-Datenbank. Meine Umbautätigkeiten bestehen deshalb bisher zum größten Teil aus Änderungen, um die Daten in Zukunft in einer PostgreSQL-Datenbank halten zu können. Leider habe ich die alten Daten nur in Form eines exp/imp-Dumpfiles für Oracle 8i, drum mußte ich tricksen:
Aus der Arbyte habe ich mir eine virtuelle VMWare-Maschine mit Oracle 9i drauf ausgeliehen, dort den Dump eingespielt und mit einem JAVA-Programm die Daten in die Postgres rüberkopiert (solche Programme sind schnell geschrieben, das habe ich schließlich im FleetBoard-Projekt lange genug geübt). Leider waren nachher alle Umlaute weg (bzw. es war ein Bit abgeschnitten — die Leute heißen dann z.B. „Jvrg“). Kurz nachgesehen: die Umlaute waren aber auch in der Quelldatenbank schon weg, am Kopierprogramm liegt’s also nicht. imp nochmal ausgeführt: da steht doch tatsächlich, die Daten seien US7ASCII-Kodiert. Ohje, sollten die Umlaute etwa beim Export schon verschwunden sein? Dann wären sie seit 2004 weg und wohl nicht wieder aufzutreiben…
Zum Glück waren die Umlaute in der Datei selbst vorhanden, da stimmte wohl nur die Deklaration nicht (das bedeutet übrigens gleichzeitig, daß Umlaute in Alertbird in der Vergangenheit nur deshalb funktioniert haben, weil Oracle sich vor Version 9 nicht um den Inhalt des achten Bits geschert hat, wenn ein 7-Bit-Zeichensatz eingestellt war). Hier fand ich eine Erklärung, wie die Zeichensatzangabe in die Exportdatei kommt. Ich brauchte also nur einen Hexeditor…
… und mußte den Anfang der Datei von „03 00 01 …“ auf „03 00 1F…“ ändern, nochmal in Oracle importieren und die Kopie noch einmal starten.
Das sieht doch schon ganz gut aus (an den Datumsfeldern muß ich aber noch feilen, die verlieren noch alle ihre Uhrzeit):
