Probleme bei der Ausgabe von Texten in UTF8 unter Perl ? So für Schnittstellen, und ähnliches ?
Kein Problem:
Nach öffnen des Ausgabestreams (File, oder ähnliches) einfach ein simples binmode FILEHANDLE,":utf8"; implementieren, und schon klappt es mit dem Charset. Wieso das auf einigen Systemen (z.B. Solaris) auch ohne Binmode geht (das setzen der Environment-Variable “LANG” auf de_DE.UTF half hier), weiss ich nicht. Aber so funktioniert es in jedem Falle !
Mobile.Me ist ja irgendwie fein. Allerdings haben sich meine Macs strikt geweigert, auch nur im Ansatz die korrekten Inhalte des Kalenders zu synchronisieren. Nun woran lag es ?
Kurz und bündig: Die “SyncData” ist quasi “out of Sync”. Soll heissen: Der Mac weiss nicht (mehr) was er synchronisieren soll, und was nicht.
Auf einschlägigen Seiten (z.B. der KB von Apple) wird ein hierzu Reset der Sync Data empfohlen. Allerdings ist diese in den Systemeinstellungen für Mobile.Me nur halbherzig implementiert. Ein Blick ins /var/log/system.log bringt folgende Meldungen zu Tage:
Sep 16 19:03:11 powermac iCalExternalSync[822]: SyncServices precondition failure in [ISyncConcreteSession clientAcceptedChangesForRecordWithIdentifier:formatted-Record:newRecordIdentifier:]: you can't change the record identifier from BLUBB-DIWUPP-HEXKEY-WIEBEI-WINDOOFS to com.apple.ical.calendars.RootNode: it is already associated with a different record.
Dem Mac das abzugewöhnen war garnicht so einfach (Naja, der Weg dahin war steinig, der Rest ist leicht 🙂 Fangen wir also an:
War der einzigste Weg bei mir, der ganze 3 Rechner wiederbelebt hat. Alle anderen “Tricks” aus irgendwelchen Apple-Foren haben garnichts gebracht. Die “Magic” steckt einzig und allein in Punkt 5 und 6 oben. Ich nehme an dass “iSync-Verlauf zurücksetzen” genau das tun sollte, was ich in Punkt 5 beschreibe. Macht es aber leider nicht. Naja, mit der Anleitung oben wird man dann auch glücklicher Mobile.Me Nutzer 😉
Viel Spass
Ein Update des DBD::Oracle Treibers von 1.16 auf 1.21 klingt zunaechst unspektakulaer. Aber wie so oft steckt der Teufel im Detail. Benutzt man nämlich persistente Verbindungen unter mod_perl mit dem Modul Apache::DBI, ändert sich das Verhalten beim disconnecten von der DB. In der Regel cached das mod_perl die Verbindungen ja, daran hat sich auch nichts geaendert.
Bei der 1.16er Version jedoch impliziert das disconnect ein commit. Das hängt laut Modul-Doku von gutdünken des (Modul-)Entwicklers ab. Hat man seine Applikation jetzt darauf ausgerichtet, dann macht man nie ein Commit (sollte man nicht tun !). Dumm nur, dass dieses Verhalten bei der 1.21er geändert wurde. Nun impliziert das Modul beim disconnecten nämlich ein Rollback. Und das macht es selbst dann, wenn ein commit vorrausgeht.
Im ersten Ansatz ist das verschmerzbar. Wenn die DB allerdings, selbst bei Skripten die nur SELECTen, jedesmal mit einem Rollback belaestigt wird, kommt da schon einiges zusammen. Das Verhalten lässt sich mit folgendem “Workaround” aendern:
Aus einem $dbh->disconnect() wird ab sofort ein
$dbh->{AutoCommit}=1;
$dbh->disconnect();
Das AutoCommit wird also kurz vorm disconnecten gesetzt, und beeinflusst das sonstige Rollback/Commit-Verhalten im gesamten Skript ueberhaupt nicht. Sobald ein neues Connect (auch in einer persistenten mod_perl Umgebung) kommt, werden (auch bei gecachter DB-Verbindung) die Parameter AutoCommit, etc., eh neu gesetzt. Damit verhält sich alles wieder wie vorher.
