mysqli - SELECT Abfrage mit prepared Statements

[Hugo Egon Balder]

Hallo Forum,

immer, wenn ich denke, ich habe zumindest einen Teil der Arbeit mit Datenbanken verstanden, komme ich danach drauf, dass ich offensichtlich _überhaupt nichts_ kapiert habe. Es ist echt zum Heulen.

Mit php/mysqli möchte ich alle Datensätze ausgeben, in denen "Hans" der Name ist. Hier der Weg ohne prepared Statements:

$sql="SELECT `id`,`name`, `stadt` FROM `foo` WHERE `name`='Hans'";  
$result=$db->query($sql);  
while($line=$result->fetch_object())  
  {  
    echo"<p>".$line->id." - ".$line->name." - ".$line->stadt."</p>\n";  
  }

Das funktioniert einwandfrei. So, nun möchte ich die Ausgabe mit einem prepared Statement machen. Meine erste Überlegung war, hier einfach einen prepared Statement-Teil einzufügen. Das sah dann so aus:

$eingabe_name="Hans";  
$sql="SELECT `id`,`name`, `stadt` FROM `foo` WHERE `name`=?";  
$result=$db->prepare($sql);  
$result->bind_param('s',$eingabe_name);  
$result->execute();  
while($line=$result->fetch_object())  
  {  
    echo"<p>".$line->id." - ".$line->name." - ".$line->stadt."</p>\n";  
  }

Das endet in der Fehlermeldung "Fatal error: Call to undefined method mysqli_stmt::fetch_object() in ..." -betreffend die Zeile mit der while-Schleife. Da verstehe ich schon mal nicht, wieso es hier ein Problem gibt. Das prepared Statement betraf doch den Abfrage-Weg _zur_ DB. Das Ergebnis, also die Ausgabe der DB, sind doch einfach, wie im ersten Fall, die betreffenden Datensätze.

OK, nach dem Besuch von sicher mehr als 50 Seiten zu dem Thema und 10 Stunden vor dem PC, habe ich vor kurzem das erste Mal eine funktioiernede Lösung ohne Fehlermeldung zustandegebracht. Und ich habe keine Ahnung, wieso:

$eingabe_name="Hans";  
$sql="SELECT `id`,`name`, `stadt` FROM `foo` WHERE `name`=?";  
$result=$db->prepare($sql);  
$result->bind_param('s',$eingabe_name);  
$result->execute();  
$result->bind_result($id,$name,$stadt);  
while($result->fetch())  
  {  
    echo"<p>".$id." - ".$name." - ".$stadt."</p>\n";  
  }

Ich verstehe es einfach nicht. Wieso muss ich, nur weil die Übergabe des Suchparameters mit einem prepared Statement geschehen ist, plötzlich die betreffenden Datensätze mit "bind_result" behandeln und in Variablen überführen? Wieso funktioniert im ersten Fall eine Schleife mit "$line=$result->fetch_object()" - während im prepared Statement Fall plötzlich nur eine Schleife mit "$result->fetch()" funktioniert? Wieso plötzlich nicht mehr die Syntax "$line->id"?

Wie gesagt, ich verstehe nicht, wieso sich beim Code für die Ausgabe der betreffenden Datensätze plötzlich so viel ändert, nur weil die Suchbedingung nicht direkt im Query, sondern als prepared Statement eingefügt worden ist.

Ich bitte darum, dass mir jemand in verständlichen Worten, also nicht in Techniksprech, die Unterschiede zwischen den beiden Situationen erklärt und wieso das nicht so funktioniert, wie ich es laut 2. Beispiel ursprünglich gedacht hatte.

Mit bestem Dank im Voraus für jede Hilfe!

MfG

Hugo Egon Balder

[hotti]

Lieber Hugo,

Mit bestem Dank im Voraus für jede Hilfe!

Beim Arbeiten mit mysqli habe ich festgestellt, dass manche Dinge nicht so funktionieren, wie sie im Handbuch beschrieben sind. Mit PDO hingegen habe ich da bessere Erfahrungen gemacht und ich denke, das kann ich auch Dir empfehlen zumal mir PDO überhaupt ein bischen zukunftsträchtiger scheint als aldi anderen Datenbanktreiber, die PHP so mitbringt.

