Problem mit Hochkomma <-> Anführungszeichen bei der String-Maskierung

Chnutz

Chnutz

Benutzer
Beiträge
6
Zunächst einmal Danke für die Aufnahme im Forum!

Nun die Frage:
Ich habe ein umfangreiches php-MySQL-Datenbank-Frontend geschrieben. In den MySQL-Abfragen habe ich die String-Werte alle in Anführungszeichen, Beispiel:
INSERT INTO tabelle SET Beispielvariable = "Beispielwert"​

Nun habe ich auf einen Localhost MySQL & php installiert, die Dateien übertragen und festgestellt, dass so gut wie keine Abfrage mehr funktioniert, weil lokal plötzlich nur Hochkommata zur Maskierung akzeptiert werden:
INSERT INTO tabelle SET Beispielvariable = 'Beispielwert'
​
Nach längerer, vergeblicher Startpage- und Manual-Suche möchte ich nun Euch fragen, ob bekannt ist, wo da ein Haken gesetzt oder herausgenommen werden muss, damit ich nicht alle Abfragen umschreiben muss?!

Die neue DB ist MySQL 5.7.

Herzlichen Dank schonmal!
 
Werbung:
Du hast Dich an das zu halten, was die Syntax vorschreibt. Mit " benennt man z.B. Spalten, mit ' Werte. Dein Insert Into ... Set ... erscheint mir auch falsch, das nur nebenbei.
 
So werden aus einer Frage zwei ;-)
Kann es sein, dass Du eben in PostGreSQL unterwegs bist? Spalten benenne ich in MySQL doch eigentlich mit ` , oder verstehe ich Dich jetzt falsch?!

Was erscheint Dir an der INSERT INTO ... SET ...-Syntax falsch? Hier ist sie doch an zweiter Stelle beschrieben:
MySQL :: MySQL 5.7 Reference Manual :: 13.2.5 INSERT Syntax

Geht übrigens auch - nur eben an allen anderen Servern außer dem neuen^^
 
Jede SQL Variante hat so ihre eigene Deutung von ' ` und ". Du solltest dich an den gängigen Standard halten, auch wenn es sich vieleicht verstellen läßt. Ich kenne keine SQL Variante die Zeichenketten als Wert nicht mit ' akzeptiert, also würde ich das als gängig bezeichnen.

Genauso ist
INSERT INTO tbl_name (a,b,c) VALUES(1,2,3)
üblich und geht in allen SQL Varianten. Das mit SET habe ich auch noch nie gesehen, auch wenn es MySQL gem. Doku kann.
 
Wie ich oben schrieb, ist es eine existierende und (bis auf diesen einen Rechner) funktionierende, umfangreiche Anwendung. Das bedeutet gut 50 Dateien voller SQL-Anweisungen.
Ihr werdet verstehen, dass ich deshalb bevorzuge, die eine, oben genannte und für das Problem verantwortliche Einstellung zu ändern und nicht die 50 Dateien Code zu durchforsten und einzeln zu ändern, auch wenn der Code dann mal nicht so schön aussieht ;)

Deshalb nochmal die Frage, ob evtl. jemand weiß, wie ich ANSI_QUOTES aus dem Mode herausbekomme?!

Ich habe dazu Folgendes gefunden:

SET sql_mode=(SELECT REPLACE(@@sql_mode,'<mode_to_remove>',''));

Umgesetzt also:
SET sql_mode=(SELECT REPLACE(@@sql_mode,',ANSI_QUOTES',''));

Es sagt mir dann aber ohne Fehlermeldung "0 rows affected"

Quelle des Vorschlags ist:
John's Observation Loft: Adding or removing individual SQL modes in MySQL's sql_mode variable


Abgesehen von dem Hochkomma-Problem bin ich aber neugierig:
Gibt es eine Begründung außer der Schönheitsfrage, warum lieber VALUES als SET genommen werden sollte, z.B. Performanz?
 
Performance denke ich nicht. Schönheit würde ich auch nicht sagen aber du könntest z.B. Teile deines SQL Codes direkt auch auf anderen Systemen ausführen und Aussenstehende erkennen schneller was der Code macht.

Im Prinzip kannst du ja auch Schwäbisch sprechen und die miesten Deutschen werden es vermutlich verstehen. Aber leichter wird es dadurch ja nicht.
 
Schnelle Lösung: Vorher entscheiden, welchen sql_mode man nutzen möchte bzw. Einstellung über
SELECT @@sql_mode
anzeigen lassen und die Einstellungen kopieren, die beibehalten werden sollen.
Dann mit

SET sql_mode 'hier Modes kommagetrennt einsetzen'

den jeweiligen Mode setzen, in meinem Fall ohne ANSI_QUOTES.

Schon geht die komplette Anwendung.

Ich frage mich nur, wodurch die eigentlich bei Installation übliche Voreinstellung des Modes geändert wurde.
 
Werbung:
Zurück
Oben