Dynamische where-Bedingung

[Rosalie Th.]

Hallo

Ich bin auf der Suche nach einer Lösung für eine dynamische Where-Bedingung.

Je nachdem kann die Where-Bedingung (Inhalt der Variable $bedingung) lauten:
WHERE elefant='blau'
WHERE baum='gross'
WHERE telefon='laestig'

Nun möchte ich die Abfrage je nach Variablen-Inhalt ($bedingung) machen. Das funtioniert leider noch nicht.

$strQuery  = "SELECT *from tabelle TEST $bedingung";
$dbRS = MySQLQuery($strQuery);
$arrRS = mysql_fetch_array($dbRS);

Muss ich das mit "@" lösen? Ich blicke da nicht durch. Ich bin für jeden Hinweis sehr dankbar!

Danke
Rosa

[suit]

Nun möchte ich die Abfrage je nach Variablen-Inhalt ($bedingung) machen. Das funtioniert leider noch nicht.

Funktioniert nicht funktioniert nicht.

Muss ich das mit "@" lösen? Ich blicke da nicht durch. Ich bin für jeden Hinweis sehr dankbar!

@ ist - wie ich in einem Fall vermute: PHP - keine Lösung sondern ein Symtomunterdrücker der meistens nicht ausgewertet wird.

Beschreibe bitte dein Problem:

Hast du ein Datenbank-Problem? Wenn ja, mit welchem DMBS? Oder hast du ein Problem mit Stringverkettung? Wenn ja, in welcher Sprache?

[Rosalie Th.]

Hast du ein Datenbank-Problem? Wenn ja, mit welchem DMBS? Oder hast du ein Problem mit Stringverkettung? Wenn ja, in welcher Sprache?

Die DB ist mySQL. Die Sprache PHP. Sorry, dass ich mich nicht klar ausgedrückt habe!

Mein Problem ist, dass die SQL-Anweisung nicht ausgeführt wird. Wenn ich die Bedingung WHERE elefant='' blau in der Abfrage stehen habe, kriege ich eine Antwort. kreire ich erst die Varible: $bedingung="WHERE elefant='blau'"; und füge diese in die SQL-Anweisung ein: select * from TEST $bedingung dann kriege ich keine Antwort.

[luti]

Hallo,

Mein Problem ist, dass die SQL-Anweisung nicht ausgeführt wird. Wenn ich die Bedingung WHERE elefant='' blau in der Abfrage stehen habe, kriege ich eine Antwort. kreire ich erst die Varible: $bedingung="WHERE elefant='blau'"; und füge diese in die SQL-Anweisung ein: select * from TEST $bedingung dann kriege ich keine Antwort.

Eins nach dem anderen ...

Gib mal bitte den Inhalt der Variable $strQuery aus, bevor Du sie weiterverarbeitest. (Und poste ihn dann.)

Gruß, luti

[Matti Maekitalo]

Tach auch.

Mein Problem ist, dass die SQL-Anweisung nicht ausgeführt wird. Wenn ich die Bedingung WHERE elefant='' blau in der Abfrage stehen habe, kriege ich eine Antwort. kreire ich erst die Varible: $bedingung="WHERE elefant='blau'"; und füge diese in die SQL-Anweisung ein: select * from TEST $bedingung dann kriege ich keine Antwort.

Es gibt keinen wesentlichen Unterschied (bis auf Kontextwechsel, den du dringenst beachten solltest), ob du eine konstante Query hast oder diese vorher per PHP zusammenpfriemelst.

Gibt also deine zusammengebaute Query mal direkt aus (per var_dump, echo, print_r, was weiß ich) und teste sie direkt in der DB. Du wirst durch das Zusammenbauen irgendwo einen Syntaxfehler machen.

Bis die Tage,
Matti

[suit]

Es gibt keinen wesentlichen Unterschied

Also für mich sind folgende Strings unterschiedlich wie Tag und Nacht.

WHERE elefant='' blau
WHERE elefant='blau'

(bis auf Kontextwechsel, den du dringenst beachten solltest),