PDO ist, ähnlich wie Perl DBI, in Schichten aufgebaut, d.h., es wird demnächst auch Layer für andere, von MySQL abweichende DB Engines geben (Oracle gibts wohl schon nach meinem letzten Wissensstand).

Viele Grüße,
Horst Heitzer

[Hugo Egon Balder]

Lieber ... jetzt weiß ich nicht, was ich schreiben soll ...

Horst Heitzer, Rolf Rrost oder hotti? :-)

Beim Arbeiten mit mysqli habe ich festgestellt, dass manche Dinge nicht so funktionieren, wie sie im Handbuch beschrieben sind. Mit PDO hingegen habe ich da bessere Erfahrungen gemacht und ich denke, das kann ich auch Dir empfehlen

Zunächst mal Danke für Deine Antwort und den Input mit dem Stichwort "PDO". Ich muss gestehen, bis vor 20 Minuten habe ich davon noch _nie_ gehört. Die ersten Seiten, die ich dazu gefunden habe, schauen aber vielversprechend aus. Es dürfte halt leider noch nicht so viele Dokus und Tutorials geben. Aber rein gefühlsmäßig wirkt das auf den ersten Blick für mich viel klarer und strukturierter. Ich glaube, Du hast mir gerade etwas gegeben, womit ich mich über die Weihnachtsfeiertage beschäftigen werde.

zumal mir PDO überhaupt ein bischen zukunftsträchtiger scheint als aldi anderen Datenbanktreiber, die PHP so mitbringt.

Da bin ich gespannt, was unsere Experten wie zB. dedlfix, ChrisB und andere dazu sagen. Ich hoffe, die geben ein Statement ab.

PDO ist, ähnlich wie Perl DBI, in Schichten aufgebaut, d.h., es wird demnächst auch Layer für andere, von MySQL abweichende DB Engines geben (Oracle gibts wohl schon nach meinem letzten Wissensstand).

Mir persönlich reicht MySQL.

MfG

Hugo Egon Balder

PS: Ich würde natürlich trotzdem immer noch gerne eine Erklärung für meine mysqli Wissenslücke haben!

[dedlfix]

Tach!

Beim Arbeiten mit mysqli habe ich festgestellt, dass manche Dinge nicht so funktionieren, wie sie im Handbuch beschrieben sind. Mit PDO hingegen habe ich da bessere Erfahrungen gemacht und ich denke, das kann ich auch Dir empfehlen

Da er keine konkreten Beispiele bringt, gehe ich mal davon aus, dass vermutlich nur hottis Verständnis nicht so funktioniert wie die im Handbuch beschriebene Funktionalität.

zumal mir PDO überhaupt ein bischen zukunftsträchtiger scheint als aldi anderen Datenbanktreiber, die PHP so mitbringt.

Ohne die anderen Datenbanktreiber kann PDO gar nichts, denn es setzt auf ihnen auf. Man kann PDO zugute halten, das es versucht, die Zugriffe zu vereinheitlichen. Das geht bis für eine gewisse Grundfunktionalität auch sehr gut. Will man aber mehr als 08/15-Datenbankzugriff und die individuellen Eigenheiten der jeweiligen DBMSe verwenden, kommt man mit dem "Gleichmacher" PDO nicht sehr weit. Einige Dinge, wie auto_increment vs. Sequenzen, können einfach nicht vereinheitlicht werden, weil die Konzepte der DBMSe zu unterschiedlich sind. Ich denke nicht, dass PDO in Zukunft die nativen Extensions ablösen wird.

Da bin ich gespannt, was unsere Experten wie zB. dedlfix, ChrisB und andere dazu sagen. Ich hoffe, die geben ein Statement ab.

Es ist immer sehr anstrengend, hottis Postings auseinanderzunehmen, oftmals erstmal sortieren zu müssen, was er überhaupt gemeint und was er mal wieder durcheinandergeworfen hat, um dann eine Richtigstellung zu verfassen. Erwarte bitte nicht, dass ich dazu jedes Mal die Energie aufbringe.

PDO ist, ähnlich wie Perl DBI, in Schichten aufgebaut, d.h., es wird demnächst auch Layer für andere, von MySQL abweichende DB Engines geben (Oracle gibts wohl schon nach meinem letzten Wissensstand).

