Microsoft scheint tatsächlich langsam aber sicher bei den Druckertreibern aufzuräumen - ein Installationsversuch eines leicht betagten HP LaserJet 4MP (Baujahr 1993) unter Windows 7 förderte auf den ersten Blick keinen passenden Treiber zu Tage.

Glücklicherweise bietet der “Drucker hinzufügen”-Dialog einen Button, der direkt mittels “Windows Update” nach einem passenden Treiber sucht - und voila

der Drucker kann installiert und verwendet werden und muß somit noch ein paar weitere Jährchen auf seine wohlverdiente Rente warten.

Ab und an kann es passieren, daß sich MySQL beim AUTOINCREMENT verschluckt und versucht, einen Wert anzulegen, der bereits existiert.

Zur Fehlerbehebung gilt es, den aktuellen AUTOINCREMENT-Wert zu ermitteln, der nach dem Ausführen von

mysql> SHOW TABLE STATUS FROM <datenbank> WHERE Name = '<tabelle>';

in der Spalte ‘Auto_increment’ zu finden ist. Anschließend kann mittels

mysql> ALTER TABLE <tabelle> AUTO_INCREMENT = <wert>;

ein neuer Startwert gesetzt werden.

Stellt sich Oracle beim Datenbank-Recovery etwas umständlich an, so muß man etwas tiefer in die Trickkiste greifen:

Erfahrungsgemäß läuft ein

RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL;

meist damit gegen die Wand, daß Oracle versucht, auf ein nicht existierendes, archiviertes Logfile zuzugreifen. Ergebnis sind in der Regel der Fehler

ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '<woauchimmer>system01.dbf'

was aber nicht unbedingt bedeutet, daß sich das Problem tatsächlich auf die eine Datei beschränkt.

Sollte dies der Fall sein, muß für ein erfolgreiches Recovery noch das aktuelle Redo-Log verwendet werden. Hierzu ist zuerst das aktuelle Log zu ermitteln

SELECT member FROM v$logfile , v$log WHERE v$log.status='CURRENT' AND v$logfile.group# = v$log.group#;

anschließend nochmals ein Recovery zu starten, hierbei allerdings weder ‘AUTO’ noch ‘CANCEL’ zu wählen sondern das soeben ermittelte Logfile anzugeben.

RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL;

Hat alles geklappt, sollte ein

ALTER DATABASE OPEN RESETLOGS;

zum gewünschten Erfolg führen.

Was letztendlich der ausschlaggebende Grund für Nick Mason war, “Inside Out” zu veröffentlichen bleibt auch nach dem Lesen des Buches im Ungewissen. Mit einem akribischen Wälzer, der jeden kleinsten Schritt der Band nachzeichnet will und kann “Inside Out” nicht konkurrieren.

Angefangen von den ersten mehr oder weniger erfolgreichen musikalischen Gehversuchen über die Entwickling des klassischen Pink Floyd-Sounds, die ersten Erfolge, dem Austauschl von Syd Barrett durch David Gilmour, dem Split mit Roger Waters sowie die Wiedervereinigung beim Live 8-Auftritt 2005 beleuchtet Nick Mason humorvoll die verschiedenen Bandphasen und scheut dabei nicht zurück, auch eigene Verhaltensweisen kritisch zu reflektieren.

“Ich habe sämtliche Referenzbücher über Pink Floyd mit einem Lächeln wieder weggelegt. Lieber Autor, das hast Du Dir schön ausgedacht, aber so ist es nun wirklich nicht gewesen.” - Nick Mason

Der Autor, der Schlagzeuger und einiziges durchgängiges Mitglied der 40-jährigen Bandgeschichte ist, liefert ein sehr persönliches Porträt und raubt manchem Mythos, der sich im Laufe der Zeit um die Band legte, die Grundlage. So entpuppt sich der teilweise zur Musikerfehde des Jahrhunderts hochstilisierte Split mit Roger Waters als eine Mischung aus mangelnder Kommunikationsfähigkeit und schlechtem Timimg, wie sie wohl nicht nur Bands tagtäglich durchleben.

Sich durchaus bewusst, daß seine Sicht der Dinge nicht die einzig wahre ist, wurde das “Inside Out” vor Veröffentlichung auch von seinen (ehemaligen) Bandkollegen David Gilmour, Roger Waters sowie dem inzwischen leider verstorbenen Rick Wright gelesen und gründlich kommentiert - einzig die Sichtweise Syd Barrets bleibt unberücksichtigt, hatte sich dieser doch auf Grund seines psychischen Verfalls seit seinem Ausstieg immer mehr von der Außenwelt zurückgezogen. Illustirert wird das Buch von einer ganzen Reihe Photos, die nicht in die Rubrik “schon tausendmal gesehen” fallen - und selbst wenn, ist es meist eine Aufnahme, die doch aus einem anderen Blickwinkel gemacht wurde oder ein bisher unbekanntes Detail zeigt.

“Inside Out” nimmt den Leser mit auf eine rund 400 Seiten starke vergnügliche Zeitreise, bei der man - obwohl der Ausgang der Geschichte längst bekannt ist - immer wieder Neues und Spannendes entdeckt.

Nachdem monatelang Apache 2.0.63, PHP 5.2.6 und MySQL 5.0.51 in trauter Einigkeit gewerkelt haben, wurde - never change a running System - zeitgleich mit einem Hardware-Upgrade auch eine Betriebssystem-Neuinstallation sowie ein Update der installierten Software auf die jeweils aktuellen Versionen vorgenommen.

Der Apache blieb bei der alten Version, PHP auf 5.2.9 modernisiert und auch MySQL auf die Version 5.1.35 angehoben. Die Installation lief problemlos und auch der obligatorische Aufruf eines phpinfo(); zeigte im Browser das erwartete Ergebnis.

Weniger erwartet war aber, daß sich beim Aufruf fast jeder lokalen PHP-Seite der Webserver mit einem “Application Error” verabschiedete und Windows gerne einen Bericht an Microsoft schicken wollte. Die einzige Gemeinsamkeit an den nicht funktionierenden Seiten waren Zugriffe auf die Datenbank, immerhin eine Spur.

Nachdem ein testweises Downgrade von PHP keine Änderung (= Linderung) des Problems brachte, hat der Rückschritt auf den 5.0’er MySQL die Symptome wie von Geisterhand kuriert

Die Ursache? Wahrscheinlich irgendwo im Zusammenhang mit “MySQLs PHP-API”, aber nachdem es weder in den Windows-Protokollen (daß Apache abgeschmiert ist, weiß ich selbst) noch in den Apache-Logs (die “error.log” ist eben kein Crash-Log) einen brauchbaren Anhaltspunkt zur Fehlersuche gibt, wird die Lösung erstmal vertagt.