…nerdy by nature!

Sofern man versucht, einen von mysqldump erzeugten Datenbankdump in einen (anderen) MySQL-Server zu importieren, kann man unter Umständen auf folgende Fehlermeldung stoßen:

Unknown command '\0'

Die wahrscheinlichste Ursache sind Datenfelder vom Typ BLOB, welche mysqldump beim Speichern im Textformat nicht richtig kodiert hat.

Der einfachste Weg zur Umgehung dieses Problems besteht darin, bereits beim Exportieren der Datenbank die Option –hex-blob zu setzen:

mysqldump -ubenutzername -p --hex-blob datenbankname > datenbankname.sql

Damit erzeugt mysqldump für jeden BLOB eine hexadezimale Repräsentation, wie es beispielsweise auch bei phpMyAdmin seit geraumer Zeit Standard ist.

Wenn man viel mit (objektorientiertem) PHP arbeitet, stößt ab und an auf die wenig aussagekräftige Fehlermeldung “Exception thrown without a stack frame in Unknown on line 0“.

Dieser Fehler ist wenig hilfreich, insbesondere bricht die Programmausführung ab und man hat keine Möglichkeit zu erkennen, wo die Ursache der Meldung liegt. Ich habe diese Meldung häufig erhalten und nie versucht zu begreifen, was sie eigentlich bedeutet. Stattdessen habe ich solang am Code gepatcht, bis das Programm wieder lief. Für alle, die ähnliche Probleme haben, findet sich hier eine Übersicht der Ursachen dieser Meldung.

Solange PHP “normal” läuft, erzeugt es für jede geworfene Exception einen Stacktrace, bei nicht abgefangenen Exceptions wird dieser Stacktrace im Log ausgegeben. Es gibt jedoch bestimmte Zustände, in denen PHP noch nicht respektive nicht mehr vollständig läuft, in diesen Fällen ist es scheinbar nicht möglich, einen Stacktrace zu erzeugen. Die folgende (nicht vollständige) Liste enthält alle  Ursachen, die mir bisher untergekommen sind:

• Eine Exception im benutzerdefinierten Exception-Handler werfen: Wen man in PHP mittels set_exception_handler() eine Funktion registriert, die ihrerseits eine weitere Exception wirft, kann PHP mit dieser nichts anfangen und gibt exakt die oben genannte Fehlermeldung aus.
  Somit ist es ratsam, im Exception-Handler sämtlichen Code in einen try-catch-Block zu verfrachten und etwaig auftauchende Exceptions beispielsweise mittels error_log() in den Log zu schreiben.
• Im Konstruktor oder Destruktor Exceptions werfen: Eine Exception im Konstruktor sorgt dafür, dass das Objekt nicht vernünftig erzeugt wird, es wird somit in einem undefinierten Zustand hinterlassen. Im Destruktor hingegen kann es sein, dass das Objekt (oder andere, referenzierte Objekte) bereits nicht mehr existieren. Auch hier ist es ratsam, alle Funktionsaufrufe, die potentiell eine Exception werfen können, mit einem try-catch-Block zu umschliessen.
• Exceptions im Autoloader: Es scheint nur teilweise der Fall zu sein, dass eine im mittels spl_autoload_register() registrierten Autoloader geworfene Exception ebenfalls diese Fehlermeldung erzeugt.

Diese Liste ist sicher noch nicht vollständig, sofern mir neue Ursachen unterkommen füge ich sie entsprechend ein.

Die Typo3 version 4.3.3 scheint einen Fehler im Installtool aufzuweisen. Bei der Erstinstallation im 1-2-3-Mode werden auf der ersten Seite zunächst die Datenbankparameter abgefragt. Nach einem Klick auf Submit wird man auf eine Fehlerseite weitergeleitet, die nur folgende Meldung enthält:

no database selected

Außerdem werden in der localconf.php keinerlei Datenbankparameter hinterlegt und es gibt keine Möglichkeit, mit der Installation fortzufahren.

Ein einfacher Workaround hierzu ist es, die Datenbankparameter direkt in der Konfigurationsdatei einzufügen. Dazu öffnet man einfach die Datei typo3conf/localconf.php mit einem Texteditor und passt die folgenden Zeilen an die eigenen Gegebenheiten an:

$typo_db_username = 'user';
$typo_db_password = 'password';
$typo_db_host = 'localhost';
$typo_db = 'dbname';

Anschließend kann man die Fehlerseite im Installtool neu laden und die Installation mit dem Importieren des Datenbankdumps fortfahren.

Tipp: Falls man das Installtool schon weggeklickt hat oder nicht mehr im 1-2-3-Mode ist nutzt man den folgenden Link:

http://serveradresse/typo3/install/index.php?mode=123&step=2

Ich habe mich immer gefragt, warum bestimmte Programme wie phpMyAdmin in von ihnen generierten SQL-Queries immer Backticks verwenden, während andere System diese nie nutzen.

Der Grund dafür ist eigentlich sehr simpel und soll in einem kurzen Beispiel erläutert werden. Angenommen, innerhalb einer Datenbank soll folgende Tabelle erzeugt werden:

Table-1

Das ist in MySQL ein durchaus gültiger Tabellenname. Um nun den Inhalt dieser Tabelle aufzulisten würde man beispielsweise den folgenden Query nutzen:

SELECT * FROM Table-1;

Weit gefehlt, anstatt den Inhalt der Tabelle zu Gesicht zu bekommen erhält man eine Fehlermeldung wie “You have an error in your SQL syntax”. Wenn man sich den Query genauer ansieht wird man feststellen, dass dieser nicht eindeutig ist. Der Parser kann also nicht mit Sicherheit sagen, ob man die Tabelle Table-1 referenzieren möchte oder von einem Feld mit dem Namen Table die Eins subtrahieren möchte.

Um dem Parser genau zu erläutern, was gemeint ist, nutzt man einfach die Backticks, die den von ihnen eingeschlossenen Inhalt als Feld-, Tabellen- oder Datenbanknamen ausweisen:

SELECT * FROM `Table-1`;

Natürlich gilt gleiches auch für andere Feld- oder Datenbanknamen. Ein weiteres (beliebtes) Beispiel ist eine Tabelle, die ein Feld max oder min enthält. Hier ist sich MySQL nicht darüber im Klaren, ob die Funktionen MAX() respektive MIN() oder das entsprechende Feld gemeint ist.

Ein Hinweis für tippfaule Leute: Es ist durchaus möglich, die Backticks nur bei benötigten Teilen des Queries zu nutzen.