Seit Anbeginn der Tage PDOs kam es mit mehr als nur MySQL-Unterstützung daher. Die aktuelle Liste umfasst Treiber für 12 Datenbanksysteme.

dedlfix.

[Hugo Egon Balder]

Hi dedlfix,

Ohne die anderen Datenbanktreiber kann PDO gar nichts, denn es setzt auf ihnen auf. Man kann PDO zugute halten, das es versucht, die Zugriffe zu vereinheitlichen. Das geht bis für eine gewisse Grundfunktionalität auch sehr gut. Will man aber mehr als 08/15-Datenbankzugriff und die individuellen Eigenheiten der jeweiligen DBMSe verwenden, kommt man mit dem "Gleichmacher" PDO nicht sehr weit.

diese Antwort hat mich jetzt überrascht, da die Seiten, die ich bisher zu diesem Thema besucht habe, bei der Entscheidung zwischen mysqli und PDO eindeutig Richtung BDO blicken. Sehr interessant zB. die Artikel "PDO vs. MySQLi: Which Should You Use?" oder auch "MySQLi vs. PDO Benchmarks". Und beim Lesen fand ich dauernd nur Kommentare von begeisterten Anwendern und niemanden, der geschrieben hat, dass er sich nach dem Vergleich von mysqli und PDO für Ersteres entscheidet. Ich habe deshalb jetzt mit einem positiveren Kommentar gerechnet. Ich selbst habe natürlich keine Meinung dazu, nachdem ich gestern um diese Zeit von PDO noch nicht mal was gewusst habe.

Einige Dinge, wie auto_increment vs. Sequenzen, können einfach nicht vereinheitlicht werden, weil die Konzepte der DBMSe zu unterschiedlich sind. Ich denke nicht, dass PDO in Zukunft die nativen Extensions ablösen wird.

Da weiß ich nicht genau, was Du konkret meinst und ob mich das bei den Dingen, die ich bisher mit mysqli gemacht habe, betrifft.

Die Zeitzonen-Festlegung bei der Verbindung mit PDO geschieht mit einem $DBH->exec("SET time_zone = '-8:00'"); ... was ich leider nirgends finde ist das Korrelat zu $db->set_charset('utf8'); nach dem Verbindungsaufbau mit mysqli. Weiß jemand, wie ich mit PDO der MySQL DB mitteilen kann, dass das Datenhandling utf-8-kodiert geschieht?

MfG

Hugo Egon Balder

[dedlfix]

Tach!

[PDO ist nicht das Non-plus-Ultra]
diese Antwort hat mich jetzt überrascht, da die Seiten, die ich bisher zu diesem Thema besucht habe, bei der Entscheidung zwischen mysqli und PDO eindeutig Richtung BDO blicken. Sehr interessant zB. die Artikel "PDO vs. MySQLi: Which Should You Use?"

In dem Artikel sehe ich überhaupt nicht PDO als ganz klaren Sieger. Der dort dargestellte einzige Trumpf von PDO ist seine Unterstützung von 12 Treibern. - Ja und? Brauchst du so viele? Wirst du jemals ein anderes DBMS verwenden? Und wenn doch, wie hoch sind die Kosten des Umstiegs? Zunächst sind sie deutlich höher als es auf den ersten Blick scheint, denn mit dem Austauschen des Connection-String allein ist es meistens nicht getan. Da müssen mindestens noch die Eigenheiten der SQL-Dialakte beachtet werden.

oder auch "MySQLi vs. PDO Benchmarks".

Schau dir mal die Unterschiede an. Sie sind so gering, dass sie in der Praxis keine Rolle spielen. Performance ist hier kaum als Entscheidungskriterium brauchbar.

Und beim Lesen fand ich dauernd nur Kommentare von begeisterten Anwendern und niemanden, der geschrieben hat, dass er sich nach dem Vergleich von mysqli und PDO für Ersteres entscheidet. Ich habe deshalb jetzt mit einem positiveren Kommentar gerechnet. Ich selbst habe natürlich keine Meinung dazu, nachdem ich gestern um diese Zeit von PDO noch nicht mal was gewusst habe.

