Tom: MYSQL ERROR weiß nicht wo der Fehler liegt

Beitrag lesen

Hello,

('lektion','deu','$kuerzel_sprache') VALUES ('$lektion','$deu','$fremd')");

Variablen zwischen einfachen Hochkommata werden nicht interpretiert...

*g* welche meinst Du denn?
Und welchen Interpreter meinst Du?
Den MySQL-SQL-Interpreter oder den PHP-Interpreter?

ich denke, nachdem er den variablen ein $-Zeichen voranstellt, werden es wohl PHP-Variablen sein, oder vielleicht wollte er ja wirklich den String $lektion in die Table schreiben...

Entschuldige bitte. Dann hast Du meine Frage nicht verstanden. Ich werde versuchen, den Knoten aufzulösen.

MySQL erwartet einen Befehlsstring für seine SQL-Textschnittstelle. Dieser kann Bezeichner enthalten, die aber nicht durch ein vorangestelltes Dollar-Zeichen, sondern durch ihre Position im Befehlsstring und ihre "Nicht-Sonderbedeutung" oder ihre Spezialmarkierung (Backticks) identifiziert werden. Einfache Anführungszeichen (Apostoph) kennzeichnet hingegen Textliterale, die als Werte übergeben werden.

PHP erkennt seine Bezeichner an einem (oder auch zwei) vorangestellten Dollarzeichen,
in einem String, der mit Doppelquote eröffnet wurde dann, wenn sie _nicht_ durch ein Escapezeichen (normalerweise der Backslash) maskiert sind.

Als erstes wertet PHP den zusammengebastelten SQL-String aus, da er hier in Doppelhäkchen eingeschlossen ist. Dabei ist unerheblich, dass einzelne Teile nochmals in Einzelhäkchen eingeschlossen sind. Die Quotierung, die den String eröffnet, steuert das Verhalten.

Also werden erst die PHP-Variablen $lektion, $deu und $fremd durch PHP gegen Werte ersetzt.
Wenn alle Ersetzugnen stattgfunden haben [1], wird dieser String an die Textschnittstelle von MySQL, also den SQL-Parser, übergeben. Dieser versucht nun den String seinerseits zu analysieren und ggf. Ersetzungen durchzuführen.

Die Spaltenbezeichner lektion, deu uns kuerzel_sprache können aber nicht erkannt werden, wenn sie als Werte für einen literalen Spaltentyp verpackt werden, also in Einfachhäkchen eingeschlossen werden. An dieser Stelle erwartet der SQL-Parser einfach noch nkeine Werte.

[1] Diesen String sollte man sich in seinem Programmablauf immer aufheben für die Ausgabe, wenn ein Debugging notwendig ist.

Liebe Grüße aus Syburg bei Dortmund

Tom vom Berg

--
Nur selber lernen macht schlau
http://bergpost.annerschbarrich.de