Was gibt es in diesem Fall genau zu beachten?

Du wirst durch das Zusammenbauen irgendwo einen Syntaxfehler machen.

Das sind Ratespiele, aber der Schluß ist naheliegend.

[Matti Maekitalo]

Tach auch.

Es gibt keinen wesentlichen Unterschied

Also für mich sind folgende Strings unterschiedlich wie Tag und Nacht.

WHERE elefant='' blau
WHERE elefant='blau'

(bis auf Kontextwechsel, den du dringenst beachten solltest),

Was gibt es in diesem Fall genau zu beachten?

Ich habe das Beispiel nicht genau angeschaut, da ich durch den offensichtlichen Syntax-Fehler davon ausging, dass es sich nicht um den echten Code handelt, sondern schnell in das Formularfeld hier getippt wurde. Ich wollte darauf hinaus, dass es keinen Unterschied gibt zwischen

$where = "WHERE 1 = 1";  
$query = "SELECT * FROM bla $where";  
$dbh->query($query);

und
$dbh->query("SELECT * FROM bla WHERE 1 = 1");

Die beiden SQL-Schnippsel von oben sind unterschiedlich, da hast du recht, aber da bezog ich mich nicht drauf.

Zum Thema Kontextwechsel bitte hier entlang.

Bis die Tage,
Matti

[suit]

Zum Thema Kontextwechsel bitte hier entlang.

Schon klar - ich wollte aber wissen, wo das in DIESEM FALL zu beachten ist - ich sehe hier nichts, was gesondert behandelt werden müsste.

[Matti Maekitalo]

Tach auch.

Zum Thema Kontextwechsel bitte hier entlang.

Schon klar - ich wollte aber wissen, wo das in DIESEM FALL zu beachten ist - ich sehe hier nichts, was gesondert behandelt werden müsste.

Ich gehe davon aus, dass früher oder später Usereingaben direkt im SQL-String landen werden .. und da gebe ich den Kontextwechsel-Tipp lieber jetzt als später, wenn man sich schon Murks angewöhnt hat.

Bis die Tage,
Matti

[suit]

Ich gehe davon aus, dass früher oder später Usereingaben direkt im SQL-String landen werden .. und da gebe ich den Kontextwechsel-Tipp lieber jetzt als später, wenn man sich schon Murks angewöhnt hat.

Schon besser - diese Info solltest du aber nicht vorenthalten :)

Dort wo es nicht notwendig ist überall und an jeder Stelle einfach mal ein mysql_real_escape_string() herumknallen ist der Performance nicht sehr zuträglich.

[Tom]

Hello,

Ich gehe davon aus, dass früher oder später Usereingaben direkt im SQL-String landen werden .. und da gebe ich den Kontextwechsel-Tipp lieber jetzt als später, wenn man sich schon Murks angewöhnt hat.

Schon besser - diese Info solltest du aber nicht vorenthalten :)

Dort wo es nicht notwendig ist überall und an jeder Stelle einfach mal ein mysql_real_escape_string() herumknallen ist der Performance nicht sehr zuträglich.

Na, na. Das wird doch nur (maximal) einmal pro Spaltenwert beim Zusammenstellen des Querys gemacht. Die eigentlich teure Aufgabe, die Abfrage, bekommt dann doch statische Werte.

Wichtiger finde ich, dass man für eine universelle Escaping-Funktion die Arten von Spaltentypen unterscheiden sollte

Stringwerte       ->                    mysql_real_escape_string()
ganzzahlige numerische Werte     ->     intval()
  wenn in der Abfrage noch
  damit gerechnet werden soll
Logische Werte (TRUE, FALSE, NULL) ->   die Literale TRUE, FALSE, NULL in Natura einstanzen

Und was machen wir bei Dezimaltypen, Daten, usw?

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[suit]

Und was machen wir bei Dezimaltypen, Daten, usw?

Leider muss man sich für sämtliche Fälle - mit Ausnahme von Strings - ohnehin eigene Funktionen basteln - leider gibt's afaik kein mysql_sanitize(mixed $var, [, string $type ]) wo man dann bequem folgendes tun kann:

mysql_sanitize('127,119', 'DECIMAL')

[Tom]

Hello,

Und was machen wir bei Dezimaltypen, Daten, usw?

Leider muss man sich für sämtliche Fälle - mit Ausnahme von Strings - ohnehin eigene Funktionen basteln - leider gibt's afaik kein mysql_sanitize(mixed $var, [, string $type ]) wo man dann bequem folgendes tun kann:

mysql_sanitize('127,119', 'DECIMAL')

So ein mysql_autoescape() hatte ich schon mal angefangen. Dazu benötigt man dann in erster Linie die Tabellendefinition. Die kann man sich ja besorgen. Und dann kann man mit der Funktion oder Methode den vorbereiteten Datansatz zieltypgerecht escapen lassen.

Bei Fehler, also wenn sich ein Feldinhalt des externen Records nicht in den Spaltentyp der Tabelle portieren lässt, gibt es dieses Feld in einem Fehler-Record (Array) zurück.

Und dann sind wir bei der Last, die das erzeugt...

Und schon macht es keinen Spaß mehr. Wenn man bei jedem Request (eigentlich ja sogar bei jedem Query) erst die Tabellendefinition einlesen und auswerten würde, und das dann auch noch, wenn mehrere Tabellen betroffen sind, dann kostet das. Also müsste man diese Abfrage irgendwie cachen und nur feststellen, ob sie noch gültig ist. Es wäre zwar ungewöhnlich, dass Datenmodelle während des laufenden Betriebs geändert werden, aber nicht unmöglich...

Aber Du hast mich da auf eine Idee für die Basistests gebracht. Die Filterfunktionen geben ja einiges her http://de3.php.net/manual/de/book.filter.php. Das hatte ich noch mit Stringfunktionen und Regular Expressions gelöst.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[suit]

So ein mysql_autoescape() hatte ich schon mal angefangen. Dazu benötigt man dann in erster Linie die Tabellendefinition.

Naja, wenn man das automatisch machen möchte - ja.

Und dann sind wir bei der Last, die das erzeugt...

Wie wärs, wenn man die Tabellendefinitionen in ein cache-File liest - das kostet zwar auch etwas Performance, aber es ist doch nicht notwendig jedes mal vorher eine Abfrage anzuwerfen.

Aber Du hast mich da auf eine Idee für die Basistests gebracht.

Wunderbar :)

[Rosalie Th.]

Jetzt funktioniert es. Ich weiss aber noch nicht warum oder was ich gemacht habe. Montagsmorgendusel!

Vielen Dank für die rasche Hilfe.

Liebe Grüsse
Rosa

[suit]

Jetzt funktioniert es. Ich weiss aber noch nicht warum oder was ich gemacht habe. Montagsmorgendusel!

Ich denke eher es handelt sich um "Copy&Paste"-Programmierung - du solltest dringend daran arbeiten, das kann sonst gefährlich enden.

[dedlfix]

Hi!

Nun möchte ich die Abfrage [...] machen. Das funtioniert leider noch nicht.
$strQuery  = "SELECT *from tabelle TEST $bedingung";
$dbRS = MySQLQuery($strQuery);
$arrRS = mysql_fetch_array($dbRS);
Muss ich das mit "@" lösen?

Keinesfalls. Wenn du einen Fehler hast, hilft es nicht, einfach seine Meldung zu unterdrücken. Im Gegenteil, du solltest während der Programmentwicklung alles dafür tun, um Fehler anzeigen zu lassen. Die mysql_*-Funktionen verhalten sich in puncto Fehlermeldungen etwas anders als das restliche PHP. Fehler werden über den Rückgabewert signalisiert (der ist dann false und keine Ressourcenkennung, wie sie die nachfolgenden Funktionen fordern). Den genauen Text zu einem Fehler liefert die Funktion mysql_error(). Und da findest du dann auch, was MySQL konkret nicht gepasst hat.

Lo!