Ich sehe als Hauptpunkt für eine Entscheidung zwischen beiden Systemen die Handhabbarkeit und die persönliche Einschätzung, welche von beiden einem besser gefällt.

Einige Dinge, wie auto_increment vs. Sequenzen, können einfach nicht vereinheitlicht werden, weil die Konzepte der DBMSe zu unterschiedlich sind.
Da weiß ich nicht genau, was Du konkret meinst und ob mich das bei den Dingen, die ich bisher mit mysqli gemacht habe, betrifft.

Du kennst aus MySQL das auto_increment-Attribut für das Primärindex-Feld, das beim Einfügen von Datensätzen selbständig einen hochgezählten Wert einfügt, den du nachher abfragen kannst. Dieses Feature ist anderen DBMSen nicht bekannt. Einige verfügen stattdessen über ein deutlich flexibleres Feature namens Sequenzen. Das ist eine separate Zählung, die auch in anderen Schritten als +1 definiert werden kann. Andererseits muss sie zu Fuß abgefragt und den Wert dem jeweiligen Feld zugewiesen werden. Dafür kann man sie oder mehrere davon in allen möglichen Feldern und auch ganz anderen Situationen verwenden, nicht nur beim Primärindex. Nichtsdestotrotz ist auto_increment oftmals völlig ausreichend und so schön einfach zu handhaben - einmal Attribut setzen und dann nur noch abfragen.

PDO versucht hier etwas zu vereinheitlichen, indem es die Sequenzabfrage in der FUnktion lastInsertId() versteckt, was nicht ganz gelingt, weil man den Namen der Sequenz angeben muss.

Die Zeitzonen-Festlegung bei der Verbindung mit PDO geschieht mit einem $DBH->exec("SET time_zone = '-8:00'"); ... was ich leider nirgends finde ist das Korrelat zu $db->set_charset('utf8'); nach dem Verbindungsaufbau mit mysqli.

Das sind halt individuelle Dinge, die man nicht oder nur schwer vereinheitlichen kann. Andere Funktionalität kann man nachbilden. Du kennst ja von MySQL auch Timestamp-Felder, die sich selbständig updaten. Das kann man zumindest mit Triggern in anderen Systemen nachbauen. Solche Kriterien sind aber bei der Wahl des DBMS ausschlaggebend, und weniger interessant für die Einscheidung welche API man für ein einziges DBMS verwenden möchte. Hier musst du in erster Linie schauen, wie die exotischen Features (bei denen man sich gleich gar nicht mehr erinnert, wo man überall welche eingesetzt hat) unterstützt werden.

Weiß jemand, wie ich mit PDO der MySQL DB mitteilen kann, dass das Datenhandling utf-8-kodiert geschieht?

Ja, im DSN, aber erst seit PHP 5.3.6. Die DSN-Beschreibung findest du im PHP-Handbuch (meist ganz unten verlinkt) im Kapitel zum jeweiligen PDO-Datenbanktreiber.

dedlfix.

[hotti]

hi,

Ohne die anderen Datenbanktreiber kann PDO gar nichts, denn es setzt auf ihnen auf. Man kann PDO zugute halten, das es versucht, die Zugriffe zu vereinheitlichen. Das geht bis für eine gewisse Grundfunktionalität auch sehr gut. Will man aber mehr als 08/15-Datenbankzugriff und die individuellen Eigenheiten der jeweiligen DBMSe verwenden, kommt man mit dem "Gleichmacher" PDO nicht sehr weit. Einige Dinge, wie auto_increment vs. Sequenzen, können einfach nicht vereinheitlicht werden, weil die Konzepte der DBMSe zu unterschiedlich sind. Ich denke nicht, dass PDO in Zukunft die nativen Extensions ablösen wird.

Vermutlich kennst Du Perl DBI überhaupt nicht, das ist schon seit Jahren ein Teiber, der in Schichten aufgebaut ist, siehe Link.

Selbstverständlich liegen Engine Specials (auto_increment, last_insert_id...) in dem der Engine entsprechenden Layer und nicht etwa in der Common Class. So wirst Du eine Methode zu LAST_INSERT_ID auch nur im DBI Layer DBD::mysql finden.

