sql-Syntax nicht valide, warum

Jop, sieht gar nicht schlecht aus. Ich tipp echt auf den Umlaut da, das der irgendwie Probleme macht... kannst du da nicht mal auf was andres als auf "Büro" filtern? Nur mal zum testen...

PS: Wir sind doch erst bei 21 Antworten. Das ist doch noch harmlos

 

Wenn deine DB auf UTF-8 läuft und du die Datei mit diesem Text 'Büro' direkt gefüttert hast, hast du sie auch als UTF-8 ohne BOM Marker im TextEditor gespeichert ? Wenn nicht, ist es eine ANSI Datei mit korruptem Zeichen in einer Anfrage für UTF-8.

 

Was mir auch grade noch auffällt: Bisher hieß der Wert immer "büro", jetzt auf einmal "Büro". MySQL ist unter Umständen Case-sensitive.

 

Naja, die Query an sich ist ja okay, nur liefert "Büro" halt kein Ergebnis. "Obergeschoss" liefert auch "null" zurück? In PHPMyAdmin liefern die Queries Ergebnisse?

So, bin erstmal weg für heute...

 

Hier die Wikipedia Beschreibung für BOM: Byte Order Mark – Wikipedia
Nicht alle Texteditoren (Standalone) können UTF-8 Text Dateien schreiben ohne eine Byte Order Mark vor dranzusetzen. Da du aber mit dem Theme-Editor ? arbeitest, sollte der eigentlich korrektes UTF-8 schreiben, sicher bin ich nicht, denn wenn die Ursprungsdatei ANSI war schreibt der auch wieder ANSI raus.

Ich mach erstmal Feierabend, komme später darauf nochmal zurück.

 

Kannst du mal irgendwas "einfaches" ausprobieren?
"SHOW TABLES" oder sowas?

Vielleicht auch mal direkt als 1. Parameter von get_results(), statt vorheriger query()?

codestyling: Kannst du mich mal bitte aufklären, was du hier mit dem BOM möchtest? Das BOM sollte doch mit der Query selbst eigentlich nix am Hut haben (abgesehen von den UTF-8-codierten Sonderzeichen im Querystring natürlich...)?

 

Verwende mal '*' statt dessen, oder meine "SHOW TABLES"-Query von weiter oben. Mal irgendwas wo wir sicher sein können, dass keine Umlaute irgendwo stören könnten.

Du meinst, direkt im Beitragseditor? Mit einem PHP-Plugin? Vielleicht macht auch der Editor Müll aus deiner Query... verwende doch statt dessen mal lieber ein Seitentemplate oder so, und gib den Code direkt mit einem Texteditor ein.

 

Der BOM Hinweise war nur zusätzlich, primär wichtig ist nur, das die Seite (Template) UTF-8 gespeichert ist.
Hier noch ein paar Randinformationen. Wenn die betreffende DB nicht komplett auf UTF-8 läuft, wird es mit dem wpdb Objekt Probleme geben, denn:

Code:

Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!

Spätestens das SET NAMES wird UTF-8 verlangen, somit muß der Query String selbst UTF-8 sein. MySQL :: MySQL 5.1 Referenzhandbuch :: 10.4 Verbindungszeichensatz und -sortierfolge

Und zum Thema Beitragseditor: Mich würde interessieren, wie ein dort eingeklebtes Script ausgeführt wird. Wenn das mit exec_php gemacht wird, das WP Objekt zwar benutzt aber die wp-config.php nicht, dann sind DB_CHARSET und DB_COLLATE nicht definiert und die DB sucht sich raus, was sie verstehen will.

 

diltigug: Das 2., aber mit Anführungszeichen:

Code:

Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!

(mmh, das 1. sollte doch auch funktionieren... vielleicht passt da intern was nicht oder ich interpretiere die Doku zu get_results() falsch... :???

Ja okay, deswegten fragte ich ja. Aber anscheinend nimmt er ja kein Template.

Ja, das hab ich auch schon gefunden. Daher ja meine Testqueries komplett ohne irgendwelche Umlaute oder Non-ASCII-Sonderzeichen. Die müssen ja was liefern, egal wie's in der DB aussieht. Oder siehst du das anders?

Das könnte man ja eventuell sogar zum Vorteil nutzen, um die Konstanten mit anderen Werten nochmal neu zu initialisieren. Falls es wirklich an den Umlauten liegt...

 

Primär sollte erstmal geklärt werden, wie das PHP Script, das im Beitragseditor eingeklebt wurde, ausgeführt wird. Da einige Fehlermeldungen von eval'd code schreiben, sieht das für mich so aus, als würde irgend ein Plugin das eingeklebte Script rausfischen und per eval() ausführen. Da kann es zu den merkwürdigsten Nebenwirkungen (angefangen von Scope Problemen bis zu nicht global zugegriffenen Objekten) kommen.
Es wäre gut, den gesamten Scriptblock mal zu sehen, der in den Editor eingefügt wird und die Angabe dazu, wer und wie das ausgeführt wird.

 

Mmh.... sollte ich die Doku doch tatsächlich missinterpretiert haben? aber es steht doch eindeutig so da:

Sehr merkwürdig das ganze...

Was is denn das nu wieder? :shock: Was steht in Zeile 30 des eval'd Code? Also wahrscheinlich die 30. Zeile des Codes im Editorfenster. Sollte es doch mit Exec-PHP zusammenhängen, dass es anders nicht funktioniert?

 

Mal diese Abschnitte durchgehen der exec_php Beschreibung:
http://bluesome.net/post/2005/08/18/50/#troubleshooting
http://bluesome.net/post/2005/08/18/50/#faq
Hier sind einige Problemfälle gelistet, wie es scheint, könnte der eine oder andere zutreffen.

Warum wird eigentlich für den Beitrag/Seite keine eigenes Template gebaut, das im PHP code die POST Bearbeitung der per Editor eingeklebten <Form> macht ? Wäre doch um einiges leichter und braucht kein Plugin.