echo $begrüßung;
Als erstes habe ich die MySQL Klasse aus dem Wiki von phpbar.de verwendet: http://www.phpbar.de/w/MySQL_Klasse
sobald die Klasse included wird, wird mir eine leere Seite ausgegeben, aufgrund irgend eines Fehlers im PHP Skript.
Der veröffentlichte Quelltext hat einen simplen Syntaxfehler in Zeile 22 von TDatabaseResultSet. Es ist außerdem sehr wahrscheinlich, dass auf deinem System display_errors ausgeschaltet ist, was dann eine leere Seite ergibt.
Syntaxfehler werden einem gleich beim Tippen angezeigt, wenn man eine PHP-Entwicklungsumgebung verwendet. Ein einfacher Editor, der unter anderem eine PHP-Unterstützung mitbringt, wird diesen Fehler nicht finden, denn der Quelltext muss dazu ständig geparst werden. Es muss dazu schon etwas vom Kaliber PHPEdit, Eclipse mit einem der PHP-Module oder Zend Studio sein.
Warum der Autor in Zeile 37 von TMySql
if (!$this->resource = mysql_connect($host, $user, rawurlencode($passwd)))
rawurlencode() verwendet ist mir auch ein Rätsel, schließlich handelt es sich bei einem MySQL-Connect nicht um einen URL-Kontext. Diese Funktion führt nur dazu, dass einige Sonderzeichen in Passwörtern nicht verwendet werden können. Du solltest diesen Funktionsaufruf entfernen, nicht dass du damit die nächsten Probleme bekommst.
Außerdem schließe ich mich Svens Meinung an. Diese Klasse ist nichts weiter als ein objektorientiertes Interface zu den alten mysql_*-Funktionen. Sie bietet keinen Mehrwert. Dafür fehlt ihr beispielweise die Funktionalität der Funktionen mysql_num_rows(), mysql_affected_rows() und mysql_insert_id(). Das Projekt ist zwar so aufgebaut, dass auf die abstrakte Klasse TDatabase mehrere konkrete Datenbankimplementationen (TMySql, TPostgress, etc.) aufgesetzt werden können, doch eine Factory-Funktionalität, die anhand eines konfigurierbaren Werts die zu verwendende konkrete Implementation wählt, fehlt. Somit wird der Vorteil einer Austauschbarkeit der Datenbank eingeschränkt, weil im gesamten Quelltext einer Anwendung die Instantiierungen von TMySql gegen z.B. TPostgress getauscht werden müssen. (Abgesehen davon, dass der Wechsel zu einer anderen Datenbank ein eher seltener Anwendungsfall ist.)
Das wesentlichste Manko ist jedoch die fehlende Unterstützung eines Escapings. Was nützt dir ein generisches Datenbank-Interface, wenn zum Escaping doch wieder native Funktionen wie mysql_real_escape_string() aufgerufen werden müssen? Auch die Quotierungszeichen müssen von einer Anwendung gleich datenbankspezifisch in den SQL-Statements angegeben werden.
Des weiteren ist die Arbeitsersparnis beim Einsatz dieser Klassen effektiv nicht vorhanden. Du benötigst weiterhin die Schritte 1. Connect, 2. Statement zusammenstellen, 3. Absenden, 4. Ergebnis abholen. Schritte 1 und 3 müssen wie üblich mit einer Fehlerbehandlung versehen werden, nur dass diese nicht mehr "if (! fehler) {...} else {...}" sondern "try {...} catch {...}" lautet.
Ich sehe einen Vorteil erst dann, wenn die Anwendung durch nur einen Funktions- oder Methodenaufruf an die gewünschten Daten kommt und der "Handarbeit" der 4 Schritte komplett selbständig von einer Datenverwaltungsschicht erledigt wird.
echo "$verabschiedung $name";