Verstehe die Layer, btw., das 'I' in DBI steht für independent interface.

Schönen Sonntag!

[dedlfix]

Tach!

Vermutlich kennst Du Perl DBI überhaupt nicht, das ist schon seit Jahren ein Teiber, der in Schichten aufgebaut ist, siehe Link.

Nun, dafür kennst du PHP/PDO schlecht. Meine Perl-Kenntnisse tun hier aber nichts zur Sache, das Thema ist PHP.

Selbstverständlich liegen Engine Specials (auto_increment, last_insert_id...) in dem der Engine entsprechenden Layer und nicht etwa in der Common Class. So wirst Du eine Methode zu LAST_INSERT_ID auch nur im DBI Layer DBD::mysql finden.

Und was hat das jetzt mit PDO zu tun? Dort gibt es keine individuellen Klassen (o.ä) für die einzelnen Datenbanksysteme. Es gibt lediglich einige treiberspezifische Konstanten, die an manchen Stellen übergeben werden können. lastInsertId() ist zum Beispiel direktamente eine Methode der PDO-Klasse.

Verstehe die Layer, btw., das 'I' in DBI steht für independent interface.

Für die PDO-Betrachtung sind die DBI-Layer und Äpfel-und-Birnen-Vergleiche nicht weiter relevant.

PDO versucht sich am 'I', aber die abhängigen Funktionalitäten sind teilweise einfach eingearbeitet und müssen individuell berücksichtigt werden.

dedlfix.

[dedlfix]

Tach!

Mit php/mysqli möchte ich alle Datensätze ausgeben, in denen "Hans" der Name ist. Hier der Weg ohne prepared Statements:

$sql="SELECT id,name, stadt FROM foo WHERE name='Hans'";

$result=$db->query($sql);
while($line=$result->fetch_object())
  {
    echo"<p>".$line->id." - ".$line->name." - ".$line->stadt."</p>\n";
  }

  
Dem fehlt noch die kontextgerechte Behandlung für HTML, also htmlspecialchars() um die auszugebenden Variablen.  
  

> Das funktioniert einwandfrei. So, nun möchte ich die Ausgabe mit einem prepared Statement machen. Meine erste Überlegung war, hier einfach einen prepared Statement-Teil einzufügen. Das sah dann so aus:  
> ~~~php

$eingabe_name="Hans";  

> $sql="SELECT `id`,`name`, `stadt` FROM `foo` WHERE `name`=?";  
> $result=$db->prepare($sql);  
> $result->bind_param('s',$eingabe_name);  
> $result->execute();  
> while($line=$result->fetch_object())  
>   {  
>     echo"<p>".$line->id." - ".$line->name." - ".$line->stadt."</p>\n";  
>   }

Das endet in der Fehlermeldung "Fatal error: Call to undefined method mysqli_stmt::fetch_object() in ..." -betreffend die Zeile mit der while-Schleife. Da verstehe ich schon mal nicht, wieso es hier ein Problem gibt. Das prepared Statement betraf doch den Abfrage-Weg _zur_ DB. Das Ergebnis, also die Ausgabe der DB, sind doch einfach, wie im ersten Fall, die betreffenden Datensätze.

Die Klasse mysqli_stmt hat keine Methoden zum direkten Fetchen. Der vorgesehene Weg beim Verwenden von P.S. ist, die Felder im Resultset an Variablen zu binden. Dann läuft man mit der Methode fetch() durch die Ergebnismenge und hat jeweils die Werte eines Datensatzes in diesen Variablen stehen.

OK, nach dem Besuch von sicher mehr als 50 Seiten zu dem Thema und 10 Stunden vor dem PC, habe ich vor kurzem das erste Mal eine funktioiernede Lösung ohne Fehlermeldung zustandegebracht. Und ich habe keine Ahnung, wieso:

$eingabe_name="Hans";

$sql="SELECT id,name, stadt FROM foo WHERE name=?";
$result=$db->prepare($sql);
$result->bind_param('s',$eingabe_name);
$result->execute();
$result->bind_result($id,$name,$stadt);
while($result->fetch())
  {
    echo"<p>".$id." - ".$name." - ".$stadt."</p>\n";
  }

  
Nun, vielleicht hast du einfach aus dem Handbuch das passende Beispiel nachgebaut.  
  

