Die ganze Wahrheit dazu: Notizen sind einfach, Kalenderdaten schwierig und Adressen ein Alptraum. mehr






Legen Sie bereit: •  ein backup ihrer Notes-nsf (die eigentlichen Notes-Datendateien) •  ihre personalisierte ID (ohne die paranoid verkryptete nsfs nicht zu öffnen sind) •  einen separat zu installierenden Notes-client selben Baujahres •  einen regular expressions sprechenden Texteditor, einigermassen Zeit und Tranquillizer.

Am Einfachsten ist es, den Notes-Client auf ihrem Rechner zu installieren. Nehmen wir der Einfachheit halber einen Wintel an. Die default-Dateien des jungfräulichen Notes-clients liegen in c:\Programme\Lotus\Notes\data. Diese "nsf" scheinen "Notes-files" zu sein. Mit einem Wald-und-Wiesen-Editor kommen Sie da nicht ran weil verschlüsselt. Taschenspielertrick: Mit blank installiertem Notes-Client klicken Sie sich in einem Dateimanager ihres Vertrauens in das gesicherte Verzeichnis ihrer gebackupten Notes-Daten. Ihre Maildatei heisst meist mail.nsf oder [ihr-company-login-name].nsf. Gefunden. Gut. Doppelklicken. Voilá: das alte Mailfile öffnet sich im neuen Notes-Client. Die ganze Sicherheit perdú: das id-file reicht. Heidewizcka! Jetzt sind erstmal alle gesendeten und empfangenen mails wieder da.

Finden Sie Ihre Daten: Kalenderdaten stecken etwa im NOtes-mailfile. Nein, da würde man sie nicht vermuten. Der gewohnte Kalender ist lediglich eine Sicht auf dieses nsf. Auf diese Sicht gelangen Sie mit /Ansichten/AlleKalenderdokumente und die wiederum stecken unterhalb des windigen Papierkorbsymboles in der linken Ordneransicht. Aufmachen. Würden Sie nun diese Daten allesamt markieren und in einen Texteditor exportieren, würde nicht viel geschehen. Denn: Notes verteckt die wesentlichen Daten zu Terminen. Warum, das weiss nur der Entwicklungschef.

Was brauchen wir mindestens? Für jeden Kalendereintrag jeweils ein Datum und Zeit für Beginn und Ende des Termines, noch ein Subject dazu. Dies in einer tabellarischen Gliederung und mit der Hoffnung von da aus einen geeigneten Importweg zu finden, am Ende ist alles immer eine Tabelle, soviel weiss ich als Nicht-Programmierer. Alles andere kann über die Wupper. Wer braucht schon annotierte Termine. Wichtig allein ist mir jedenfalls mein biografisches Gedächtnis: Wann war ich wo?

Nun bringen wir der Datenbank bei zu zeigen, was sie in sich trägt. Das geht so: /Aktionen/Ansichtsoptionen/Gestaltung Wir sehen: nichts. Nur leere Zeilen samt Spaltenköpfen.

Die GUI-Designer bei Lotus sollen in der Hölle schmoren.

Am äussersten Fensterrand jeweils rechts und unten scheint der Fensterrand verdickt: packen und ziehen. Wir sehen nun zwei Rahmen: der rechte interessiert nicht, das untere ist der Schlüssel.Oben zwei Reiter Objekte und Referenz. Wir brauchen aus den Objekten nur zwei Werte: Beginn des Termines und Zeit, ditto Ende.