> Ich verstehe es einfach nicht. Wieso muss ich, nur weil die Übergabe des Suchparameters mit einem prepared Statement geschehen ist, plötzlich die betreffenden Datensätze mit "`bind_result`{:.language-php}" behandeln und in Variablen überführen?  
  
Da musst du die Entwickler der MySQL-Client-API fragen, warum sie da einen anderen Weg gehen als bei herkömmlichen Abfragen. PHP ist hier nur geringfügig schuldig, weil es einfach diesen Weg nur mit PHP-Mitteln nachgebaut hat. Die PDO-Extension geht jedenfalls auch bei P.S. den herkömmlichen Fetch-Weg und bietet den Bind-Fetch-Weg optional an.  
  

> Wieso funktioniert im ersten Fall eine Schleife mit "`$line=$result->fetch_object(`{:.language-php})" - während im prepared Statement Fall plötzlich nur eine Schleife mit "`$result->fetch()`{:.language-php}" funktioniert? Wieso plötzlich nicht mehr die Syntax "`$line->id`{:.language-php}"?  
  
Weil es so entworfen wurde.  
  

> Wie gesagt, ich verstehe nicht, wieso sich beim Code für die Ausgabe der betreffenden Datensätze plötzlich so viel ändert, nur weil die Suchbedingung nicht direkt im Query, sondern als prepared Statement eingefügt worden ist.  
  
Muss man nicht verstehen, man muss aber diesen Weg gehen, wenn man P.S. mit mysqli haben will.  
  

> Ich bitte darum, dass mir jemand in verständlichen Worten, also nicht in Techniksprech, die Unterschiede zwischen den beiden Situationen erklärt und wieso das nicht so funktioniert, wie ich es laut 2. Beispiel ursprünglich gedacht hatte.  
  
Du hast ja nun schon herausgefunden, wie es geht. Mehr kann ich dir daran auch nicht erklären. Ich finde es auch nicht besonders glücklich gelöst. Die ganze Sache arbeitet nämlich mit Referenzen.  
  
Referenzen kurz erklärt: Eine Variable besteht aus zwei Teilen - einem Container, der den Wert enthält, und ihrem Namen, der auf den Container zeigt. Bei $a = $b wird der Wert von $b nach $a kopiert - genauer: der Wert aus dem Container von $b wird in den Container von $a kopiert (noch genauer: PHP-intern passiert das etwas anders, aber das führt jetzt zu weit, für den Anwender sieht das jedenfalls wie eine Kopie aus). Ändert sich danach $a oder $b, betrifft das den jeweils anderen Container-/Variableninhalt nicht. Bei $a =& $b (man beachte das & )wird $a eine Referenz auf $b, was heißt, dass nun $a (ebenfalls) auf den Container von $b zeigt und damit beide auf denselben Variableninhalt. Man kann nun über $a und $b auf diesen einen Wert (Container) lesend oder schreibend zugreifen.  
  
Beim Param-Bind wird jeweils vom Platzhalter eine Referenz zu einer bestimmten Variable (das heißt auf ihren Container) erstellt. Erst beim Execute wird deren (dessen) Inhalt ausgelesen. Wenn zum Beispiel bei einem Insert mehrere Datensätze eingefügt werden sollen, braucht man zwar nur ein Prepare und einmal Param-Binds, kann dann aber das Execute mehrfach aufrufen. Zwischen den Aufrufen muss man nur den Inhalt der Variablen (also ihres Container, angesprochen über den uns bekannten Variablennamen) ändern.  
  
Beim Fetch-Vorgang wird ebenfalls eine Referenz auf die beim Result-Bind angegebenen Variablen erstellt. Ein Fetch schreibt über die in PHP intern gemerkten Referenen in die Container und du liest die Werte über die dir bekannten Variablennamen aus.  
  
Das ganze funktioniert, wenn man einmal weiß, wie es geht, recht unkompliziert, wenn man den Wert gleich beim Fetchen ausgibt und ihn dann nicht mehr braucht. Will man die Werte aber zur späteren Verwendung in einem Array of Arrays speichern, muss man jede Variable einzeln anfassen und umkopieren. Noch bescheidener wird es, wenn man eine generische Datenbankabstraktionsfunktion schreiben will, die mit einer unterschiedlichen Anzahl von Parametern als auch Ergebnismengenfeldern umgehen soll. Dann kann man schlecht einzelne Variablen verwenden und fängt an, sich mit Referenzen auf Array-Felder rumzuschlagen.  
  
So, mal wieder drei Fragen geklärt ... und zehn neue aufgeworfen ;)  
  
  
dedlfix.

[Hugo Egon Balder]

Hi Dedlfix!

Vielen Dank für die ausführliche Antwort!

Dem fehlt noch die kontextgerechte Behandlung für HTML, also htmlspecialchars() um die auszugebenden Variablen.

Na also _so weit_ bin ich schon, dass ich solche Dinge beachte! Ich habe hier einfach nur den für mein Problem relevanten Code hingeschrieben, um die Sache schlank zu lassen. Die Beachtung des Kontextwechsels lasse ich _natürlich nicht_ unter den Tisch fallen.

Die Klasse mysqli_stmt hat keine Methoden zum direkten Fetchen.

Was mir so unklar an der Sache ist, ist die Tatsache, dass es sowohl (im funktionierenden) Beispiel 1 ohne PS als auch im (falschen) Beispiel 2 um den Weg der Daten von der DB zur Ausgabe handelt. Die PS betreffen ja den Weg _zur_ DB, damit die weiß, was sie suchen soll. Da würde ich verstehen, wenn es Probleme gibt. Aber wenn die DB mal etwas gefunden hat und es jetzt darum geht, diese gefundenen Stücke "herzugeben", darf ich das beim Arbeiten mit PS plötzlich nicht mehr so machen wie ohne? Das ist _völlig_ unlogisch (für mich)!

Nun, vielleicht hast du einfach aus dem Handbuch das passende Beispiel nachgebaut.

Nein, da war ich heute zwar auch schon 20 Mal, aber das war ein Zufall. Ich möchte halt einfach immer alles _verstehen_ und nicht stur irgendetwas abschreiben, was zwar funktioniert, ich aber keine Ahnung habe, warum.

So, mal wieder drei Fragen geklärt ... und zehn neue aufgeworfen ;)

Nein nein, überhaupt nicht! Ganz im Gegenteil! Das war durch die symbolhafte Didaktik sehr verständlich und informativ/sympathisch zulesen! Danke dafür!

MfG

Hugo Egon Balder

[dedlfix]

Tach!

Was mir so unklar an der Sache ist, ist die Tatsache, dass es sowohl (im funktionierenden) Beispiel 1 ohne PS als auch im (falschen) Beispiel 2 um den Weg der Daten von der DB zur Ausgabe handelt. Die PS betreffen ja den Weg _zur_ DB, damit die weiß, was sie suchen soll. Da würde ich verstehen, wenn es Probleme gibt. Aber wenn die DB mal etwas gefunden hat und es jetzt darum geht, diese gefundenen Stücke "herzugeben", darf ich das beim Arbeiten mit PS plötzlich nicht mehr so machen wie ohne? Das ist _völlig_ unlogisch (für mich)!

Tja, so ist es nun mal. Im Beispiel 1 arbeitest du mit der Klasse mysqli und bekommst als Ergebnis der Methode query() ein Objekt der Klasse mysqli_result. Warum auch immer, aber der P.S.-Teil arbeitet eben schon seitens MySQL-API anders. Du beginnst zwar mit der Klasse mysqli für die Verbindung, machst aber ab propare mit der Klasse mysqli_stmt weiter. Und das eben auch beim Fetchen.

Nun, vielleicht hast du einfach aus dem Handbuch das passende Beispiel nachgebaut.
Nein, da war ich heute zwar auch schon 20 Mal, aber das war ein Zufall. Ich möchte halt einfach immer alles _verstehen_ und nicht stur irgendetwas abschreiben, was zwar funktioniert, ich aber keine Ahnung habe, warum.

Es ist nicht verkehrt, ein Beispiel abzukopieren, es erst einmal erfolgreich laufen zu sehen, und sich dann erst damit weitergehend zu beschäftigen, es zu analysieren, es umzubauen, zu schauen, was geht und was nicht.

dedlfix.