Die Lotus-Programmierer sollen die GUI-Designer bitte im Orkus besuchen gehen, der Prozess ist haarsträubend: zuerst eine neue Spalte einfügen (rechter Mausklick auf einen Spaltenkopf, Spalte einfügen). rechte Maustaste auf den eben eingefügten Spaltenkopf bringt das Eigenschaftenfenster nach vorne. Jetzt muss die Spalte wissen, dass Sie den Beginn eines Termines beherbergen soll. Dazu als Feld (nicht Formel!) den Eintrag STARTDATETIME in der Liste aller Felder finden. Dann bei Anzeige im unteren Frame kurz auf Formel wechseln und nach STARTDATETIME einen Return. Unvermittelt erscheint neben Formel ein grünes Hackerl. Das klicken und fertig ist die Spaltenfüllung. Um die Spalte nun mit den korrekten Daten zu füllen, auf das kleine Schweinebürzel (nach rechts drehender Dreiviertelpfeil klicken. Alles wiederholen für EndDateTime. Grünes Hackerl. Wenn man nun wirklich will, kann mit Rechtsklick auf die Spaltenköpfe in der Ansichtsgestaltung noch die auf-/ab-Sortierung beigeben, doch das ist alles unwürdige Kosmetik.

Die Änderungen an der soeben exportfähig gemachten Ansicht speichern (haut euch gegenseitig auf die Finger da unten im Fegefeuer, GUI-Designer, Lotus-Ingenieure: zum Sichern auf das Kreuzchen klicken, dann "ja"? Allesamt Meschugge seid ihr.)

So, vollbracht. Jetzt sind alle Kalenderdaten exportierbar. Dies als Lotus-1-2-3 (arrgn) Datei, als CSV (comma separated values) oder als tab-delimited. Da man nie wissen kann, wo in Terminen sich ein Komma versteckt haben könnte und noch viel weniger klar ist, wie NOtes CSVen exportiert, scheidet csv als Exportformat aus. WKS ist ein Format, das von Excel importiert und (von da aus als CSV auch sauber) exportiert werden kann. Ohne Excel ist tab-delimited, also die Feldinhalte durch Tabulatoren (\t) getrennt, die beste Wahl.

Im Abfragefenster Alle Dokumente und mit Ansichtstiteln wählen. Beten.

Jetzt wären die Kalenderdaten auf einer tabellarischen Halde. Dort wollen die Daten wieder heraus.

Nehmen wir für den Moment nur an, man verschriebe sich an OutlookXP (OLK). Ja, es gibt andere PIMs, nein, es gibt keinen akzeptablen OpenSource PIM. Das alles wäre so gotteinfach, wenn OLK strukturierte NOtes-Daten einfach einlesen würde. Tut es nicht, jedenfalls so lange nicht, wie man stand-alone, ohne NOtes und ohne Exchange-Server arbeitet. Bei der corporate migration von NOtes zu Exchange scheint das zu klappen ... doch in der Fabrik, da sind wir nicht mehr.

Weiter mit den Adressen.

NOtes kann sogenannten structured text exportieren und schreibt dann alle Felder pro Eintrag nacheinander, ganz gleich, ob in diesen Feldern Daten stehen. Für 1200 Adressen entstehen dann 4,5 MB ASCII-Text. Diesen muss man dann von jenen Feldern befreien, die in der freien Welt keinen Nutzen mehr haben. Das geht mit einem ordentlichen Texteditor und unter Zuhilfenahme von regular expressions. Letztere sind kompliziert und gleichsam mächtig.

[Drei Tage später.]

Die Adressdaten sind nun bereinigt, für jede Adresse bleiben nur die Daten übrig, die tatsächlich Information tragen. Die Datensätze sind naturgemäss "schmutzig", da nicht jeder Eintrag alle Felder bestückt hatte. Dieses Ergebnis nun in eine Tabellenkalkulation übertragen und zurechtrücken. Zuvorderst sollten alle harten Returns durch \n ersetzt werden, denn quoted printable kann wiederum von OLK nicht importiert werden. Lernt man alles, wenn man es nicht schon weiss.

Dieser unfassbare Aufwand wäre nicht nötig, wenn NOtes die weithin akzeptierten und standardisierten Formate vcf für Adress- und und vcs für Kalenderdaten in aktueller Definition exportieren könnte.

Ja, NOtes kann nach vcf exportieren aber nur in einem Substandard, aus dem heraus wiederum kein Import in OLK stattfinden kann. NOtes exportiert Adressen etwa in ein .list.vcf-file. OLK kann zwar separierte .vcf-files lesen, nicht aber .list.vcf-files. OLK importiert nur den jeweils ersten Eintrag und ignoriert alle anderen. Weshalb, das wissen nur die OLK-Programmierer in der Nebenhölle.

Um vcf in Version 3 nutzen zu können, müssen die in einem einzigen list.file zusammengeschriebenen vcfs in einzelne gesplittet werden. Könnte man sich nun ausgooglen, meint man. Leider nein.

Ein Skript aus einer Mailingliste scheint zu tun, was erwartet wird:

#!/usr/bin/perl

if (@ARGV !=1) { print "usage: vcf-split.pl <list.vcf>\n"; exit; }

$src = shift @ARGV;

$out = 'out/'; # uncomment to change the diretory to save .vcf files

open SRC, $src or die "*** error: cannot open file $src\n";

$n = 0; $vcf = ''; foreach () { next unless (/^BEGIN:VCARD/ || $vcf);

$vcf .= $_;
$file = $1 if /^X-EVOLUTION-FILE-AS.*:(.*\S)/;

vcf();

} vcf();

close SRC; print "*** $n vcards saved.\n";

sub vcf { if (/^END:VCARD/) { $n++; $file = $n unless $file;

open OUT, ">$out$file.vcf";
print OUT $vcf;
close OUT;

$vcf = $file = '';
}

}

Dazu muss man lediglich Indigoperl samt einem Apacheserver Perl installieren, PHP gibt es als Gratiszugabe. Schwache 100 MB. Harte Kost für einen Nichtprogrammierer.

Das Skript tut wie befohlen. Allerdings stehen die in Einzeldateien gesplitteten vcfs in einer Codierung, bei der OLK nur wieder die unmittelbar nach dem Feld "NOTES:" stehenden Daten übernimmt. Also müssen die eingefügten \n wieder entfernt werden, suboptimalerweise zu Leerzeichen. Man weiss ja nicht, welche Zeichen beim Import in OLK akzeptiert werden.

[Vier Tage später.]

Kalenderdaten sind nun in OLK importiert, mit spontanen Datumsverschiebungen und wirren Irrläufern.

Die Adressendaten blieben in Summe erhalten aber haben sich um lesbare Notizen erleichtert ("\n durch Leerzeichen"), einen Tod muss man sterben.

Nein, man hätte all´ das nicht mit dem "Personal NAB Import / Export Utility" aus der Lotus Sandbox lösen können, denn dieses schmutzige Stück Software verhält sich agnostisch den an Adressen angeflanschten Notizen gegenüber. Nein, dort gibt es kein Werkzeug, das alles kann. Nein. Nein. Nein.

[Zwei Tage später.]

Meine Daten gehören mir und die Erde ist eine Scheibe.

Oder wie der Ingenieur sagte:

"Ich will keinen inkompatiblen Gack Outlook Dreck Extrawurscht Scheiß Formatier Exchange Gagel vi telnet Nerdie Wix Sonderformat Krankhirn Stuff Gnutella Scheiße, sondern etwas, was alle schon länger benutzen, was nicht nur einer Firma gehört, was offene Schnittstellen hat, worüber sich kluge Leute lang genug Gedanken gemacht haben, und was deshalb funktioniert. Und mit dem Rest kann mir die IT-Welt wirklich kreuzweise den Arsch ausschlecken." -- on Thu, 21 Sep 2000 17:41:19 GMT

ActiveState Perl geht nicht?

...und wozu der Webserver? ActiveState Perl kommt alleine, also ohne unnötigen Überhang und ist auch nicht so groß. www.activestate.com

Vielleicht hilft das ja.


Weiss der Deibel ... weiss ich, was ActiveState ist? Nein. Eben. Das erste sich andienende Paket, wurde installiert. Indigo mochte ich eh´ gerne. Das wenigstens hat geklappt.


:)

ActiveState perl ist eine einfache Perldistribution für Windows, klein und fein. Wobei mein Favorit natürlich immernoch "das Original" ist, aber das geht natürlich mit Windows nicht.